[SOLVED] Slightly confused by jack_iodelay output

[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.

[gimmeapill]

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

Soooo... I gave it a try: RT vs Stock, Sync. vs Async., all at 96k, and I do see a difference as well

Code: Select all

RT kernel (4.9.27), jack2, synchronous
/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3

   624.639 frames      6.507 ms total roundtrip latency
        extra loopback latency: 432 frames
        use 216 for the backend arguments -I and -O
 
RT kernel (4.9.27), jack2, asynchronous     
/usr/bin/jackd -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3

   705.639 frames      7.350 ms total roundtrip latency
        extra loopback latency: 449 frames
        use 224 for the backend arguments -I and -O
   
Stock Arch kernel (4.11.9), jack2, synchronous
/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3

   602.639 frames      6.277 ms total roundtrip latency
        extra loopback latency: 410 frames
        use 205 for the backend arguments -I and -O

Stock Arch kernel (4.11.9), jack2, asynchronous
/usr/bin/jackd -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3

   678.639 frames      7.069 ms total roundtrip latency
        extra loopback latency: 422 frames
        use 211 for the backend arguments -I and -O

Conclusions regarding the fluctuations of that "extra loopback latency" value:
- The kernel makes a difference (in my case pretty small).
But I tested different versions, with probaby some Alsa changes in the middle, so this is probably apple and oranges.
To get a better undertsanding we should compare RT vs Stock at the same version, which is hardly possible with Arch, unless maybe by going back to LTS (I'm too lazy to do that). At least it seems that newer = better, RT or not. Xruns are a completely different thing.
- the jack sync/async mode seems to make a difference as well, but nothing unexpected in my case.
- the sound card seems to make a difference.

= we're chasing unicorns with that mysterious "extra loopback latency", there are just too many unknown factors

[Jack Winter]

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.

What I mean is not the difference between jack1 and jack2's default double buffering. What I mean is that each subseqent invocation of the server might show a slightly different loopback latency.

[gimmeapill]

What I mean is not the difference between jack1 and jack2's default double buffering. What I mean is that each subseqent invocation of the server might show a slightly different loopback latency.

Do you mean that with jack1 you get more or less identical loopback latency values on each start but not with jack2? That's interesting.
I'll give it a try as well, it's relatively easy to switch back and forth on Arch.

[Jack Winter]

Do you mean that with jack1 you get more or less identical loopback latency values on each start but not with jack2? That's interesting.
I'll give it a try as well, it's relatively easy to switch back and forth on Arch.

No what I mean is that both jack1 and jack2 exhibits a strange behaviour, namely that the jack_iodelay result is not repeatble after a restart of the server. Don't remember the exact values, but jack_iodelay results might differ by up to 50 samples on USB.

1 Start jack take a measurement
2 Restart jack, take another measurement
Result, a possibly different roundtrip latency.

I've seen this on usb with both a rme babyface and a behringer x32, I've also seen it with both jack1 and jack2.

Never see it with my rme multiface, the hidden latency is always the same no matter what parameters are used or if jack gets restarted.

[sadko4u]

I've seen this on usb with both a rme babyface and a behringer x32, I've also seen it with both jack1 and jack2.

Never see it with my rme multiface, the hidden latency is always the same no matter what parameters are used or if jack gets restarted.

Have you tried our new stuff?
viewtopic.php?f=24&t=17304
It's interesting to get measurements using it.

[Jack Winter]

Have you tried our new stuff?
viewtopic.php?f=24&t=17304
It's interesting to get measurements using it.

Not yet since I'm mostly using reaper, but I'm looking forwards to testing once the gtk problem is solved.

[sadko4u]

Not yet since I'm mostly using reaper, but I'm looking forwards to testing once the gtk problem is solved.

You can run a standalone version to perform a test.

[CrocoDuck]

There's a random latency value when using a usb soundcard, which is different everytime jackd is restarted.
I don't know the reason myself, only that it has been mentioned several times on IRC.

Yes. When I worked on my master project I had to monitor latencies and I found that they change not only when restarting JACK, but also when an xrun happens. Don't really know why too.

[tramp]

Yes. When I worked on my master project I had to monitor latencies and I found that they change not only when restarting JACK, but also when an xrun happens. Don't really know why too.

Just a guess here, but the USB protocol use "packages", didn't it? As so does jack. But, there is no sync function between them. So, the round-trip latency may depend on the sync between jack buffer and USB package, so the USB card may re-pack the buffers to fit the USB protocol.

Code: Select all

____-____-____-____-
-____-____-____-____-

on the next start, or after a Xrun it may look like this

Code: Select all

____-____-____-____-
__-____-____-____-__

[gimmeapill]

Yes. When I worked on my master project I had to monitor latencies and I found that they change not only when restarting JACK, but also when an xrun happens. Don't really know why too.

Just a guess here, but the USB protocol use "packages", didn't it? As so does jack. But, there is no sync function between them. So, the round-trip latency may depend on the sync between jack buffer and USB package, so the USB card may re-pack the buffers to fit the USB protocol.

Code: Select all

____-____-____-____-
-____-____-____-____-

on the next start, or after a Xrun it may look like this

Code: Select all

____-____-____-____-
__-____-____-____-__

That USB bus is for sure a crapshoot fest.
It should theoretically be possible to wireshark/pcap an xrun, or simply record the traffic to the audio interface to find out more: https://wiki.wireshark.org/CaptureSetup/USB
https://ask.wireshark.org/questions/110 ... sb-traffic
I'll give it a try when time permits, although I don't expect to undertsand much of the output, even assuming I find the right filters...