[pulseaudio-discuss] [RFC] When maxlength and adjust_latency are set, do not allow higher latencies

[Tanu Kaskinen]

On Wed, 2013-06-12 at 16:28 +0200, David Henningsson wrote:
> Assume that we *really really* want no more than 10 ms of latency, and
> there are occasional underruns. Now the latency will increase, first to 1 ms,
> then 2 ms, 4 ms, 8 ms, 16 ms. At that point, when the sink's latency
> is 16 ms and maxlength is 10 ms, we get a constant stream of underruns,
> because we fill 10 ms of data up and then go to sleep for 16 ms (minus watermark).
> 
> By not allowing the latency to grow beyond 7.5 ms in this case, we
> only get occasional underruns instead of constant underruns.
> 
> This is not a finished patch:
>  1) I'm not sure (maxlength - minreq) is the correct formula, but it seems to
>     work reasonably here at least.

It sounds reasonable to at least have both maxlength and minreq in the
formula. I guess the question is whether the margin that is substracted
from maxlength should sometimes be larger than minreq. I have no idea
about that.

>  2) The max_sink_length calculation should probably be somewhere in sink.c.

By max_sink_length I assume you mean max_sink_latency? I don't see why
calculating that value should be done in sink.c, since it's a property
of the sink input.

>  3) Setting max_sink_length should probably be done in a more thread safe fashion.

Yes. I think there should be pa_sink_input_set_max_sink_latency(), which
would send a message to the IO thread (if the sink input is linked).

>  4) I'm not sure whether we should add something to the other modes
>     (traditional, early requests). After all, it's only in adjust_latency
>     mode that we describe as "adjusting the overall latency of the pipeline".

I don't think the other modes need any changes.

-- 
Tanu