On Sun, 20 Oct 2013 07:25:23 +0100 Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote: > 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. In fact, I have just used tcpdump to prove this isn't the case. Because the TCP tunnel contains pure uncompressed PCM audio, a tcpdump with hexdump of the raw TCP segments contains pure zeroes during silence. With mpd paused, I see lots of zeroes go by. The /moment/ I unpause mpd, those zeros turn into varying numbers, containing real audio data. Yet my speakers remain silent... a number of seconds afterwards, sound now comes out. So then I hit pause. Instantly, those numbers in tcpdump are all zeroes again, but yet it takes a number of seconds for the sound to stop coming out of the speakers. This latency is occurring entirely with the tunnel receiver in my laptop, and not mpd. -- 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/3fb0a607/attachment.pgp>
