[SOLVED] Slightly confused by jack_iodelay output

[CrocoDuck]

Hi there!

I have been using jack_iodelay in the past to get the round-trip latency of my sound-card. I remember its results to correlate very well with the lag I could observe comparing, say, a square wave track with the square wave I would record by looping back the track through the sound-card and another track, using a DAW.

However, I have been playing with jack_iodelay today and there's something I don't quite get. If I launch jack_iodelay and loop its output directly to its input, without passing through the soundcard, the latency should be 0 since the output is just being copied back to the input. Instead, I read the JACK Frames/Period value:

Code: Select all

/usr/bin/jackd -P70 -t5000 -dalsa -r96000 -p4096 -n3 -D -Chw:USB,0 -Phw:USB,0

Code: Select all

4096.000 frames     42.667 ms total roundtrip latency
    extra loopback latency: 4096 frames
    use 2048 for the backend arguments -I and -O

What am I not getting?

[CrocoDuck]

Hi, thank you for your reply!

Yes, it is JACK2, and I tried with the -S option. I get the same result:

Code: Select all

/usr/bin/jackd -S -P70 -t5000 -dalsa -r96000 -p4096 -n3 -D -Chw:USB,0 -Phw:USB,0

Code: Select all

4096.000 frames     42.667 ms total roundtrip latency
  extra loopback latency: 4096 frames
  use 2048 for the backend arguments -I and -O

[CrocoDuck]

With the help of sadko4u, I think I am getting why.

I think that in very basic terms the fact is that as soon as I connect jack_iodelay output to its input there is really nothing to write to jack_iodelay input: an output buffer has not been produced by jack_iodelay yet. Given that the buffer is Frames/Period long, I will have to wait Frames/Period samples to get one filled, that then is made available for the input. Hence the latency.

Does it make any sense?

[gimmeapill]

Yes, this makes sense. As I understand it, you should see just the jack buffer value and not the ADC/DAC conversion time (why would you want to do that is of course another question ).
What I don't get is why you see the same value even with with synchronous mode enabled...

[tramp]

What I don't get is why you see the same value even with with synchronous mode enabled...

Simply, because jack_iodelay is a single client, that means, in any cycle (frame), first the input port gets processed by jack, and, then, exact one cycle (frame) later, the output port gets processed. Hence you see the delay of exact one jack frame buffer.
This gives jack_iodelay, as any other jack client, the time ( one frame) to process the buffer.
The extra frame jackd2 use in async-mode, isn't between jack clients, it's just between jack and alsa. It's a additional initial buffer, not a additional per cycle (frame) buffer , so jack_iodelay wont recognise it, when connected this way.
Results may start to get interesting, when you use a loopback cable from your sound-card output to your sound-card input.
Then the results between async and sync mode may be visible in the results.

[gimmeapill]

Ok, got it. Thanks Tramp for the explanation.
And it works: With jack_iodelay connect to itself without going through the system outputs, the latency reported is exactly one frame, but that is not very useful information.

Actually I just spotted some interesting behavior with my scarlett 2i2 first gen when running through my usual jack settings
(tihis time with a patch cable - sorry CrocoDuck for the hijacking):

Code: Select all

/usr/bin/jackd -P89 -p128 -t2000 -dalsa -r44100 -p32 -n3 -Xseq -D -Chw:USB -Phw:USB -i2 -o2
	607.633 frames     13.779 ms total roundtrip latency
        extra loopback latency: 479 frames
        use 239 for the backend arguments -I and -O

/usr/bin/jackd -P89 -p128 -t2000 -dalsa -r48000 -p32 -n3 -Xseq -D -Chw:USB -Phw:USB -i2 -o2
        398.641 frames      8.305 ms total roundtrip latency
        extra loopback latency:270 frames
        use 135 for the backend arguments -I and -O

/usr/bin/jackd -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3 -Xseq -D -Chw:USB -Phw:USB -i2 -o2
	751.640 frames      7.830 ms total roundtrip latency
        extra loopback latency: 495 frames
        use 247 for the backend arguments -I and -O

/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3 -Xseq -D -Chw:USB -Phw:USB -i2 -o2
	621.640 frames      6.475 ms total roundtrip latency
        extra loopback latency: 429 frames
        use 214 for the backend arguments -I and -O

This might not be very obvious, but the extra loopback latency reported at 48k (which I understand is the combination of alsa driver + HW latency) is significantly lower: 270 frames versus 400 something in all other cases.
Should I conclude that the card itself perfoms best at 48K?

[CrocoDuck]

Thank you for your explanations guys!

Should I conclude that the card itself perfoms best at 48K?

I don't really have any clue about that. Unfortunately I don't really know much about the details of AD/DA converters implementation (and data communication over USB).

[tramp]

This might not be very obvious, but the extra loopback latency reported at 48k (which I understand is the combination of alsa driver + HW latency) is significantly lower: 270 frames versus 400 something in all other cases.
Should I conclude that the card itself perfoms best at 48K?

You should translate the reported latency samples into time.
formula is:
1 sec = sample rate
1000 ms = 1 sec
so you get
1000/ sample rate = ms per sample

formula is now

(1000/sample rate) * latency reported = latency in millisecond

the formula could abstracted to

1000 / (sample rate / number of samples) = latency in millisecond

So, on 48kHz you've 270 samples, which means

1000 / (48000/270) = 5,625 ms

for 96kHz you've 495 samples (without the -S option)

1000/(96000/495) = 5,156 ms

with the -S option on 96kHz you get

1000/(96000/429) =4,469 ms

on 44100 Hz it's

1000/(44100/479) = 10,86 ms

conclusion:
the sample rate 44100 Hz isn't well supported by your card,
looks like some kind of resampling is going on,
or, the frames didn't fit well in the internal buffer of the card,
but 96 kHz or 48 kHz didn't differ that much.

[CrocoDuck]

conclusion:
the sample rate 44100 Hz isn't well supported by your card,
looks like some kind of resampling is going on,
or, the frames didn't fit well in the internal buffer of the card,
but 96 kHz or 48 kHz didn't differ that much.

That's interesting. Could it be that the sound card works with up-sampling? Maybe the sampling happens at 96 kHz or even 192 kHz all the time, and then the signal is downsampled (if needed) later on. If I am not wrong this is often done to implement better anti aliasing filters. Then, 96 kHz and 48 kHz would work better due to being commensurate (hence making re-ampling easier).

192000 / 96000 = 2 => easy resampling
192000 / 48000 = 4 => easy resampling
192000 / 44100 = 4.35374149659864 => not integer, harder resampling

Or

96000 / 48000 = 2 => easy resampling
96000 / 44100 = 2.17687074829932 => not integer, harder resampling

[gimmeapill]

conclusion:
the sample rate 44100 Hz isn't well supported by your card,
looks like some kind of resampling is going on,
or, the frames didn't fit well in the internal buffer of the card,
but 96 kHz or 48 kHz didn't differ that much.

Thanks Tramp, with the formula it is crystal clear (& I really have to write that one down).
The impact of the extra Jack buffer in asynchronous mode is negligible, but that performance hit at 44.1k is rather interesting.
& I have now a very good reason to avoid 44.1k with Guitarix - which has actually nothing to do with Guitarix itself

@CrocoDuck: Agree with the resampling factor, it's easier with integers. I put my money on 96K fixed internal frequency for for the Scarlett v1 and 192K for the v2 (just because otherwise it wouldn't make sense for Focusrite to advertise something lower than what the card supports natively).
Out of curiosity, can you try with your 2i4 if you still have it? I remember it performed slightly differently (not to say better) when we did a pissing contest last year

[CrocoDuck]

@CrocoDuck: Agree with the resampling factor, it's easier with integers. I put my money on 96K fixed internal frequency for for the Scarlett v1 and 192K for the v2 (just because otherwise it wouldn't make sense for Focusrite to advertise something lower than what the card supports natively).
Out of curiosity, can you try with your 2i4 if you still have it? I remember it performed slightly differently (not to say better) when we did a pissing contest last year

Sure!

Code: Select all

/usr/bin/jackd -P70 -t5000 -dalsa -r44100 -p32 -n3 -D -Chw:USB,0 -Phw:USB,0
   369.682 frames      8.383 ms total roundtrip latency
	extra loopback latency: 241 frames
	use 120 for the backend arguments -I and -O
	
/usr/bin/jackd -P70 -t5000 -dalsa -r48000 -p32 -n3 -D -Chw:USB,0 -Phw:USB,0
   387.696 frames      8.077 ms total roundtrip latency
	extra loopback latency: 259 frames
	use 129 for the backend arguments -I and -O
	
/usr/bin/jackd -P70 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB,0 -Phw:USB,0
   814.754 frames      8.487 ms total roundtrip latency
	extra loopback latency: 558 frames
	use 279 for the backend arguments -I and -O
	
/usr/bin/jackd -S -P70 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB,0 -Phw:USB,0
   823.754 frames      8.581 ms total roundtrip latency
	extra loopback latency: 631 frames
	use 315 for the backend arguments -I and -O

Uhm... a bit all over the place isn't it?

[gimmeapill]

Thanks Croco.
All over the place, yes. Your results are weird too, but in a different way
I eventually found that old thread: viewtopic.php?f=24&t=15809&hilit=jack_iodelay&start=30

And interestingly, some of the results are comparable.
On 15/07/2016 - roughly one year ago, you had for example:

Code: Select all

96000Hz, 64 buffer, 3 periods/buffer

Code: Select all
   636.753 frames      6.633 ms total roundtrip latency
   extra loopback latency: 380 frames
   use 190 for the backend arguments -I and -O

(I'm assuming this was run at the time with jack2 in default async mode)

This became today:

Code: Select all

/usr/bin/jackd -P70 -t5000 -dalsa -r96000 -p64 -n3 -D -Chw:USB,0 -Phw:USB,0
   814.754 frames      8.487 ms total roundtrip latency
   extra loopback latency: 558 frames
   use 279 for the backend arguments -I and -O

I didn't even need to convert the extra loopback latency to ms: there's a clear perf. degradation here.
This difference over a year cannot be due just to the card converters (unless you messed really really badly with the components inside).
That must have to do with the rest of the system, either the alsa driver/kernel and the computer itself - this skews the extra loopback latency value reported. You changed your computer in the meantime, right?

As for my results, nothing particularly surprising. For the results that are comparable, the variations are smaller, probably because my config didn't change much except for the RT kernel upgrades and the switch from jack1 to jack2. I just wish I had run the benchmark at 44.1k last year.

The results given by jack_iodelay are anyway to be taken with a grain of salt. It looks like things like the USB bus latency are tainting the results more than we thought, no?

And of course, why you see a higher extra loopback value when you enable Synchronous mode is yet another mystery...

[CrocoDuck]

This difference over a year cannot be due just to the card converters (unless you messed really really badly with the components inside).

Indeed. Moreover, electronics are very reliable and deterministic things. If they get screwed it is more likely for the thing to just stop working or freeze in an unrecoverable state.

You changed your computer in the meantime, right?

No, I changed my computer in September 2015.

I feel like I was testing with the RT kernel back then, I did the latest ones with the standard one...

The results given by jack_iodelay are anyway to be taken with a grain of salt. It looks like things like the USB bus latency are tainting the results more than we thought, no?

Yeah, jack_iodelay is pretty good at measuring the delay between two points, so I would say it is actually accurate. However, the extra loopback latency is latency "not due to JACK buffering", so it includes really all the rest of the latency sources.

And of course, why you see a higher extra loopback value when you enable Synchronous mode is yet another mystery...

That's pretty weird...

[Jack Winter]

FWIW, with USB and the same settings, I see different roundtrip latencies each time I start JACK (both 1 & 2)...

[gimmeapill]

FWIW, with USB and the same settings, I see different roundtrip latencies each time I start JACK (both 1 & 2)...

By default this is pretty much normal since jack2 runs by default in asynchronous mode and adds 1 period as buffer. To get comparable results between jack1 and jack2, you should start jack2 in synchronous mode with the "-S" switch, like that:

Code: Select all

/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB -i2 -o2

Then you should theoretically see more or less the same results.