[pulseaudio-discuss] [PATCH] alsa: reset watermark to initial values on resume

[David Henningsson]

On 10/09/2011 11:34 AM, Tanu Kaskinen wrote:
> On Sun, 2011-10-09 at 10:53 +0200, David Henningsson wrote:
>> On 10/08/2011 11:27 AM, Arun Raghavan wrote:
>>> On Fri, 2011-10-07 at 18:12 -0500, Pierre-Louis Bossart wrote:
>>>> Watermark level and latency values are not restored when
>>>> resuming, the values used prior to suspending are reused.
>>>> This leads to side effects when underruns happen and buffer
>>>> sizes are updated, PulseAudio can never meet lower latency
>>>> requirements.
>>>>
>>>> Solution: keep track of watermark and latency values on sink or
>>>> source creation, and reapply them on resume to start with
>>>> a clean slate.
>>>
>>> One possible concern here -- if the default values are too low for a
>>> system, every suspend-unsuspend cycle will force readjustment,
>>> potentially causing artefacts.
>>>
>>> I'd argue that it's better to adjust the defaults on such a system,
>>> though, and broadly take the optimistic view that any major
>>> readjustments are unlikely to be required permanently.
>>>
>>> This is in my tree now -- just pointing out one side effect in case
>>> anyone else has similar concerns.
>>
>> For the reason pointed out above, I think this is in general a bad idea.
>>
>> Or put in another way - what is it that causes the underrun and
>> watermark to increase in the first place? Shouldn't we try to fix *that*
>> instead?
>>
>> But if we can't fix that something, what is it that says that it has
>> gone away because we suspend/resume the stream? Can there be better
>> methods to determine the "something" has stopped, e g if we have
>> fulfilled our watermark with a big margin for a specific amount of time?
>
> I see your point - so take my "looks good" comment as "if this logic
> makes sense (more than the current logic), the implementation looks good
> to me".
>
> 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?

In addition to Colin's comment, there is actually an interesting 
parameter here: the buffer attr's "maxlength" parameter. E g, an app 
could say "I'd really like 10 ms of latency, but anything above 50 ms is 
completely useless, so I prefer occasional underruns to that" by setting 
tlength to 10 ms and maxlength to 50 ms.

How well this actually plays out with watermark increases and all that, 
I'm not sure, but maybe we could investigate that path further.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic