> I would have thought that givig the audio process full priority would have the greatest benefit. I think you're conflating two separate things. Giving full p

> I would have thought that givig the audio process full priority would have the greatest benefit. I think you're conflating two separate things. Giving full priority to an audio processing thread will ensure it will be scheduled as much as possible which increases throughput. This is crucial for things like rendering (audio or video) where the process takes in the order of minutes or hours and needs to be completed as fast possible. In the other application, such as synthesizers, virtual instruments (MIDI keyboard -> MIDI signal -> DAW -> sound wave), music notation etc you care only about latency. Human brain is hard-wired to observe even the minutest latency in music, especially in bass register, any millisecond delay will be perceptible to highly trained professional musicians. To fix this, you need to tell kernel, when it receives a signal, the thread cannot be scheduled out. Here, you don't care about throughput, but have extreme latency requirements. I, as a hobbyist composer, personally use a traditional archlinux setup for my studio. It's not real time at all. It honestly sucks, the latency is extremely noticable, which makes some applications, such as playing on my keyboard and hearing soundfonts through DAW impossible; as the latency makes me confused and prevents me from playing the keyboard properly. This is ok for me, as it doesn't distrupt my personal workflow (I have a very slow, calculated approach to composing, and when I need to improvise, I do it on my piano) so I didn't care about optimizing it. But if you're a professional musician and need good latency, something like this is can be crucial.