[SOLVED] Slightly confused by jack_iodelay output
Moderators: MattKingUSA, khz
-
- Established Member
- Posts: 381
- Joined: Sun May 28, 2017 3:52 pm
Re: [SOLVED] Slightly confused by jack_iodelay output
FWIW, with USB and the same settings, I see different roundtrip latencies each time I start JACK (both 1 & 2)...
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: [SOLVED] Slightly confused by jack_iodelay output
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:Jack Winter wrote:FWIW, with USB and the same settings, I see different roundtrip latencies each time I start JACK (both 1 & 2)...
Code: Select all
/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB -i2 -o2
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: [SOLVED] Slightly confused by jack_iodelay output
Soooo... I gave it a try: RT vs Stock, Sync. vs Async., all at 96k, and I do see a difference as wellCrocoDuck wrote: I feel like I was testing with the RT kernel back then, I did the latest ones with the standard one...
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
- 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
-
- Established Member
- Posts: 381
- Joined: Sun May 28, 2017 3:52 pm
Re: [SOLVED] Slightly confused by jack_iodelay output
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 wrote: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:Jack Winter wrote:FWIW, with USB and the same settings, I see different roundtrip latencies each time I start JACK (both 1 & 2)...
Then you should theoretically see more or less the same results.Code: Select all
/usr/bin/jackd -S -P89 -p128 -t2000 -dalsa -r96000 -p64 -n3 -D -Chw:USB -Phw:USB -i2 -o2
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: [SOLVED] Slightly confused by jack_iodelay output
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.Jack Winter wrote: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.
I'll give it a try as well, it's relatively easy to switch back and forth on Arch.
-
- Established Member
- Posts: 381
- Joined: Sun May 28, 2017 3:52 pm
Re: [SOLVED] Slightly confused by jack_iodelay output
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.gimmeapill wrote: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.
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.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
- sadko4u
- Established Member
- Posts: 989
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 361 times
Re: [SOLVED] Slightly confused by jack_iodelay output
Have you tried our new stuff?Jack Winter wrote: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.
viewtopic.php?f=24&t=17304
It's interesting to get measurements using it.
LSP (Linux Studio Plugins) Developer and Maintainer.
-
- Established Member
- Posts: 381
- Joined: Sun May 28, 2017 3:52 pm
Re: [SOLVED] Slightly confused by jack_iodelay output
Not yet since I'm mostly using reaper, but I'm looking forwards to testing once the gtk problem is solved.sadko4u wrote:Have you tried our new stuff?
viewtopic.php?f=24&t=17304
It's interesting to get measurements using it.
Reaper/KDE/Archlinux. i7-2600k/16GB + i7-4700HQ/16GB, RME Multiface/Babyface, Behringer X32, WA273-EQ, 2 x WA-412, ADL-600, Tegeler TRC, etc For REAPER on Linux information: https://wiki.cockos.com/wiki/index.php/REAPER_for_Linux
- sadko4u
- Established Member
- Posts: 989
- Joined: Mon Sep 28, 2015 9:03 pm
- Has thanked: 2 times
- Been thanked: 361 times
Re: [SOLVED] Slightly confused by jack_iodelay output
You can run a standalone version to perform a test.Jack Winter wrote:Not yet since I'm mostly using reaper, but I'm looking forwards to testing once the gtk problem is solved.
LSP (Linux Studio Plugins) Developer and Maintainer.
Re: [SOLVED] Slightly confused by jack_iodelay output
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.falkTX wrote: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.
-
- Established Member
- Posts: 2348
- Joined: Mon Jul 01, 2013 8:13 am
- Has thanked: 9 times
- Been thanked: 468 times
Re: [SOLVED] Slightly confused by jack_iodelay output
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.CrocoDuck wrote: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.
Code: Select all
____-____-____-____-
-____-____-____-____-
Code: Select all
____-____-____-____-
__-____-____-____-__
On the road again.
-
- Established Member
- Posts: 564
- Joined: Thu Mar 12, 2015 8:41 am
- Has thanked: 44 times
- Been thanked: 8 times
Re: [SOLVED] Slightly confused by jack_iodelay output
That USB bus is for sure a crapshoot fest.tramp wrote: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.CrocoDuck wrote: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.
on the next start, or after a Xrun it may look like thisCode: Select all
____-____-____-____- -____-____-____-____-
Code: Select all
____-____-____-____- __-____-____-____-__
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...