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
