Hello, maybe it is very simple.
I have a new plain Kubuntu 22.04 with kxstudio repos.
I also use the proprietary NVIDIA drivers.
what is the best way ti install the low-latency kernel?
I would prefer a command line.
Thanks in advance
Moderators: MattKingUSA, khz
Hello, maybe it is very simple.
I have a new plain Kubuntu 22.04 with kxstudio repos.
I also use the proprietary NVIDIA drivers.
what is the best way ti install the low-latency kernel?
I would prefer a command line.
Thanks in advance
@NVIDIA drivers: viewtopic.php?p=132670#p132670
That shouldn't be relevant for low-latency kernel, only RT kernel.
Why not use a modern generic kernel? Most distros use one now. With most of the real time patches incorporated into the generic kernel, it’s a simple matter of a couple of kernel boot parameters in GRUB to have most of the audio latency benefits that a custom kernel would provide—and it’s a lot easier to set up too.
Essentially, you just need the /threadirqs and /preempt=full parameters—along with granting realtime scheduling rights to your chosen audio group, and adding yourself to the group, configuring your memlimits, and configuring your preferred Pipewire settings. That’s mostly it. If you still aren’t satisfied with the already low latency, you could look into adding the rtirq script to your startup. But that’s pretty much all there is to it. IMHO, except in the most extreme of circumstances, the days of needing a custom kernel are pretty much over.
Edit: I just noticed that you are using an Ubuntu derivative. Their method of adding their already easily-provided custom kernel is easy too. you might as well use that as mentioned above. For other distro families though, I don’t see a point in the extra effort of custom kernels.
Audiojunkie wrote: ↑Sun Mar 05, 2023 5:08 amEssentially, you just need the /threadirqs and /preempt=full parameters—along with granting realtime scheduling rights to your chosen audio group, and adding yourself to the group, configuring your memlimits, and configuring your preferred Pipewire settings. That’s mostly it. If you still aren’t satisfied with the already low latency, you could look into adding the rtirq script to your startup. But that’s pretty much all there is to it. IMHO, except in the most extreme of circumstances, the days of needing a custom kernel are pretty much over.
I'm on Debian 11 so I have a pure generic kernel. I can add threadirqs to my grub options:
But, How can add the option "preempt=full" ?
That's a compile option so you need to tick it in config then compile kernel. I don't think threadirqs does anything unless you have at least
Code: Select all
CONFIG_PREEMPT=y
(I may be wrong; I was once before).
You can check with:
Code: Select all
$ grep -i preempt config-$(uname -r)
I use Liquorix kernel in Debian which has that set. "threadirqs" definitely works with Liquorix.
It is not set in default Bullseye kernel but I just checked and it does have:
Code: Select all
CONFIG_PREEMPT_VOLUNTARY=y
TBH I'm not an expert and don't know what that means. I looked it up and still don't know ( ) - https://cateee.net/lkddb/web-lkddb/PREE ... NTARY.html
This article sheds a glimmer of light through the haze - https://www.codeblueprint.co.uk/2019/12 ... ghput.html
miuzik wrote: ↑Sun Mar 12, 2023 4:57 amAudiojunkie wrote: ↑Sun Mar 05, 2023 5:08 amEssentially, you just need the /threadirqs and /preempt=full parameters—along with granting realtime scheduling rights to your chosen audio group, and adding yourself to the group, configuring your memlimits, and configuring your preferred Pipewire settings. That’s mostly it. If you still aren’t satisfied with the already low latency, you could look into adding the rtirq script to your startup. But that’s pretty much all there is to it. IMHO, except in the most extreme of circumstances, the days of needing a custom kernel are pretty much over.
I'm on Debian 11 so I have a pure generic kernel. I can add threadirqs to my grub options:
- Edit the file /etc/default/grub
- And I add GRUB_CMDLINE_LINUX_DEFAULT="quiet splash threadirqs"
But, How can add the option "preempt=full" ?
As I understand it, the preempt _dynamic functionality starts showing up in kernels as early as 5.12. I use Fedora which is already on the 6.x series of kernels. If I’m not mistaken, the default Debian kernel for 11 is only 5.10, so the functionality would not yet be available for you without moving to the Debian Testing branch. It also, as mentioned above, is a compile-time option, so it also depends on whether the distro you use chooses to compile with that option—Fedora does. Your best options are to try moving to Debian Testing (which should be pretty stable at this point), or try again when Debian 12 is released.
Audiojunkie wrote: ↑Sun Mar 12, 2023 2:36 pm...the default Debian kernel for 11 is only 5.10, so the functionality would not yet be available for you without moving to the Debian Testing branch
Your best options are to try moving to Debian Testing (which should be pretty stable at this point), or try again when Debian 12 is released.
Bullseye Backports has 6.0 and 6.1 kernels available.
Cool! If the Debian team compiled with the Preempt-Dynamic option, this would be the easiest solution.
Audiojunkie wrote: ↑Mon Mar 13, 2023 1:01 pmCool! If the Debian team compiled with the Preempt-Dynamic option, this would be the easiest solution.
I just installed it out of curiosity:
Code: Select all
$ grep PREEMPT config-6.0.0-0.deb11.6-amd64
CONFIG_PREEMPT_BUILD=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
CONFIG_PREEMPT_COUNT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_DYNAMIC=y
CONFIG_PREEMPT_RCU=y
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_CALL=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DRM_I915_PREEMPT_TIMEOUT=640
CONFIG_DEBUG_PREEMPT=y
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
So that's a yes. Haven't booted it yet, bedtime here in the land of Oz.
There's an unsigned 6.1 kernel in backports too. Should be fine unless you have Secure Boot active. May try that one tomorrow. I suspect I will stay with Liquorix though, it's been good to me.
In my recent update to Ardour 7.3, I noticed that my most recent kernel (6.2.0-5.slh.1-aptosid-amd64
) failed Ardour's test:
Code: Select all
System failed the quick sanity check... Looking for the cause
System does not allow realtime for the current user... Looking for a solution
!!! WARNING !!! - The current user can not execute realtime processes.
This will adversely affect audio latency.
This system has an audio group and the user is a member. If jack was
just installed, a simple log out/in may fix this.
The kernel does have PREEMPT_DYNAMIC
enabled:
Code: Select all
$ uname -a
Linux debian 6.2.0-5.slh.1-aptosid-amd64 #1 SMP PREEMPT_DYNAMIC aptosid 6.2-4 (2023-03-12) x86_64 GNU/Linux
(Note that I'm running basically Debian Sid with a custom kernel.)
I've posted it in the Ardour Forum, and it is not clear that PREEMPT_DYNAMIC
works well for realtime applications, although I have not tested it very much. (Fortunately, I can also run Debian's official rt-kernels.) But I'd be curious about others' experiences with preempt dynamic kernels.
I've got a PREEMPT_DYNAMIC
kernel and my user has realtime permissions. I don't think your issue is kernel related. It's the old /etc/security/limits.d/99-realtime-privileges.conf
, which is what it's called on Arch, but I think the name is different on Debian.
I get "Sanity Check Failed!" with the backports 6.0 kernel on Debian. Will reboot to Liquorix and check that.
Back in the latest Liquorix 6.1.18-1-liquorix-amd64 now.
Sanity check passes "Sanity Check OK!" when using performance governor, but fails with ondemand governor. CPU governor seems to be the critical factor.
Rebooted to the Debian kernel 6.0.0-0.deb11.6-amd64 and found the same result. Sanity check OK with performance governor and fails with powersave (this kernel doesn't have ondemand governor).
We must remember the sanity check is just a simple parameter check afaik; it doesn't check actual performance.
There's a simple GUI utility available in Debian to switch governors - cpupower-gui.
And it is well worth checking setup with rtcqs - https://codeberg.org/rtcqs/rtcqs . It would tell you to set performance governor.
I see @finotti also has an interesting thread going at https://discourse.ardour.org/t/system-d ... /108331/13