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

[Tanu Kaskinen]

On Thu, 2017-02-23 at 18:05 +0100, Georg Chini wrote:
> On 23.02.2017 12:17, Tanu Kaskinen wrote:
> > On Sun, 2017-02-19 at 17:15 +0100, Georg Chini wrote:
> > > The current code does not make any attempt to initialize the end-to-end latency
> > > to a value near the desired latency. This leads to underruns at startup because
> > > the memblockq is initially empty and to very long adjustment times for long
> > > latencies because the end-to-end latency at startup is significantly shorter
> > > than the desired value.
> > > This patch initializes the memblockq at startup and during source or sink changes
> > > so that the end-to-end latency will be near the configured value. It also ensures
> > > that there are no underruns if the source is slow to start and that the latency
> > > does not grow too much when the sink is slow to start by adjusting the length of
> > > the memblockq until the source has called push for the first time and the sink
> > > has called pop for the second time. Waiting for the second pop is necessary
> > > because the sink has not been started when the first pop is called.
> > 
> >   
> >       update_adjust_timer(u);
> > +
> > +    /* Send a mesage to the output thread that the source has changed.
> > +     * If the sink is invalid here during a profile switching situation
> > +     * we can safely set push_called to false directly. */
> > +    if (u->sink_input->sink)
> > +        pa_asyncmsgq_send(u->sink_input->sink->asyncmsgq, PA_MSGOBJECT(u->sink_input), SINK_INPUT_MESSAGE_SOURCE_CHANGED, NULL, 0, NULL);
> > +    else
> > +        u->output_thread_info.push_called = false;
> >   }
> >   
> >   /* Called from main thread */
> > @@ -451,6 +593,18 @@ static void source_output_suspend_cb(pa_source_output *o, bool suspended) {
> >       pa_assert_ctl_context();
> >       pa_assert_se(u = o->userdata);
> >   
> > +    /* If the source output has been suspended, we need to handle this like
> > "source output" -> "source" (the same terminology mistake is in
> > sink_input_suspend_cb())
> > 
> 
> Isn't it a source output suspend callback? Can the source output
> only be suspended when the source is suspended?

Source outputs don't have a suspended state. They have the corked
state, but this callback is not about that. This callback just tells
that the source that this source output is connected to became
suspended or unsuspended.

-- 
Tanu

https://www.patreon.com/tanuk