>On a typical PC JACK can get that delay down to the almost imperceptible where a typical non-realtime audio framework struggles to keep it sub-second.
Ouch. My only experience with lowish-latency audio on Linux was back in 2005 when I was trying to make WoW in Wine as responsive as possible. At the time, the buffer could be squeezed down to about 90ms, but any lower would risk very occasional underruns when under heavy load (and always caused by disk activity, not CPU) - becoming quite frequent underruns by the time you got to a target latency of 50ish. Using rt could push it a couple of 10s of ms lower but wasn't really necessary for gaming and came at a cost in throughput.
If we now need rt scheduling to avoid being several times worse than we were on cheap hardware years ago, then something is surely wrong. I wonder if this difference is due to software, or the continued decline in quality of audio hardware (eg. all mixing is done in software nowadays because the hardware can't do it).