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

[Tanu Kaskinen]

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?

-- 
Tanu