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
I think I’ll try a fresh installation on a VM to see if the problem persist
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.
@pterodattero and @wunder_musiker what does jackd --version say?
jackd --version
jackdmp version 1.9.12 tmpdir /dev/shm protocol 8
I played around with pam.d files as well, but without success so far.
I did try something with systemd/system.conf as well, but can’t remember. At the moment it looks like this:
ps -eLo pid,cls,rtprio,pri,nice,cmd | grep -i irq
9 TS - 19 0 [ksoftirqd/0]
18 TS - 19 0 [ksoftirqd/1]
24 TS - 19 0 [ksoftirqd/2]
30 TS - 19 0 [ksoftirqd/3]
36 TS - 19 0 [ksoftirqd/4]
42 TS - 19 0 [ksoftirqd/5]
48 TS - 19 0 [ksoftirqd/6]
54 TS - 19 0 [ksoftirqd/7]
165 FF 50 90 - [irq/9-acpi]
183 TS - 39 -20 [vfio-irqfd-clea]
184 FF 85 125 - [irq/16-ehci_hcd]
185 FF 84 124 - [irq/23-ehci_hcd]
186 FF 85 125 - [irq/32-xhci_hcd]
187 FF 84 124 - [irq/33-xhci_hcd]
188 FF 83 123 - [irq/34-xhci_hcd]
189 FF 82 122 - [irq/35-xhci_hcd]
190 FF 81 121 - [irq/36-xhci_hcd]
191 FF 80 120 - [irq/37-xhci_hcd]
192 FF 79 119 - [irq/38-xhci_hcd]
193 FF 78 118 - [irq/39-xhci_hcd]
194 FF 79 119 - [irq/12-i8042]
195 FF 80 120 - [irq/1-i8042]
196 FF 50 90 - [irq/8-rtc0]
282 FF 50 90 - [irq/18-i801_smb]
295 FF 50 90 - [irq/16-mmc0]
296 FF 50 90 - [irq/19-firewire]
298 FF 49 89 - [irq/16-s-mmc0]
300 FF 50 90 - [irq/41-ahci[000]
517 FF 50 90 - [irq/42-mei_me]
583 FF 50 90 - [irq/43-i915]
588 FF 50 90 - [irq/44-iwlwifi]
590 FF 49 89 - [irq/44-s-iwlwif]
605 FF 90 130 - [irq/17-snd_hda_]
623 FF 90 130 - [irq/45-snd_hda_]
1212 TS - 19 0 /usr/sbin/irqbalance --foreground
1212 TS - 19 0 /usr/sbin/irqbalance --foreground
1822 FF 50 90 - [irq/40-enp0s25]
7742 TS - 19 0 grep --color=auto -i irq
Strange then. Starting Ardour 6.0.rc1.114 with QJackCtl Realtime off. Ardour is running connected to Jack.
Ardour: ./waf configure --freedesktop --lxvst --lv2 --prefix=/usr/ --no-phone-home --optimize –with-backend=alsa,jack,dummy --libjack=weak
Does ulimit -r say something like 95 or does it say 0 ?
If it’s 0 you have to set up limits.conf according to the link given by the realTimeConfigQuickScan.pl and then log out and in again.
I have a feeling you’re looking at the lower level stuff and are ignoring the #1 item on the Jack realtime list.
95 That’s what is strange
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.
What does whoami ; ulimit -r ; chrt -f 80 echo Yes RT say?
Also, what does strace chrt -f 80 true 2>&1 | grep sched_ say?
chrt: Festlegen der Richtlinie für PID 0 ist fehlgeschlagen: Vorgang nicht zulässig
In other words: Doesn’t work.
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 (Vorgang nicht zulässig)
Yeah, I have no idea why it doesn’t work.
If ulimit -r = 95 then chrt -f 80 should work.
It could be some weird cgroup thing but I have no idea how to troubleshoot that.
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.
Can you tell me what you did exactly? I’m dealing with the exact same issue after a 20.04 upgrade!
I’ve completely purged snap and have disabled apparmor and still no dice.
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.
Good luck.
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.
FFS looks like my upgrade didn’t include linux-lowlatency. installing now. will reboot and report.
Installing linux-lowlatency did the trick.