[namibj]

Actually, the RT_PREEMPT stuff gives you worst-case blips around the 100-300 microsecond mark, and if it's just audio with remotely tolerant handling of buffer under/overrun, you can ignore those and use the more normal latency ceiling around 20-50 microseconds.

Note: 192 kHz is 5.2 microseconds/sample, 48 kHz is 20.8 microseconds/sample. The 15 cm distance between the ears takes around 100 microseconds to traverse (at the higher speed-of-sound in the head, vs. free-air). The 1m distance of air for close-by human 1:1 talking takes a full 3 milliseconds to traverse.

There is a non-profit [0] with hard-realtime applications (including CNC) that runs a few racks of systems with latency monitoring. For example, the blue rack3slot0 line [1] is a histogram for an almost-standard distribution kernel on an IvyBridge Xeon-E3 running a thread with timer interrupts every 200 microseconds for about 5.5 hours (100 M times, specifically), and recording the latency of that interrupt. As one can see, there were about 20 at-or-above 20 microsecond delay, and even then just barely over. With remotely decent under/overrun hiding, 10 microsecond latency should be easily usable. And yes, those systems had background load at normal priority and this realtime thread at high priority:

> Between 7 a.m. and 1 p.m. and between 7 p.m. and 1 a.m., a simulated application scenario is running using cyclictest at priority 99 with a cycle interval of 200 µs and a user program at normal priority that creates burst loads of memory, filesystem and network accesses. The particular cyclictest command is specified in every system's profile referenced above and on the next page. The load generator results in an average CPU load of 0.2 and a network bandwidth of about 8 Mb/s per system.

[0]: https://www.osadl.org/Realtime-Linux.projects-realtime-linux... [1]: https://www.osadl.org/Optimization-latency-plot-of-selected-...

[fho]

Not entirely sure what you are getting at, I am guessing "10 ms latency is good enough for audio"? Plus "normally we are so far away from the speaker that it does not really make a difference"?

That figure is thrown around a lot and is definitely grounded in some solid research ... just ... lower latency numbers (in jackd) "feel" better when playing guitar. There is a lot of subjectivity in the guitar playing world and I am definitely not immune to that.

So ... 2.8 ms round-trip time in jackd plus 1-2 ms for AD/DA conversion plus 3 ms that the sound takes to travel from the speaker to my ear (plus any latency that the brain needs to process the sound). 2.8 + 2*1-2 + 3 already gets us very close to 10 ms.

No idea what I am getting at here, but I am on my third generation of modelling amps (cheap M-Audio BlackBox, POD X3 Live, now Guitarix) and while I never really had an issue with the latency ... I feel like I probably would if I went back to a previous generation.

[namibj]

There is a lower threshold beyond which you won't feel the difference anymore.

Also, by replacing a speaker with headphones, there is enough latency budget from that that can be spent on lightspeed delay for 100+km distance, if optimizing the audio stack for deep-sub-millisecond delays using RT_PREEMPT. Yes, this precludes USB2, but modern computers have quite decent on-board audio codecs (aka A/D + D/A engines) that end up connected to the southbridge and are accessed via PCIe. That has sub-microsecond latency between the digital side of the A/D + D/A converters and the CPU cache.

I guess I mostly just wanted to say "RT_PREEMPT reduces jitter enough to allow sub-millisecond AD->jackd(mixer only)->DA without much effort using modern onboard audio", and to show that is truly little in sound wave path length.

[fho]

> replacing a speaker with headphones

That makes perfect sense! I am aware of the issue ... but apparently I never put two and two together there :-)

USB Audio 2.0 on USB 3.x is actually quite decent. But honestly I have no clue what actually changed there over USB Audio 1.0.

[namibj]

"the issue" refers to the audio latency of speakers, I assume? If not, please elaborate; my understanding of the matter in practical/human terms is fairly fuzzy due to most of this being very domain-specific knowledge I haven't been in the right places for.

Oh, I know USB-attached-SCSI (the good USB3 storage protocol) is nice in latency due to actually exploiting the dedicated TX/RX lanes for latency benefits. It just shoves command packets towards the drive, and receives response packets when the drive has them ready.

However, USB still has comparatively severe driver overhead due to the MMIO-level protocols, to a similar (but iirc worse) extend as AHCI (with NVMe being the better replacement).