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

[Georg Chini]

>> 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.
> I assure you, I want these patches, especially this one, because this
> patch should fix two bugs that I know have caused people trouble (slow
> adjustment to target latency and accumulating a lot of latency when the
> sink is slow to start).
>
> I fully understand that the process is frustrating when we have trouble
> understanding each other. It's frustrating to me too. I wish I knew how
> to make it easier for us to reach common understanding.
>
> If you think that some criticism is excessive nitpicking, and you don't
> want to do the suggested change, you can say "I prefer doing it this
> way. If you want to change it, you can write a patch later yourself,
> ok?" That has been known to work sometimes.

Thanks.

>> 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.
> Are you still referring to this code:
>
> +            /* 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(u->sink_input->sink), false);
>
> The only condition is that pop hasn't been called, and from that you
> certainly can't draw the conclusion that the sink is not suspended. I
> am again very confused.
>
You are right. I even needed a check for the sink being suspended when
detecting an underrun one line further down in the code ...
The call is more or less there for symmetry reasons similar to the the
SINK_CHANGED message (which I will remove). I can remove it as well
if you like. It should not have much effect. This also applies for the other
call in sink_input_pop_cb().
But still you cannot get rid of the effective_source_latency variable, 
it becomes
relevant latest at the moment when we also have to take the offsets into 
account.