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

[Colin Guthrie]

Lennart Poettering wrote:
>> 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.

OK I think that kind of explains it. I certainly wont use ESD myself,
but I just wanted to understand why PA appeared to be performing worse
than ESD in this respect. I guess it's quite obvious when you lay it out
like that.

Real ESD:

App -> Resampling+Time Compensation -> ESD -> Output
                                       ^^^^^^^^^^^^^
                                       Little Delay

PulseAudio over ESD:

App -> PA(ESD Proto) -> Resampling -> Output
                        ^^^^^^^^^^^^^^^^^^^^
                        Some delay but no feedback to app


Cheers for the explanation.

Col