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