On Mon, 2017-04-03 at 16:47 +0200, Georg Chini wrote:
> +/* Called from main thread.
> + * It has been a matter of discussion how to correctly calculate the minimum
> + * latency that module-loopback can deliver with a given source and sink.
> + * The calculation has been placed in a separate function so that the definition
> + * can easily be changed. The resulting estimate is not very exact because it
> + * depends on the reported latency ranges. In cases were the lower bounds of
> + * source and sink latency are not reported correctly (USB) the result will
> + * be wrong. */
> +static void update_minimum_latency(struct userdata *u, pa_sink *sink, bool print_msg) {
> +
> + u->minimum_latency = u->min_sink_latency;
> + if (u->fixed_alsa_source)
> + /* If we are using an alsa source with fixed latency, we will get a wakeup when
> + * one fragment is filled, and then we empty the source buffer, so the source
> + * latency never grows much beyond one fragment (assuming that the CPU doesn't
> + * cause a bottleneck). */
> + u->minimum_latency += u->core->default_fragment_size_msec * PA_USEC_PER_MSEC;
> +
> + else
> + /* In all other cases the source will deliver new data at latest after one source latency.
> + * Make sure there is enough data available that the sink can keep on playing until new
> + * data is pushed. */
> + u->minimum_latency += u->min_source_latency;
> +
> + /* Multiply by 1.1 as a safety margin for delays related to the buffer sizes */
You probably mean "for delays that are proportional to the buffer
sizes" or something like that. "Related to" doesn't quite convey the
same meaning.
Otherwise looks good.
--
Tanu
https://www.patreon.com/tanuk
