4 Jun
2020
4 Jun
'20
8:41 p.m.
Thanks for the clarification :)
Guess I just got too used to the Arch stock kernel (preempt but not RT)
which performs reasonably well for my applications and on my hardware.
But that of course might vary between distributions.
Paul Davis wrote on 04.06.2020 15:09 (GMT +02:00):
On Thu, Jun 4, 2020 at 3:26 AM
<nik(a)parkellipsen.de> wrote:
Hmm I never felt any advantage using RT kernels,
either, at least in the
recent
years, so I wonder if they still have any advantage in 2020 ? And that's
not a rhetorical
question, I really wonder what contemporary use cases for RT kernels in
the audio world are.
I feel like these kernel-tuning approaches date back to times when
desktop
responsiveness
etc. were much more serious issues. Might be wrong here, of course.
This is wrong. The behavior of a "normal", "low latency" and
"preempt-RT"
kernel are all different, and for realtime audio work, the correct
behavior
is only going to happen with a "preempt-RT" kernel.
However ...
The behavior of the normal and "low latency" kernels have changed over the
years too, and on *some* systems (from a hardware perspective), they will
function similarly enough to a "preempt-RT" kernel that a realtime audio
workflow will be just fine. In addition, the "behavior" gap between a
"preempt-RT" kernel and a normal kernel will be less and less apparent as
the latency settings (buffer/period size) become more relaxed (i.e. grow
larger).
How do you know which systems this is true for? You just have to try it.
It
is a complicated mixture of many different aspects of the hardware.
There's
an overview of the kinds of things that can contribute to the need for a
"preempt-RT" kernel here:
https://manual.ardour.org/setting-up-your-system/the-right-computer-system-…
<https://lists.linuxaudio.org/listinfo/linux-audio-user>