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
logout
Now logout of your user and login again.
Now open the terminal and type
ulimit -l
It should now say unlimited.
Now type: ardour3
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
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 pam_limits.so
Now you need to relogin and the warning message should be gone.
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?
@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 pam_limits.so” 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.)
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.
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?
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).
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.
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.
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.
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.
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.
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.
The example assumes that you want Ardour to be able to use max 10 GB of memory (memlock). The username in the example is: mika
Nano is a text editor and you save text in it by pressing ctrl + o and enter.
You exit from nano by pressing: ctrl + x
First open a terminal window and then you open config files in the nano editor and edit them.
Add the following lines to limits.conf: sudo nano /etc/security/limits.conf @audio - rtprio 99 @audio - memlock 10000000
Add the user that is going to be running Ardour to the group: audio sudo usermod -a -G audio mika
Add the following lines to 99-sysctl.conf: sudo nano /etc/sysctl.d/99-sysctl.conf
vm.swappiness = 10
fs.inotify.max_user_watches = 524288
Reboot
If you have a USB audio interface it is best to let it have its own USB - bus if possible. Connect the device in each of your USB - connectors and then list USB - devices to see if you found a connector that has its own bus. My “Alesis” audio device is connected to Bus 2 that has no other devices on it.
USB devices can be listed with: lsusb
Bus 001 Device 008: ID 0835:8502 Action Star Enterprise Co., Ltd
Bus 001 Device 007: ID 0835:8500 Action Star Enterprise Co., Ltd
Bus 001 Device 006: ID 04d9:1702 Holtek Semiconductor, Inc. Keyboard LKS02
Bus 001 Device 005: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button)
Bus 001 Device 004: ID 0835:8501 Action Star Enterprise Co., Ltd
Bus 001 Device 003: ID 0835:8500 Action Star Enterprise Co., Ltd
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 13b2:0071 Alesis
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
For plugins search for https://aur.archlinux.org/ For example to install invada plugins do the following:
I’ve been using Manjaro with Ardour for about two years now and had no problems. Manjaro makes it easy to install several kernel versions also realtime - kernels. I use Ardour only to record and edit audio (no midi) and I found that the default non-realtime kernel works fine in this workflow. Realtime kernel might be useful when using midi. If you use a proprietary graphics driver, then you are limited to the kernel versions that it supports. Support for new kernel versions lags a little behind.
