On 10/10/2011 05:40 PM, Pierre-Louis Bossart wrote:
So the question is whether the logic in Pierre's patch makes sense.
I don't know the answer. Anyway, here's one argument why the current
logic is not good: I believe some applications really are sensitive to
latency - to the point that it's better to have occasional drop-outs
than to raise the watermark to prevent glitch-free playback or
recording.
I agree that resetting the watermark on suspend doesn't make too much
sense. Should we instead always obey the latency requests from clients
(i.e. not touch the watermark if doing so would increase the latency
too
much), or should the clients be able to explicitly say that "I'm ok
with
drop-outs if you can't satisfy my latency request otherwise"? Or am I
wrong in thinking that some applications prefer drop-outs to
higher-than-requested latency?
We could enhance the logic by detecting if the latency specified changed. My
thinking was that if the application changes, the load on the system will
also change.
Actually the main issue is not really the watermark, because the watermark
can be decreased. The issue is that after a set of underruns, the buffer
settings will be increased, and they will never ever be decreased. This
means if there's a set of glitches, the only way to have low-latency is to
restart pulseaudio...My patch is a step to avoid this.
If the RT prio stuff is working the way it should, there shouldn't be
underruns (on the Pulse/ALSA side, not the client side) even if the
system load is high.
Before working around this in PulseAudio, what was the original reason
in your case for the underruns (which in turn caused the increase in
buffer settings)?
I think it'd be great to have one (or even better, a few) examples here
so we can understand the problem better.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
