Probably not.
The CONFIG_PREEMPT_RT seems to come from the RT patch, so if you’re running -generic you’re not supposed to have that line.
-generic has CONFIG_HZ=250
The thing is; I’m using the 20.04 Xubuntu Live USB, with the default 5.4.0-26-30-generic kernel, and I’m not having any problems running jack at rtprio 95.
So at least one step further. Changing the Kernel config I got now a Kernel with Real Time Preemption.
Result of realtimeconfigscan with the rltprio issue still there:
/realtimeconfigquickscan$ perl ./realTimeConfigQuickScan.pl
== GUI-enabled checks ==
Checking if you are root… no - good
Checking filesystem ‘noatime’ parameter… 5.4.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors… CPU 0: ‘performance’ CPU 1: ‘performance’ CPU 2: ‘performance’ CPU 3: ‘performance’ CPU 4: ‘performance’ CPU 5: ‘performance’ CPU 6: ‘performance’ CPU 7: ‘performance’ - good
Checking swappiness… 10 - good
Checking for resource-intensive background processes… none found - good
Checking checking sysctl inotify max_user_watches… >= 524288 - good
Checking access to the high precision event timer… readable - good
Checking access to the real-time clock… readable - good
Checking whether you’re in the ‘audio’ group… yes - good
Checking for multiple ‘audio’ groups… no - good
chrt: Festlegen der Richtlinie für PID 0 ist fehlgeschlagen: Vorgang nicht zulässig
Checking the ability to prioritize processes with chrt… no - not good
Could not assign a 80 rtprio SCHED_FIFO value. Set up limits.conf.
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Checking kernel support for high resolution timers… found - good
Kernel with Real-Time Preemption… found - good
Checking if kernel system timer is high-resolution… found - good
Checking kernel support for tickless timer… found - good
In which case Ardour does not start. Arodur asks jack to create realtime client threads for processing, and if jack cannot provide those Ardour cannot run.
Ardour’s ALSA backend can work, there is only a warning.
PS. Are you certain that is is a kernel config issue, and not just another instance of systemd ignoring /etc/security/limits*?
The problem with Ubuntu 20.04 is neither a kernel nor a limits problem per se but seems to be something with upgrading from an older Ubuntu version. Or maybe Stefano and wunder have done some customization of their own which makes it misbehave.
A fresh Xubuntu 20.04 install can run real-time Jack, after adding the limits.conf entries and logging out and in.
One thing came to mind; a fresh install gives you jack2, aka jackdmp 1.9.x
If you have jack1, aka jackd 0.12x, installed and then upgrade to 20.04 it probably installs the same jack1 and maybe the 20.04 version of that is buggy.
Ardour works fine without realtime jack, as long as you’re starting jack manually before ardour.
If you’re starting jack through ardour it has to be able to run at realtime.
Solved. Thanks for your support, gents. I wasted a lot of time, but learned a lot
I removed an openmpi packet with an /var/lib/dpkg/ error and removed snapd which caused some apparmor issues.
So something completely different. Now everything runs as expected.
Couple of things:
I removed snapd. Left apparmor. I had a broken package unable to repair or to remove and fixed that. I remember I removed some docker files (I forgot to mention here).
For me realTimeConfigQuickScan from github helped me finding out some issues.
I added those files to the kernel config in \boot
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y
I also changed CONFIG_AUDIT=n to no from yes. That was due to the fact that I got the EPERM error in:
trace chrt -f 80 true 2>&1 | grep sched
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
sched_setscheduler(0, SCHED_FIFO, [80]) = -1 EPERM
I also copied some files from my HDD to etc/pam.d/
If you checked ulimit -r and the other stuff Pedar mentioned it might be the first points I mentioned. Try removing docker as well I have no docker file left.
So I ran the reltimeconfigquickscan script and corrected all of the issues I can. my failures were the cpu governors, swapiness, max_user_watches, rtc accessability, and hpet readability. The only two still standing are teh sched_fifo limits.conf check, which I don’t get because ulimit displays unlimited memory and a 95 value for rt for my account, and “kernel with real time premption not found” which I don’t get because I’m using the same stock 20.04 kernel as you are. Here’s my current results:
== GUI-enabled checks ==
Checking if you are root… no - good
Checking filesystem ‘noatime’ parameter… 5.4.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors… CPU 0: ‘performance’ CPU 1: ‘performance’ CPU 2: ‘performance’ CPU 3: ‘performance’ - good
Checking swappiness… 10 - good
Checking for resource-intensive background processes… none found - good
Checking checking sysctl inotify max_user_watches… >= 524288 - good
Checking access to the high precision event timer… readable - good
Checking access to the real-time clock… readable - good
Checking whether you’re in the ‘audio’ group… yes - good
Checking for multiple ‘audio’ groups… no - good
chrt: failed to set pid 0’s policy: Operation not permitted
Checking the ability to prioritize processes with chrt… no - not good
Could not assign a 80 rtprio SCHED_FIFO value. Set up limits.conf.
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Checking kernel support for high resolution timers… found - good
Kernel with Real-Time Preemption… not found - not good
Kernel without ‘threadirqs’ parameter or real-time capabilities found
For more information, see https://wiki.linuxaudio.org/wiki/system_configuration#do_i_really_need_a_real-time_kernel
Checking if kernel system timer is high-resolution… found - good
Checking kernel support for tickless timer… found - good
== Other checks ==
Checking filesystem types… ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card’s IRQ by looking at ‘/proc/interrupts’ and lspci.