[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