[pulseaudio-discuss] [PATCH 2/2] source/sink: Allow pa_{source, sink}_get_latency_within_thread() to return negative values

[Tanu Kaskinen]

On Fri, 2017-04-14 at 17:02 +0200, Georg Chini wrote:
> The reported latency of source or sink is based on measured initial conditions.
> If the conditions contain an error, the estimated latency values may become negative.
> This does not indicate that the latency is indeed negative but can be considered
> merely an offset error. The current get_latency_in_thread() calls and the
> implementations of the PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY messages truncate negative
> latencies because they do not make sense from a physical point of view. In fact,
> the values are truncated twice, once in the message handler and a second time in
> the pa_{source,sink}_get_latency_within_thread() call itself.
> This leads to two problems for the latency controller:

The commit references "the latency controller" without giving any clue
about what that is, so please mention that you're talking about module-
loopback.

If I understood correctly, the two problems you mention here are not
yet fixed, but will be fixed in a subsequent patch. That could be
stated more clearly in the commit message.

> 
> - Truncating leads to discontinuities in the latency reports which then trigger
>   unwanted end to end latency corrections
> - If a large negative port latency offsets is set, the reported latency is always 0,
>   making it impossible to control the end to end latency at all
> 
> This patch adds a flag to pa_{sink,source}_get_latency_within_thread() to allow
> negative return values. Truncating is also removed in all implementations of the
> PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY message handlers. The allow_negative flag
> is set to false for all calls of pa_{sink,source}_get_latency_within_thread()
> except when used within PA_{SINK,SOURCE}_MESSAGE_GET_LATENCY. This means that the
> original behavior is not altered in most cases. Only if a positive latency offset
> is set and the message returns a negative value, the reported latency is smaller
> because the values are not truncated twice.
> 
> Additionally let PA_SOURCE_MESSAGE_GET_LATENCY return -pa_sink_get_latency_within_thread()
> for monitor sources because the source gets the data before it is played.

Even though I complained about a couple of things, the commit message
is pleasantly clear and detailed. Thank you!

The code looks good to me.

-- 
Tanu

https://www.patreon.com/tanuk