On Sun, 20 Oct 2013 07:25:23 +0100 Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > Restarted what? PulseAudio or MPD? I would expect that restarting MPD > is enough. Restarting the tunnel; running my previously-pasted script in "down" then "up" mode. > Latency can only increase only if there is some buffer that is > growing. module-tunnel doesn't have such buffer. It sounds like MPD > is working so that it writes at a constant pace to an internal > buffer, and reads from the buffer at the rate that PulseAudio asks > for more data. If network glitches occur, PulseAudio will ask less > often, so MPD's buffer will get larger and larger. If this > speculation is true, then MPD should be fixed. It should define some > maximum size for the buffer. 30 seconds is silly. And if you're > playing local files, this whole problem shouldn't exist, because MPD > should decode the files at the rate PulseAudio is consuming the data, > not at a constant wall-clock rate. I'm not sure that's consistent with what is happening. When I press the MPD pause button, it still takes a long time for the sound to stop playing. then again a long time after I resume it before the sound comes out again. Also, my MPD has multiple outputs; pushing to both pulse and the shoutcast server, so it couldn't wait for one output to catch up with the sound by delaying the others - it has to just generate sound at its own rate and let the outputs keep up as best they can. Again to clarify - I am happy for pulse to occasionally drop frames of audio in order to keep the end-to-end system latency bounded. It sounds like so far it isn't capable of doing so. -- 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/20131020/aba8551a/attachment.pgp>
