Realtime group scheduling doesn't know JACK

Not just audio input, any case where input passes through the JACK system to become output. That's what latency is! For example, from thumping the concert A on a MIDI keyboard to hearing the sound from the software instrument. The larger the buffer, the longer it takes.

Or consider DJing. Suppose we just have a 2 second buffer. So I hear the end of track A, there's a boring instrumental lead out, I want to play track B - must I wait 2 seconds before it begins? That's a long time. OK, so maybe we provide the DJ a separate mix. Now I can hear where track B will start playing, but it takes 2 seconds before I hear my own decisions. This is very difficult to work with.

You can play with this, if you have lab audio equipment, create a 2 second delay audio loop, where what you say is recorded and then played back quietly through headphones (so it doesn't feed back). You won't be able to hold a conversation properly, because you must concentrate very hard just to override a built-in audio-cognitive mechanism that tells you you're being interrupted. Reduce the loop to 15ms. Now it's fine. The much shorter delay resembles environmental echo, which was present when our audio cognition evolved. Latency matters.

> That's my whole point -- there is a whole world of other systems that (to me) seem much more demanding than audio processing, like video input and output, and gaming, that don't seem to have the realtime requirements or problems of JACK. I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult. And it seems like the answer is the specific case of live looping back audio from input->output which needs low latency.

It's not just _LOW_ latency.

Realtime configurations give you the ability to _CONTROL_ latency.

That's the point.

Often stuff running realtime will have significantly worse performance then if you had them in the normal configuration.

Linux is designed to provide high throughput and work efficiently under high loads. The design choices and compromises that goes into making Linux behave well and perform well under high loads is COUNTERPRODUCTIVE to providing good realtime performance.

It's not a question on how demanding the workload is, it has to do with your ability to control how often something happens and when it happens.

THAT is what realtime performance is about. Not making your system work faster, quicker, or perform better... it's just a question of being able to control latencies. Without realtime configurations you can see latency spikes up to 250msec or more on a regular basis for Linux. It's just a nature of the beast.

And of course even with Linux in 'realtime mode' it's not perfect and can't guarantee you with 100% latency control.. Linux is far too complicated for that, but it does help tremendously.

>I'm trying to understand exactly what the audio use cases are that make processing 48 KHz data so difficult.
If you're processing a lot of tracks simultaneously the throughput can be quite high. In film soundtrack work it's not uncommon to be working with a hundred or more tracks at once.

Depending on your game, you can easily replicate the problems JACK is suffering. A player can learn to see past consistent quarter-second network latencies in a fast paced game. If the apparent latency changes because the kernel wants to contemplate its navel for 100ms, however, all bets are off. You will be a sitting duck, fragbait.