[pulseaudio-discuss] [PATCH 02/21 v2] loopback: Initialize latency at startup and during source/sink changes

[Georg Chini]

+
>>>>> +            /* 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.