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
