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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
