Re: [LAD] JACK + PA Latency

From: Patrick Shirkey <pshirkey@email-addr-hidden>
Date: Mon Sep 30 2013 - 15:15:24 EEST

On Mon, September 30, 2013 9:50 pm, Fons Adriaensen wrote:
> On Sun, Sep 29, 2013 at 08:19:08PM -0400, Paul Davis wrote:
>
>> 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.
>

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Oct 1 00:15:03 2013

This archive was generated by hypermail 2.1.8 : Tue Oct 01 2013 - 00:15:03 EEST