Re: [Jack-Devel] Testing jack_iodelay

On Tue, Aug 23, 2011 at 09:40:21AM +0200, Stéphane Letz wrote:

> I'm currently testing jack_iodelay with jack2 SVN on OSX and get this kind of result:
> 
> Signal below threshold...
>    926.942 frames     21.019 ms total roundtrip latency
> 	extra loopback latency: 21 frames
> 	use 10 for the backend arguments -I and -O
> 
> Since OSX CoreAudio drivers report their internal latencies (as the "input latency offset", "input latency", "output latency", "output latency offset"), and since those values are reported in JACK notion of in/out latency, the result should be better.
> 
> What is the expected precision of jack_iodelay?

There are two aspects to this, precision and error probability.

The precision depends on a phase measurement done at 1/16 of
the sample rate. This produces a delay value in the range
[0..16) samples. The real value is course this one plus k * 16
samples, k integer. For a decent audio card the precision will
be around 1/1000 of a sample, it depends mostly on S/N ratio.

Phase measurements on additional frequencies are used to find
the value of k. Each such measurement multiplies the unambiguous
range by a value of N. In the original version of jdelay (which
is the code used by jack_iodelay) N = 8. This is done in such
a way that small errors in the phase measurement have no effect
at all - the value is compared to N expected ones and the nearest
one is chosen. The system also checks for consistency between
the results. 

If the audio channel has a delay that is reasonably independent
of frequency no such errors will occur until the signal is really
very bad. But with N = 8 they are possible if you have things
like equalisers in the signal chain.

The latest release of jack_delay uses N = 2, which of course
requires more frequencies for the same range, but tolerates
much larger frequency-dependent delays.

Ciao,

-- 
FA

1314108932.12491_0.ltw:2,a <20110823141514.GA18448 at linuxaudio dot org>