On 06.04.2017 21:54, Tanu Kaskinen wrote:
> 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.
>
Thanks for the review. Changed the comment and pushed.
