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

[Paul LeoNerd Evans]

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>