linuxgeek: [nslu2-linux] CPU utilization for mpd streaming

   Hello, all. I've been successfully using mpd 0.15.7-1 on unslung 6.10. When I use on-board hardware, and route audio through a USB audio device, everything works just fine. I recently tried using the built-in streaming server to create an http-based audio interface. When I play some MP3s (using a web-based client), and then go to connect to the audio stream, the stream begins to buffer very, very slowly (it might be ready to play after a few minutes, which isn't right).

   I used top to determine what the CPU utilization of mpd was at "rest":

Mem: 29604K used, 912K free, 0K shrd, 864K buff, 13368K cached
CPU:   3% usr   1% sys   0% nice 94% idle   0% io   0% irq   0% softirq
Load average: 1.93 1.26 1.02
PID PPID USER     STAT   VSZ %MEM %CPU COMMAND
535     1 root     S    22736 74%   0% /opt/bin/mpd
545   544 root     S    22736 74%   0% /opt/bin/mpd
544   535 root     S    22736 74%   0% /opt/bin/mpd
546   544 root     D    22736 74%   0% /opt/bin/mpd

   Here it is with a playlist actively playing in mpd (this is what it settles down to after spiking up to around 80% CPU utilization in the first 10 seconds or so of playback):

Mem: 29848K used, 668K free, 0K shrd, 1116K buff, 13464K cached
CPU: 14% usr   1% sys   0% nice 83% idle   0% io   0% irq   0% softirq
Load average: 1.64 1.57 1.20
PID PPID USER     STAT   VSZ %MEM %CPU COMMAND
546   544 root     S    25364 83% 15% /opt/bin/mpd
545   544 root     S    25364 83%   0% /opt/bin/mpd
910   544 root     R    25364 83%   0% /opt/bin/mpd
535     1 root     S    25364 83%   0% /opt/bin/mpd
544   535 root     S    25364 83%   0% /opt/bin/mpd

   And then when I actually use a client to connect to the http stream:

Mem: 29616K used, 900K free, 0K shrd, 1388K buff, 12976K cached
CPU: 98% usr   1% sys   0% nice   0% idle   0% io   0% irq   0% softirq
Load average: 1.96 1.46 1.11
PID PPID USER     STAT   VSZ %MEM %CPU COMMAND
910   544 root     R    25364 83% 100% /opt/bin/mpd
546   544 root     S    25364 83%   0% /opt/bin/mpd
535     1 root     S    25364 83%   0% /opt/bin/mpd
545   544 root     S    25364 83%   0% /opt/bin/mpd
544   535 root     S    25364 83%   0% /opt/bin/mpd

   Here's what my /etc/mpd.conf file looks like:

#mpd - Music Player Daemon configuration

port                    "6600"
music_directory         "/opt/bin/.mpd/my_mp3s"
playlist_directory      "/opt/bin/.mpd/playlists"
db_file                 "/opt/bin/.mpd/mpd.db"
log_file                "/opt/bin/.mpd/mpd.log"
error_file              "/opt/bin/.mpd/mpd.error"

# OSS Mixer
#mixer_type              "oss"
#mixer_device            "/dev/mixer"
#mixer_control           "Vol"

# new configuration to activate HTTP stream
audio_output {
    type                "httpd"
    name                "SLUG Radio"
    encoder                "lame" # optional, vorbis or lame
    port                "8000"
    quality                "5.0"   # do not define if bitrate is defined
#    bitrate                "128"   # do not define if quality is defined
    format                "44100:16:1"
}

   The OSS Mixer section enables the hardware-based audio output, which works fine (even though I get deprication messages when I start mpd from the command line).

   I've tried switching the encoder to "vorbis", but it seems that parameter is not acceptable in my current configuration. I've tried switching off the "quality" parameter while turning on the "bitrate" parameter. I also tried commenting out the "format" parameter. None of those changes made any difference.

   I know from the wiki (and from experience) that the NSLU does not support floating-point computation. Is there something I'm missing about the stream encoding that is requiring floating-point math, that the normal hardware-based output does not? I don't think it's the lame encoder, since I also use my Slug to share MP3s with TiVos in my house using pyTivo, and I believe that package uses lame as the transcoding engine.

   Help?