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
