[pulseaudio-discuss] Understanding esound latency issues (was Re: pulseaudio automatic startup)

[Lennart Poettering]

On Sun, 17.02.08 02:09, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Thanks for the info. I've done some tests here with interesting results.
> If you've any insight here it would be useful.
> 
> I know esd is evil, but I just want to try and understand why this is
> happening. I've tried with both pulse and the real esd:
> 
> When playing a 48kHz file, mplayer -ao esd will resample to 44.1kHz
> before giving it to the audio layer. This results in bad lip sync with
> esd and noticibly worse sync with pulse.
> 
> When playing a 44.1kHz file mplayer -ao esd will just pass the audio
> straight to the audio layer. This results in bad lip sync with esd
> (comparable to the above test) and *better* sync with pulse! (this is
> probably due to the fact that the latency reported by mplayer esd is
> actually higher than with pulse which is nice!).
> 
> So the question is, why does the extra resampling by mplayer cause worse
> performance with pulse than with esd?

Since the esd protocol provides no way to query the actual latency,
the servers will pick for buffering whatever suits them and the
clients will usually just do a bit of guess work, which is usually
wrong -- especially if the server side is called PA and is not the real
ESD.

Now, if you are lucky, than things are lip sync due to coincidence if
you do resampling, but not if you don't do it (or the other way
round). This is the case because doing resampling adds an extra
latency to the whole system, and thus the guess of the client might be
better (or worse) than otherwise.

Don't do esd if you care about lip sync or latency. Just don't.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4