+ >>>>> + /* If pop has not been called yet, make sure the >>>>> latency does not grow too much. >>>>> + * Don't push any silence here, because we already >>>>> have new data in the queue */ >>>>> + if (!u->output_thread_info.pop_called) >>>>> + memblockq_adjust(u, >>>>> pa_sink_get_latency_within_thread(->sink_input->sink), false); >>>> As mentioned above, the sink latency is undefined if the sink is not >>>> running yet. Luckily there's no need need to know the sink latency >>>> here: before pop has been called, the only reason why the memblockq >>>> needs to be adjusted in the POST handler is to avoid it becoming huge >>>> and thus consuming a lot of memory. memblockq_adjust() can be called >>>> here with simply zero as the offset parameter. >>>> >>> This will keep too much data in the queue if the sink is running. >>> This would not be a big problem, but why not adjust as good as >>> possible in this >>> situation? >> Because there's no benefit in doing that. Using 0 is simpler and >> doesn't involve invoking kernel code to ask for information that might >> be bogus anyway. >> > Sorry, slowly I am thinking that you don't want the patches at all and > are nitpicking > to discourage me. If you don't want the patches, just say so. Thinking twice, there is not even a way you could get to that call while the sink is suspended, so pa_sink_get_latency_in_thread() will always return some value.
