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>
