[PATCH 09/13] loopback: Track the amount of jitter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2015-12-12 at 11:52 +0100, Georg Chini wrote:
> On 08.12.2015 21:47, Tanu Kaskinen wrote:
> > On Wed, 2015-02-25 at 19:43 +0100, Georg Chini wrote:
> > > ---
> > >   src/modules/module-loopback.c | 18 +++++++++++++++++-
> > >   1 file changed, 17 insertions(+), 1 deletion(-)
> > The commit message should say something about why the jitter is tracked.
> 
> OK
> 
> > > diff --git a/src/modules/module-loopback.c b/src/modules/module-loopback.c
> > > index cbd0ac9..b733663 100644
> > > --- a/src/modules/module-loopback.c
> > > +++ b/src/modules/module-loopback.c
> > > @@ -95,6 +95,8 @@ struct userdata {
> > >   
> > >       pa_usec_t source_latency_sum;
> > >       pa_usec_t sink_latency_sum;
> > > +    pa_usec_t next_latency;
> > > +    double latency_error;
> > >   
> > >       bool in_pop;
> > >       bool pop_called;
> > > @@ -263,15 +265,22 @@ static void adjust_rates(struct userdata *u) {
> > >                   (double) current_latency / PA_USEC_PER_MSEC,
> > >                   (double) corrected_latency / PA_USEC_PER_MSEC,
> > >                   ((double) u->latency_snapshot.sink_latency + current_buffer_latency + u->latency_snapshot.source_latency) / PA_USEC_PER_MSEC);
> > > -    pa_log_debug("Latency difference: %0.2f ms, rate difference: %i Hz",
> > > +    pa_log_debug("Latency difference: %0.2f ± %0.2f ms, rate difference: %i Hz",
> > What does "± %0.2f ms" mean? Is the real latency difference between
> > those bounds with 100% confidence, or less than 100% confidence?
> 
> This is just an indication of the current error (with respect to the model),
> so not 100% confidence.

Can you assign any particular confidence to the numbers? If not, then
the numbers have very little meaning... They can be useful for seeing
whether the jitter is higher or lower compared to some other
measurements, but they say very little about whether the latency
difference really is between those bounds.

At the very least there should be a comment explaining how the numbers
should be interpreted.

> > 
> > >                   (double) latency_difference / PA_USEC_PER_MSEC,
> > > +                (double) 2.5 * u->latency_error * final_latency / PA_USEC_PER_MSEC,
> > Why is that 2.5 there?
> > 
> 
> Good question. I think it was copied over from the definition of the 
> deadband in the next
> patch. The observed errors are however in good agreement with that factor.

What does that mean? What would be different if the factor wasn't
there? How would it be worse than with the magic factor?

-- 
Tanu


[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux