I'm not sure, but that's a different issue. The latency problem with everything except linux is we can't tell the OS to elevate our audio apps priority above the rest of the kernel, so operating system calls randomly happen and jump in front of the audio callback, hosing latency. I used to get 0.7ms latency on linux with the CPU at over 90%!!! I'm lucky to get 7ms on OSX with the CPU at 30-40%ms, sigh. It sucks so bad, it's like being allowed to use 1/4 of your computer power for real time audio. Even Windows 98 was better, you could tweak it pretty well. If you put your audio latency down to 2-3ms nowadays you can use very little of your CPU without under-runs. :-/
Well I'm no OS dev, so I will happily defer. But I was under the impression that this would not change the fact that a host audio app is running under user-space and can be pre-empted anytime? The way most pro-audio apps work is they have a callback they run once per audio vector size to fill a buffer of samples for the next buffer to pass to the audio subsystem. So if this gets knocked down the priority list, you get problems. Man I'd love to see any developments to improve that though, on an OS level we've been stalled for 20 FREAKING YEARS now. :-/
