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?
