Your System has a limit to locked memory [Solution]

(Gldraphael) #1

When I ran Ardour for the first time, it never opened. I gave a warning though which read:

WARNING: Your system has a limit for maximum amount of locked memory!
This might cause Ardour to run out of memory before your system runs out of memory.
You can view the memory limit with ‘ulimit -l’, and it is normally controlled by /etc/security/limits.conf

I tried edited the limits.config but it dint seem to work

Here’s how I fixed it. Go to the terminal (Ctrl + Alt + T in some distros) and type the following:

sudo -i
ulimit -l unlimited

Now logout of your user and login again.
Now open the terminal and type

ulimit -l

It should now say unlimited.
Now type:
and it should probably work well. I find opening ardour from the terminal very advantageous because I get detailed log.

I also had to add my current user to the audio group btw


(Nick Livings) #2

You want to create an audio group and a realtime group, add your user to these groups, and make /etc/security/limits.conf like so:

  •   hard	rtprio		0
  •   soft	rtprio		0

@realtime hard rtprio 20
@realtime soft rtprio 10

@audio - rtprio 95
@audio - memlock unlimited


(Profguille) #3

I found this solution from

Trouble shooting
Limit of the maximum locked memory
When you start Ardour you may get this warning message:
WARNING: Your system has a limit for maximum amount of locked memory. This might cause Ardour to run out of memory before your system runs out of memory.
You can view the memory limit with ‘ulimit -l’, and it is normally controlled by /etc/security/limits.conf

To avoid this you have to edit the limits.conf
sudo gedit /etc/security/limits.conf
and add this line to it
@audio - memlock unlimited
To activate this change you also have to edit /etc/pam.d/common-session:
sudo gedit /etc/pam.d/common-session
adding the line
session required
Now you need to relogin and the warning message should be gone.


(Anotherashworth) #4

Conflict in my setup? Can someone familiar with Ubuntu Studio advise me?

My version of /etc/group has an audio group and my username is in that group.
I have a file “/etc/security/limits.d/audio.conf” that says…

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 jackd

@audio - rtprio 95
@audio - memlock unlimited
#@audio - nice -19

Since this is in the limits.d directory is it automatically read by /etc/limits.conf?
Should the nice line be uncommented?
What does “dpkg-reconfigure -p high jackd” that loading audio.conf does not do?


(J Rigg) #5

@mashworth - I’m not familiar with Ubuntu Studio but /etc/security/limits.d/audio.conf is the same on my Debian testing system and it’s working fine. There’s no need to uncomment the nice line as nice values don’t affect rtprio processes. Does running “dpkg-reconfigure -p high jackd” not get it working?

(BTW the “session required” line mentioned in the post previous to yours appears in /etc/pam.d/runuser in later Debian versions, so that wiki article may be out of date.)


(Anotherashworth) #6

Thanks. I made the addition to common-session based on your advice. My system has been working but I’ve experienced some glitches in exported files. I’m looking at everything short of installing a completely different distro. I’m not ready to create a dedicated “appliance” machine at this time.


(Support) #7

Perhaps paul can shed some light on this - how can there be glitches in exported audio? I don’t know of any other DAW which does this - surely when exporting (offline) - even if using JACK (in ‘freewheel’ mode) Ardour should be just handing blocks of samples to the processing chain, wouldn’t an xrun (assuming that’s what it is) indicate something very worrying at a deep level in the audio / processing stack?


(Seablade) #8


That is just it, I don’t think any developer has been able to replicate this. I can’t speak for them on this obviously, but I will say when I was more active in support, one of the first things I suggested when I heard the word Ubuntu, was to try it in another distro (And I think I remember suggesting exactly that using the LiveCD of AVLinux in a different thread to the poster) to see if the problem went away, as Ubuntu tended to break things in very subtle but very annoying ways. Granted from what I can see they have gotten better recently (Or rather Ubuntu Studio has) but I still hear about subtle issues showing up there on occasion which makes my advice still be the same. Try it in AVLinux’s Live CD and see if it goes away (No need to install, just need to boot it and open the session).


(Paul Davis) #9

Indeed, we (developers) have been unable to replicate this so far. We will be testing sessions supplied by the couple of users (mashworth is one of them) who have apparently run into this problem. Assuming the clicks are real, they are not “xruns” but likely some other DSP error, such as xfades or automation.


(Support) #10
...they are not "xruns" ...
It would make more sense (and perhaps be less worrying) if they aren't xruns - in as much as I assume that when rendering offline, it - should be - just a (very complex) numerical (and statistical ? ) calculation on a large data set. The fact that the data set can be interpreted as audio, is almost irrelevant (similarly you wouldn't expect to get an xrun from a spreadsheet when doing your accounts..) As I recall there was a tendency to get xruns in the bad old days of Ardour2, it might have also been a JACK2 issue, combined with something nasty like JAMIN doing some threadlocking in the audio callback - I hope none of that is happening anymore.

(Seablade) #11


Yes Jamin, among other plugins, did not handle freewheel very well, but like many things it depended on your setup. I used it for mastering on several projects without issue, others on the other hand had issues, but I never replicated it on my machine. Similar story with the CALF plugins and threading in libfftw not to long ago. Of course there is a question on how much Ardour can do to avoid issues in plugins, one which we hashed out back during those Calf issues, so I won’t bring them up again here.

That being said, if the issues are in fact with x-fades etc. in Ardour itself, then absolutely something can, and should, be done about it.


(Don Estabrook) #12

Hi - I’m one of the users that’s been seeing glitches (I’ll use that term sort of generically here) in exported audio, and I’ve supplied a session - which has no plugins - for analysis. There are indeed no xruns reported during export, and the glitches seem to be completely random - not at fixed locations, and not aligned with cross-fades, automation, etc. Oh, and this is on Fedora/CCRMA - so not Ubuntu.

Coming back to the OP for a moment - I’ve also wondered for a long time about that warning message. The systems I’ve been using lately have at least 8 GiB of RAM and are configured to allow locking at least 4 GiB of that. I figured that should be more than plenty (when I’ve looked, Ardour’s size has been no more than 10% of that) and I wasn’t really thrilled with the idea of allowing a process to lock all of my RAM, ya know…? Am I misunderstanding anything there? As far as I remember, I’ve never seen any error messages or crashes indicating that Ardour couldn’t actually lock enough RAM when it needed to.


(al F) #13

On lubuntu 15.10, with added kxstudio repos, I got the same “WARNING: Your system has a limit for maximum amount of locked memory. This might cause Ardour to run out of memory before your system runs out of memory.” Ardour was then unable to create a session.

Adding my user to the audio group and logout / login fixed this.


(Mikael Hartzell) #14

I used to have clicks in exported audio almost every time I exported stem mixes of a song. There was usually 1 click per about 5 - 6 exported stem files and as I usually have this amount of stems, I had clicks in every song. I used to just re-export the stem until it was clean.

I never managed to pinpoint the exact reason for the clicks. Sometimes it seemed like the cause was normalization, sometimes the file format I used (flac) and sometimes I got those clicks many times during a volume automation fade out at the end of the song. If other affected by this are using flac, then it might be perhaps be some fault in the flac library.

However this problem hasn’t happened anymore since maybe 3 - 5 months. I always used the latest version of Ardour and it seems the clicks were gone (at least for me) a couple of releases ago.

The OP posted some commands that shows that he is using Ardour 3. The 3.x series was very “clicky” so everybody should upgrade to 4.6 and try again. Also try without normalization, different file format (wav, flac) and see if it helps.


(Seablade) #15

Heh the OP was from about 3 years ago:)


(Mikael Hartzell) #16

Oops, should have checked the date before replying :slight_smile: