I just updated to version 7.3 and got the following message (which I had never seen before):
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.
For best results, please correct this on your system.
(Hint: check /etc/security/limits.conf or /etc/security/limits.d/)
Here is my /etc/security/limits.d/audio.conf:
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
# dpkg-reconfigure -p high jackd2
@audio - rtprio 95
@audio - memlock unlimited
#@audio - nice -19
Start a Terminal and run groups ; ulimit -r
You should see that you are in the audio group and that your rtprio is 95.
If not it may be as simple as logging out and in again, to applying the audio.conf settings to your user
I do get that the user is in the audio group and that rtpio is 95. But both were already true during the update, so I am wondering why the Ardour installer gave me the message above. Is it a problem with the installer or with my system?
If you’re only getting this message from the installer, I wouldn’t worry about it. I used to get messages from the installer that Jack was missing even thought that was not true.
The installer did not change with this release and that particular test has not changed in years.
The installer runs a small program to just check and see if it can create a realtime process. It would be interesting to run it on your system again and see if it still fails.
You can run the command from a terminal.
/opt/Ardour-7.3.16/bin/sanityCheck -a
Your Ardour version may be different, so you will need to adjust the path to suit.
Did you compile the kernel or did you get it from somewhere else?
Copy in /boot/config- and we can help verify that you have the right config options to enable RT scheduling. Perhaps you inadvertently disabled that.
PREEMPT_DYNAMIC is a new kernel feature and it may not behave in the way that older kernels have. Although this may change over time, I don’t believe from the little I have read that this kernel configuration option is ready for mainstream use just yet. I could be wrong.
I also notice this difference between your config and the config on my machine:
CONFIG_RT_GROUP_SCHED=y
My kernel does not have CONFIG_RT_GROUP_SCHED set.
I believe that config option brings cgroups into the RT permissions. I may be wrong about that, some pages I have found indicate that cgroup limiting RT scheduling would only be a problem for system services, not for user software.
The config option which Paul mentioned is for changing between none/voluntary/preempt config at boot time, but according to this article it will default to preempt, so should be the same as compiling with CONFIG_PREEMPT defined if you do not change the kernel command line. Phoronix dynamic preempt article
That was two years ago, so I don’t know how new I would consider that feature. I guess it depends on how conservative you are with your kernel choices. It is set on my kernel config, and I did not even realize my distribution (Fedora) had switched to setting that config option, so I don’t think it has been very problematic.
I just had a few minutes to search through cgroup information, I did not find anything definitive. I cannot say with much confidence that will be a useful path to search, just that it is the only difference which stands out from my config, which does allow my applications to request RT scheduling.
Thanks Paul and Chris for the informative replies.
Interesting… On the other hand, an older 6.0.0-8 version of the slh kernel also says PREEMPT_DYNAMIC, but it does pass the test.
It seems that all my recent slh kernels have this option enabled, including the version 6.0.0-8 mentioned above, that passes the check.
It seems that some change from 6.0 to 6.1 caused the change (failing the test), as older versions of 6.1 also fail.
So, my question now is: does Ardour’s test really test the systems capability or does it test for “something expected”? If the latter, I can just test it and see if it works well enough. If the former, I would likely try to find a fix.
(Well, I guess s fix is to run some other kernel… Debian’s official rt kernel passes the test as well.)
After installing rtcqs, and some fixes, the problem that still remains is
RT Priorities
=============
[ WARNING ] Could not assign a 80 rtprio SCHED_FIFO value due to the following error:
[Errno 1] Operation not permitted. Set up limits.conf.
See also https://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
On the other hand, I do have have/ etc/security/limits.d/audio.conf set :
$ cat /etc/security/limits.d/audio.conf
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
# dpkg-reconfigure -p high jackd2
@audio - rtprio 95
@audio - memlock unlimited
#@audio - nice -19
Not only that, once (a couple of days ago) I checked rtcqs again and the RT test passed (as well as Ardour’s sanityCheck!), while I really don’t think I had done anything that would affect it.
Coincidentally I ran into a similar or maybe just this problem just a few days ago, on a new install of openSUSE Tumbleweed on Raspberry Pi 4. All set up well, but chrt not able to raise RT priorities …
I googled a while and found hints about /proc/sys/kernel/sched_rt_runtime. I set this from 950000 to -1, reloaded sysctl and chrt started to work. To make it permanent I added this line in /etc/sysctl.d/60-inotify_swappiness.conf where I keep the other suggestions from rtcqs:
kernel.sched.rt_runtime_us = -1
Funnily, on my laptops this setting is unaltered, also at 950000 and chrt works well so I really don’t know if this is of any help to you, I just wanted to add my experience…
Thanks! I haven’t be able to try it very carefully yet, but that seems to work! I googled that around and could not find the solution, so thanks for sharing!