Hello everyone. Just got this message. Thought I’d drop a line to see if anyone can give me a basic interpretation of the meaning of this message and its implications. Then…I’m going to get in and tweak it. Thanks for taking a minute or so to consider my thoughts. Any and all feedback appreciated.
I believe this message is due to your distro not being setup for realtime scheduling. Information on how to set this up is here:
Not specifically, but the recommendation from Ardour is to not set a limit for locked memory for the audio group (the group which gives realtime permissions for audio apps, which might have a different group name, such as jack, jackuser, audiouser, realtime, etc.).
Some distributions will enable realtime scheduling permission, but limit the maximum amount of locked memory in an attempt to prevent one application from being able to lock so much memory that no other applications can run successfully.
On recent distributions that is typically set in a file in /etc/security/limits.d but could be in /etc/security/limits.conf depending on your distribution. I do not remember where Debian stores it by default, or which group name it uses by default, but check there for settings for rtprio and memlock. If Ubuntu uses the same files as Debian then it might be /etc/security/limits.d/audio.conf.
Once you find the correct file, you want to make sure the settings are like this:
@audio - rtprio 95
@audio - memlock unlimited
Again, double check your distribution to see if the group name is different, but “audio” seems like a common group name. My machine still has a “jackuser” group, so if you see a groupname with “jack” in the name, or “multimedia” or anything similar that could be the groupname on your machine.
After verifying the security file settings, make sure that your user account is part of that group. If you run the groups command it will print the groups your user account is currently using. If your user account is not part of the correct group you will have to add using your system administration tools, or using usermod if you are comfortable with command line administration tools.
Nice explanation, Chris.
The name of the configuration file on Debian will depend on what version of Debian it is, and perhaps what desktop is selected. On Debian 12, Pipewire is installed by default when the Gnome desktop is selected during installation, but Pipewire is not included if the XFCE desktop is chosen (unless this has changed in subsequent point releases). Kali may not align with this, but either way, the configuration file should be located in the directory /etc/security/limits.d/.
If Pipewire is in use, the user needs to be in the group “pipewire”. The file will either be named “25-pw-limits.conf” or “95-pipewire.conf” and should contain:
@pipewire - rtprio 95
@pipewire - nice -19
@pipewire - memlock unlimited
If Pipewire is not installed, there may be no file in /etc/security/limits.d/ by default, and one needs to be created. In this scenario, the file should be a simple text file called “audio.conf” and contain the lines below. The user needs to be in the “audio” group for this to have effect rather than the “pipewire” group. Per the JACK FAQ, the line in the Pipewire configuration files that sets the nice value is unnecessary. It is a remnant from old configuration files and irrelevant to the warning message you are seeing.
@audio - rtprio 95
@audio - memlock unlimited
Just to avoid any confusion; it really doesn’t matter what the group is called, be it “pipewire”, “audio” or “WindowsVistaWasTheBestVersion”, as long as there’s a conf-file for that particular group in limits.d and the user belongs to that group.
On my openSUSE-15.5 I only belong to the “users” group, so if I didn’t feel like creating a new group and adding myself to it I’d create entries for @users .
Or I’d skip the @ sign and just create rtprio and memlock entries for my particular username.
I also tend to limit memlock and leave out one or two GB, just to make sure the entire computer doesn’t crash if Ardour for some reason runs amok and grabs as much memory as it’s allowed to (which is “all of it” in the example).
Thank you. That part, I took care of with an install of Qjackctl. I has happy about that being built into the packaging. It was after this that I received the message. Which was strange.
Thank you for taking the time. Great resource. I appreciate your depth of understanding on this and the time you took to write it.
Thank you for the context. Much appreciated.
Thank you for the thorough explanation Chris. 
I think that is a valid configuration, but note Ardour will still warn that the setting is not unlimited.
I do not know specifically what would happen if Ardour had a bug and attempted to lock all available physical memory, but I think out-of-memory killer daemon would kill the process.
A forced kill by the OOM daemon could potentially corrupt your session, depending on what Ardour was doing when it got abruptly killed.
I don’t know if Ardour itself handles hitting the memory limit in a more graceful way but it feels to me like it’s the safer of the two alternatives.
From what I understand the warning is there to, hopefully, keep people from complaining about not being able to, for instance, load a 2GB sample library or impulse response file even though they mayhave 64GB of RAM.
As for the warning itself you can always check the “Do not show this window again” box.
It is just a warning and if you’ve deliberately not given Ardour unlimited RAM you probably don’t need to be told that every time you’re starting the program, anyway 