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
