[pulseaudio-discuss] Transporting sound from 'mpd' server to laptop

Paul LeoNerd Evans leonerd at leonerd.org.uk
Sat Oct 19 19:53:49 CEST 2013


Hi all,

I run mpd on my house server, so it can serve sound to a number of
clients, one of which is my laptop. Until recently I was using
shoutcast/icecast for this, but I thought I'd try out pulse instead due
to a number of non-ideal properties of icecasting.

My first attempt was to try RTP, largely by following a few examples
such as http://fruit.je/mpd-rtp. This works fine if I put the laptop
directly on the same wired ethernet link that the server is, but the
IP mulitcast traffic won't make it across the router to reach wireless.

So next I tried various forms of "tunnel". I have one solution somewhat
working currently though it is non-ideal. The current config I have is

(on the mpd server):
  load-module module-null-sink sink_name=rtp format=s16be channels=2
    rate=44100 sink_properties="device.description='RTP Multicast Sink'"

then on my laptop, a script to run:

  #!/bin/sh

  case "$1" in
    up)
      pacmd load-module module-tunnel-source server=cel.leo source=rtp.monitor
      sleep 0.2 # give it time to start up
      pacmd load-module module-loopback source=tunnel-source.cel.leo sink=0
      ;;
    down)
      pacmd unload-module module-tunnel-source
      pacmd unload-module module-loopback
      ;;
  esac

This currently has a number of problems with it:

 1) It's not automatic; I have to remember to run the "up" mode on
    resume from suspend.

 2) Because it's two modules and not just one, the sleep is necessary
    to (hopefully) ensure the tunnel is running before loopback starts,
    otherwise it won't find a source to pull from. The timing however
    is unreliable and it doesn't always work - sometimes I have to
    "down" then "up" it again.

 3) Also because it has two modules, whenever the server goes away
    (e.g. because I've taken my laptop elsewhere) the tunnel module
    disappears but the loopback remains, and switches its source to the
    fallback, which becomes the local microphone. So now I have my
    local speakers echoing from the microphone. Not good.

 4) This mode accumulates latency. One of the reasons I wanted to avoid
    icecast is because of the near-3second latency that happens between
    the play/pause button on mpd, and the sound on the speakers.
    Initially this pulseaudio tunnel is near-instant, though any sort
    of network upset causes it to stutter into a latency it never
    recovers, so after several hours it could be many seconds latent. I
    once stopped timing it after 30 seconds of latency and just
    restarted it.

Does anyone have any suggestions on this, on how I can run it better?
This sort of simple network sound seems like the ideal thing Pulse is
built for, but I can't quite see how to manage it at present.

-- 
Paul "LeoNerd" Evans

leonerd at leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20131019/f262a666/attachment.pgp>


More information about the pulseaudio-discuss mailing list