30 Sep
2013
30 Sep
'13
2:15 p.m.
On Mon, September 30, 2013 9:50 pm, Fons Adriaensen wrote:
On Sun, Sep 29, 2013 at 08:19:08PM -0400, Paul Davis
wrote:
Thanks for that explanation. IIUC the variation is making it harder to get
a good reading. So the next step is figuring out why/where the variation
is happening in the first place.
It could just be this machine that is causing the inconsistent results or
it could be something in the multitude of code that is being touched in
order to send a stream from jack_delay -> pa ->ecasound ->pa ->
jack_delay.
This is why I ask for some more feedback from the LAD community.
I have written up a guide on the test process that I am using.
http://boosthardware.com/pa-jack-latency-test.txt
I'm asking for additional suggestions on how to authoritatively test this
combination and provide definitive results. I realise that it is a fairly
difficult question but it is part of a big push for wider adoption of open
source pro audio solutions so I hope that you will all feel it is worth
the effort to solve this problem too.
What I'm currently looking at is a tool that will measure the latency
between each node in the graph. Possibly extending jack_delay for that
purpose.
--
Patrick Shirkey
Boost Hardware Ltd
There is no difference between jack_iodelay and
*older* versions of
Fons'
original jack_delay, other than the formatting of the output.
He has noted in the past that we should upgrade the code in jack's
utility
folder to use his newer version.
As long as you measure a delay that is
* independent of frequency in the range (approx) FS/64 up to FS/16,
* constant or slowly changing
both versions will measure the same. The newer version will be
more tolerant if those conditions are not satisfied, which is
certainly the case here (the delay seems to increase in a non-
continuous way).
Delay is calculated for phase measurements on a series of sine
waves which have frequencies chosen to have some mathematical
properties.
The basic measurement is done at FS/16. This provides a delay
D in the range [0...16) samples. The real delay is D + k * 16
samples, with k integer. The other frequencies do not affect
precision, but are used to find the value of k.
The original version used 4 such frequencies, each of them
multiplying the unambiguous range by a factor of 8. The first
one will add k_1 * 16 samples, the second k_2 * 128 samples
and so on, with k_1...k4 integers in the range 0..7. The phase
measurements provide a value in the range [0..8) which is then
rounded to the nearest integer. This means that any error must
be smaller than 360/16 degrees, or the wrong k_n will result.
The new version uses 12 frequencies, each of them doubling the
range. This will produce the correct result if phase errors are
less than 360/4 degrees.
For a good signal, the values computed from those frequencies
will be close to an integer. The difference is tested, and if
greater than 0.2 the result is flagged as suspect or rejected.
When the delay is changing in steps (as is the case here), it's
easy to get values that are inconsistent.