Best kernel for Ardour

Installation & Configuration Linux
#1

Hi, which is the best kernel for Ardour: Generic, LowLatency (PRE-EMP) or RT?

#2

The RT kernel is generally the most desirable. There are complications with some systems, notably if you use the proprietary Nvidia graphics drivers (not insurmountable complications, but they can still be a bit more of a headache than you may anticipate).

1 Like
#3

My system in based on ā€œAMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfxā€.

#4

I would advocate against using the RT kernel on a personal computer unless other kernels donā€™t work out for you.
Try the generic kernel first and if you donā€™t get satisfying results go for low-latency and then real-time.

2 Likes
#5

What kind of problems an RT kernel introduces?

#6

Well it can be a hassle to maintain, I did experience issues with nvidia drivers (as Paul already mentioned), and it is overall not suited to everyday use.
If you really need super low latencies, I guess configuring a system with a real-time kernel is better, but generic kernels do work well enough for my personal use. Especially considering my computer is not dedicated to music production only.

1 Like
#7

In my case the maintenance is really an apt-get upgrade every now and then, just to have up-to-date firmware modules. Also I donā€™t have an nvidia card, so it all boils down to overall not suited to everyday use. What do you mean with that?

With my audio interface it seems that I cannot go under 256 / 3 periods @ 48kH (I havenā€™t tried really hard). It is low enough for my needs. Maybe I should try with the stock kernel to see if something changes.

Does the RT kernel influence also the general DSP performance (meaning x-runs)?

#8

As someone with a lot of experience with this and someone who advocated and provided RT Kernels longer than any other Audio Distro I suggest with modern 4+ multicore CPUā€™s and with nVidia hardware pretty much needing proprietary drivers since Nouveauā€™s nVidia driver is getting less relevant and more buggy in MOST cases the RT Kernel is not the way to go any longer.

Lowlatency or a performance tuned kernel like Liquorix is probably the first place to lookā€¦ Often latency problems are due to other factors (IRQ sharing, IRQ prioritization, Buggy Broadcom WiFi drivers, missing ā€˜threadirqsā€™ Kernel boot codes and using the wrong CPU Governor). Once those are evaluated then a RT Kernel may be the next place to look but it is definitely a shrinking needā€¦

4 Likes
#9

Yes, for USB devices this is the rule of thumb.

If you require latency lower than 256 / 48kHz, then you very likely need a preempt-rt kernel.

This corresponds to ~10ms round-trip, which coincidentally is the latency an average human can easily cope with (~3.4 m of sound in air, a distance common between performers stage; or between guitarist and speaker).

Back on topic, a lot of the rt-patch has been merged into mainline, particularly threadirqs. In most cases vanilla linux with rtirq is sufficient.

However if you perform live on stage or have customers, you may still want preempt-rt just because it improves overall reliability. ā€“ One reason against preempt-rt is that overall power consumption increases (bad for laptop batteries). Also the reliability comes at the cost of reducing overall peak performance. And then there is this annoying Nvidia license conflict that others already mentioned.

1 Like
#10

Doesnā€™t rtirq require configuring with PREEMPT (what OP noted as low latency)? Or those are orthogonal? Perhaps I am confusing rtirq with something else.

Is that still the case if no processes are requesting RT scheduling?

#11

rtirq is a tool that sets IRQ priorities. It only requires the kernel boot option threadirqs.

There are two variants of this:

Realtime scheduling does not require a preempt-rt kernel. Realtime scheduling is available on all Linux systems no matter what kernel they use.

preempt-rt allows to interrupt low level kernel routines which are otherwise atomic. e.g. a sound-card IRQ can stop an ongoing video-driver procedure instead of waiting for it to complete. There is additional scheduler overhead among other things fewer idle states.

So yes overall power consumption is significantly larger. I get 2 instead of 13 hours on battery by just booting into a different kernel (debianā€™s linux 5.10.0-8-rt) under normal operation. However compiling Ardour can drain the battery even faster regardless of kernel :slight_smile:

1 Like
#12

The best kernel IMO is Preempt/RT without Bluetooth, WLAN or any other time-critical stuff. Itā€™s usually sufficient to turn these options off but if you know what you are doing you might run lsmod as root, delete modules you do not need with modprobe -r and run depmod -a afterwards to keep them from loading until needed.
Iā€™d prefer low-latency over RT because -as said before- real-time systems can be a major PITA. Once a real-time process goes slightly out of sync it will exit. So you might easily end up with a system that causes you much more trouble than one thatā€™s not insanely responsive but stable.

#13

I am not sure what youā€™re describing here. It has nothing to do with the kernel. As x42 mentioned, RT scheduling is available with all kernels. The RT kernel just makes RT scheduling a bit more RT. The ā€œout of sync ā†’ exitā€ behavior is application specific and is not a problem with Ardour or any other application I know of.

#14

To elaborate on this.

The first is a ā€œstartup scriptā€. It runs once when the system boots and sets everything up. Easy. It is also packaged by most GNU/Linux distros as ā€˜rtirq-initā€™ and comes with a good default config that works directly.

But that fails if the soundcard is not yet connected at boot, or un/re-plugged later. Also on laptops with suspend-resume, IRQ priorities can be reset on resume. This is where the udev script comes in.

#15

a performance tuned kernel like Liquorix is probably the first place to lookā€¦

+1. Iā€™ve also had good results with the zen scheduler in liquorix.

2 Likes
#16

+2 for Liquorix. The only kernel that really worked well and consistent for me.

Most important for me is being able to deal with multiple soundcards (Behringer UMC404HD, UMC202HD and my Katana 100 mkII via USB) and USB/MIDI devices (Millenium HD120 eDrum kit, M-Audio keystation), and still have a latency that is acceptabel to deal with in a live session.

I use all above mentioned gear at the same time without any real glitches and with no noticeable latency.

My systeem is AMD Ryzen 2700, AMD Vega 56 graphics, 32GB Ram (4 x 8GB @ 3200mHz). Canā€™t use to much filters and effects though, makes things crash, but that can be done after recording a session without to much problems.

1 Like
#17

Count me in for Liquorix praise. Itā€™s the one kernel Iā€™ve run which has not crashed on me, and hibernation is also working reliably. Also the one which can run lowest latency most stably.

#18

A competitor to liquorix is xanmod which provides a few flavours of the linux kernel.

There is also this hint in the pipewire WIKI:

" How Is PipeWire Going To Avoid Xruns?

  • All the regular system tuning you might do to avoid or reduce xruns still apply, for now.
  • PipeWire uses a thread with real-time priority, eventfd and epoll in the data processing path. This does not fix avoid the underrun/overrun problems but using simple primitives allows the processing pipeline to run on a real-time kernel subsystem like EVL. This might be to solution in the long term to avoid xruns."

See Overview :: Xenomai 4 for an interesting read on realtime kernel.

#19

I use debian rt kernels for my audio workstation and work fineā€¦ i get some xruns sometimes, but nothing to worry about. I have a beringher 404hd

#20

I am a bit late with this reply as I just saw it in Ardour Forum summary.

Things happens with the kernel drivers.
I would say kernel 5.15.10-rt24 is a good choice. It is the first 5.15 kernel after 5.15.7 with rt patches. I tried 44.1KHz, 16 samples, 3 periods, 0.4ms. no xruns.

Unfortunately you need to patch and kompile the kernel yourself.

From the Changelog for kernel 5.14.2
The recent change for low latency playback works in most of test cases
but it turned out still to hit errors on some use cases, most notably
with JACK with small buffer sizes. This is because USB-audio driver
fills up and submits full URBs at the beginning, while the URBs would
return immediately and try to fill more ā€“ that can easily trigger
XRUN. It was more or less expected, but in the small buffer size, the
problem became pretty obvious.

Fixing this behavior properly would require the change of the
fundamental driver design, so it's no trivial task, unfortunately.

and here is from the Chalngelog for kernel 5.15.7 (actually a much longer explanation)

This is another attempt to improve further the handling of playback
stream in the low latency mode.  The latest workaround in commit
4267c5a8f313 ("ALSA: usb-audio: Work around for XRUN with low latency
playback") revealed that submitting URBs forcibly in advance may
trigger XRUN easily.  In the classical mode, this problem was avoided
by practically delaying the submission of the actual data with the
pre-submissions of silent data before triggering the stream start.
But that is exactly what we want to avoid.