linux-rt, linux-rt-lts, linux-lqx(Liquorix) and linux-rt-bfq, which is the best?...

[funkmuscle]

linux-rt, linux-rt-lts, linux-lqx(Liquorix) and linux-rt-bfq, which is the best for proaudio?
I'm currently using linux-rt-lts but I've noticed the others available in AUR.
Just wanna know if anyone getting good performance with any of these? No only Arch but whatever distro.

[English Guy]

Liquorix gave me less xruns than rt, so that is what I use (Debian stable)

[progwolff]

I made good experiences with linux-ck (with some config changes) on Arch Linux.
Runs smoother than rt with zero xruns and less configuration effort (on my fairly new machine). Never tried Liquorix.

[gimmeapill]

I made good experiences with linux-ck (with some config changes) on Arch Linux.
Runs smoother than rt with zero xruns and less configuration effort (on my fairly new machine). Never tried Liquorix.

Interesting. I'm generally happy with -rt, but was always curious about Con Kolivas's work.
I guess I'll have to give -ck a try then

Would you mind sharing your config changes, and at which latency you tested?

@Funkmuscle: I would rather recommend -rt-lts as a fallback option for when -rt gets a major version update (and the possible peformance degradations associated). At the moment, if you try -rt, you should see some light improvement over -rt-lts. But I think they are mostly due to the newer kernel rather than the rt patchset.

[progwolff]

My config is attached. Might not be optimal though; I didn't look into it for some time now...

Minimum latency is depending on the plugins in use... 48kHz with a buffer size of 64, 3 periods/buffer using a Scarlett 2i4 on an Intel i7-6700HQ are possible.

When I get home, I will measure the roundtrip latency and report back.

[gimmeapill]

@progwolff: Thanks. I'm roughly in the same ballpark: 96khz, 64, 3p with a scarlett 2i2 1st gen on a core i5-3317u, but I'm not running much plugins with that config, and still have the occasional xrun. So this will be worth testing.

& since we are talking about custom kernels, there's one more thing to add to the list: building with 'make localmodconfig'

From the Kernel README: https://git.kernel.org/cgit/linux/kerne ... ags/v4.3.3

make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loadedmodules.

You just need to add the line to the pkgbuild after the "make *config options"

This of course helps a lot with build time and kernel size, but I also found the overall system responsiveness to be better (empirically).
https://wiki.archlinux.org/index.php/Mo ... om_kernels

The caveats, are, well...you will find out as soon as you try to use a kernel module that was not loaded at the moment you built the kernel

[progwolff]

As I use the same computer for audio and daily work ( including programming for different operating systems and hardware development ), I decided to have localmodconfig disabled.
It seems a little strange to me that this could improve the responsiveness. The modules loaded at runtime should be the same...

[funkmuscle]

I'm curious, do you guys get rid of the vanilla kernel? I never do. When I try a new kernel, I just add it to the list of bootables.
I'm asking as rollback and fallback and other answers here lead to this question.

[gimmeapill]

@funkmuscle: Nah, you're doing right: always keep the standard kernel around (well, unless you like trying out the lastest Arch bootable iso ).
The limit to the number of kernels is mainly the space available on /boot (assuming you have it as a dedicated partition), but on a default Arch Install that should be good for ~3 kernels at least.

@progwolff: Yes, the modules loaded are exactly the same, so there should be in theory no run time performance delta.
I didn't do an A/B test for a few months to be honest, but I have usually slightly faster boot times + slightly less xruns.
Running cyclictest didn't show much difference either, so I cannot throw any hard figure.

Also, localmod config doesn't always build cleanly with the linux-rt AUR pkgbuild (at the moment I'm running standard -rt), so there could be something else going on at configure time that might account for that smallish perf difference...

[sysrqer]

When I used to make my own kernel I tended to keep a good version around (not necessarily vanilla but working) if I experimented with new configs or patches. I tend not to be interested in customizing these days, I always found that in terms of speed and responsiveness there wasn't a great deal of difference with the various patches around. ck had some serious problems the last time I compiled using it so gave up on that. I like BFQ, it makes things like booting a bit slower but it's pretty smooth. With rt vs low latency (I forget what the actual term for this option is) I have noticed that the latency is slightly better with the rt patch and there are less xruns but the xruns I was getting with the low latency were mostly inaudible anyway. The lqx patches only had one significant difference the last time I looked, it seemed to make the system run in more of a performance mode (hotter, higher fan usage) but I never noticed anything drastic in performance.

These days I just use the low latency kernel, it's good enough for what I need for now. I might look at rt if I start recording audio more in the future.

One thing I will say is that these patches and the impact they have is massively dependent on the machine they are being used on. I used to have a fairly old dell laptop and I had certain strange little issues which were affected by patches and tweaks to the kernel but the new laptop I bought to replace it works perfectly well without any adjustments or tweaks.

[funkmuscle]

found a very interesting article on this topic...kinda:
http://www.akitaonrails.com/2017/01/17/ ... -computers

[gimmeapill]

OK, I did a quick test yesterday and built the latest LInux-ck with localmodconfig + bfq (the pkgbuild btw includes out of the box support for Modprobed-db which is sweet).

I got a slim kernel of ~13MB, but unfortunately it's absolutely not suitable for my config.
When trying to run Guitarix at 2ms latency (96k, 64b, 3p) it's xrun hell, I couldn't even get any sound.
Then I went to refresh my linux-rt from 3.8 to 3.9 (also built with localmodconfig) and everything runs smoothly again - with only Guitarix running I get no xrun at all.

Problems start usually when I run DAWs or soft synths at this latency: Qtractor is behaving relatively well, Ardour is no-no, Renoise is ok as long as I don't try heavy instruments or plugins (this is nothing new, just mentioning the caveats of my config).

But it's anyway comparing apples and oranges: linux-ck is at 4.10 at and linux-rt at 4.9.13.
If time ever permits, I'll try again when both are at least on the same major kernel version, and without localmodconfig.

[progwolff]

Like sysrqer said, it highly depends on the machine and on the configuration of your system.
Just changing the kernel and keeping other configs which were optimized against the old kernel will always lead to bad results.
My requirements are also quite different than yours. I rarely do any recording, but play live keyboards through plugins. With an rt kernel it was difficult to set the priorities in a way that the DE and the GUI of my plugins were still smooth and responsive. It also didn't play well with my wifi device and the graphics card.

@funkmuscle: Nice article, thanks!

[gimmeapill]

With an rt kernel it was difficult to set the priorities in a way that the DE and the GUI of my plugins were still smooth and responsive. It also didn't play well with my wifi device and the graphics card.

RT can indeed be a royal pain for the responsiveness of graphical applications, it was never exactly meant for desktop usage.
But that was never a deal breaker here: I'm not using any DE, just a plain WM with Intel graphics, so yeah, quite a few things less to care about.
Otherwise, not much really kernel specific: NOOP set for my SSD, and IRQ threading. The rest (like audio group priorities, swapiness) is pretty much transparent. I can usually figure out quite well where the stock kernel drops the ball and where RT still makes sense.

From funkmuscle's article, there's another contender to try, linux-zen.
Interesting since it's an official Arch kernel apparently similar to Liquorix, so nothing to compile:
https://www.archlinux.org/packages/extr ... linux-zen/

But overall I found this article quite misleading: it's called "Optimizing Linux for Slow Computers", yet the final word is to buy an M2 SSD and 8GB of RAM so that Gnome can keep chugging along...that doesn't really help...

[CrocoDuck]

I have tried quite a lot of kernels and what I set on are linux-lts and linux-rt-lts. On the kernel side, I prefer to have less frequent updates and a more stable environment. rt-lts works ok for me.