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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
