Loading ...
Sorry, an error occurred while loading the content.

CPU utilization for mpd streaming

Expand Messages
  • M.J. Johnson
    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
    Message 1 of 1 , Feb 3, 2010
    • 0 Attachment
         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?
    Your message has been successfully submitted and would be delivered to recipients shortly.