On 03.04.2017 19:32, Peter Meerwald-Stadler wrote:
>> With the current code, the user can request any end-to-end latency. Because there
>> is no protection against underruns, setting the latency too small will result in
>> repetitive underruns.
>>
>> This patch tries to mitigate the problem by calculating the minimum possible latency
>> for the current combination of source and sink. The actual calculation has been put
>> in a separate function so it can easily be changed. To keep the values up to date,
>> changes in the latency ranges have to be tracked.
> nitpicking below
Thanks for reviewing.
>
>> @@ -142,13 +160,19 @@ enum {
>> SINK_INPUT_MESSAGE_REWIND,
>> SINK_INPUT_MESSAGE_LATENCY_SNAPSHOT,
>> SINK_INPUT_MESSAGE_SOURCE_CHANGED,
>> - SINK_INPUT_MESSAGE_SET_EFFECTIVE_SOURCE_LATENCY
>> + SINK_INPUT_MESSAGE_SET_EFFECTIVE_SOURCE_LATENCY,
> I think it is good pratice to end enumerations with , (comma) so that
> adding to the list changes one line and not two
Never appeared to me that the comma at the end of an enumeration
is on purpose. Thanks for the hint.
>
>> + * 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 */
>> + u->minimum_latency *= 1.1;
>> +
>> + /* Add 1.5 ms as a safety margin for delays not related to the buffer sizes */
>> + u->minimum_latency += 1.5 * PA_USEC_PER_MSEC;
>> +
>> + /* Add the latency offsets */
>> + if (-(u->sink_latency_offset + u->source_latency_offset) <= (int64_t)u->minimum_latency)
>> + u->minimum_latency += u->sink_latency_offset + u->source_latency_offset;
>> + else
>> + u->minimum_latency = 0;
> really set to 0? this doesn't go well with the comment above
Yes, 0 is correct. The latency offsets can be negative.
