[pulseaudio-discuss] [PATCH v6 14/25] source.c, sink.c: Implement pa_{source, sink}_get_raw_latency_within_thread() calls

[Tanu Kaskinen]

On Wed, 2016-08-17 at 06:52 +0200, Georg Chini wrote:
> On 17.08.2016 00:30, Tanu Kaskinen wrote:
> > What would you think about the following idea:
> > 
> > Let's say that the latency calculation in the alsa code results in
> > -123
> > usecs. Negative latencies are impossible, so we know that the value
> > is
> > wrong by at least 123 usecs. If the error is due to a wrong
> > reference
> > point that was set in the beginning, we can improve this and all
> > subsequent reports by moving the smoother's reference point by 123
> > usecs. It will cause a jump in the latency reports, but it will
> > happen
> > only once (well, there's no guarantee that the reference point
> > error
> > isn't bigger than 123 usecs, so negative values can still occur and
> > more jumps can happen, but each jump makes all subsequent jumps
> > smaller, until there's no more error left to fix).
> > 
> > The values produced by the smoother are estimates, so they can
> > contain
> > also other errors than the error in the reference point, so I guess
> > overcompensation is possible in this scheme, but I'd expect it to
> > be
> > negligible in magnitude.
> > 
> What would this be good for? Only not to have negative numbers?
> The final end-to-end latency is not what you configure anyway, there
> are (as we discussed) other offsets around that we cannot see. So
> why bother to correct half a millisecond here? Accepting negative
> latencies is just to keep the reports smooth and continuous.
> If you prefer, I can try your approach, but I do not see the benefit.

The benefit is the same as with your "accept negative values" patch:
more smooth and continuous reports than with the current code (and also
slightly more accurate, but the difference is negligible). The drawback
of this idea compared to your approach is that there are incontinuities
in the beginning, but on the plus side, the core doesn't have to be
complicated just in order to pass known-incorrect values around for
little practical benefit (or maybe there is some significant practical
benefit, but so far your stated goal of 50-usec latency stability seems
arbitrary, and irrelevant to end users).

-- 
Tanu