I’m facing problem to create new sessions after installing Ardour-5.0.5. I receive a message “Could not create session in <session_path>”.
Additionally, as I opened Ardour5 via console, here it is the output collected.
Errors/Messages:
ERROR: JACK: Cannot use real-time scheduling (RR/5)(1: Operação não permitida)
ERROR: JACK: JackClient::AcquireSelfRealTime error
INFO: Loading keybindings from /opt/Ardour-5.0.5/etc/ardour.keys
INFO: Loading bindings from /opt/Ardour-5.0.5/etc/ardour.keys
Loading menus from /opt/Ardour-5.0.5/etc/ardour.menus
ERROR: JACK: Cannot create thread res = 1
Your system is not configured for real time scheduling. You are using JACK2, which refuses to start if realtime scheduling does not work.
Fix your system configuration and it will work again. Alternatively, use the ALSA backend to Ardour. You should fix your system, because Ardour needs RT scheduling no matter which audio/MIDI backend it uses.
I have vs 4.6.0, as packaged Sarah’s Software Manager. Took a while to deduce it would load correctly (without errors) only in superuser mode after entering ulimit -l unlimited. Maybe some of you lgeeks can tall me why this is so? Now to figure out how to get some stuff (synths, sounds . . . ) or quit feeling irretrievably stupid. (Sarah’s Software Manager tries to protect us novices from our ignorance but somehow they missed that one.)
@DickyA: you should never run Ardour as root. If it won’t run without being root, your system is not configured correctly (the link is still relevant and should be read).
Thank you for your reply. I am able to set ulimit -l unlimited while in superuser mode. Then ulimit -l returns unlimited. Log out of superuser and ulimit -l returns 64. That is not good enough to load Ardour4 without many complaints. There does not seem to be a way to retain unlimited in user mode. 64 seems to be tops. I have no inkling about how that situation might be configured away. I suspect it is a feature of Sarah (Mint 18). Or maybe of my computer Dell Optiplex 740 with 6 GB memory and slightly more than that of swap. Maybe you will hear more about it as Sarah gets popular - your vs 4.6.0 is very easy for dummies like me to install from Sarah’s Software Manager (easy, like in Windows).
The problem is RR/5 being used as realtime priority. jack-process threads use the configured value and the 5 below it, which results in jack trying to create a thread a invalid priority “0”.
New qjackctl (0.4.0 or later) does no longer allow one to configure 5 or less and jack’s default is 50 (at least jackdbus, don’t know about others).
I just had this problem too. It would be really good if the RT priority problem was included in the error message - as it stands, the error message just looks like a permissions problem, and so it’s impossible to fix without searching for the error on the console.
That’s tricky. The issue is actually in libjack. Ardour asks JACK to create process-threads and JACK fails to deliver… The error message that you see in the terminal is generated by libjack.
But you do have a point, Ardour could show a “best guess” in the popup dialog.
On Linux Fedora 29 I just disabled realtime in qjackctl, now I can create sessions as normal user. (Ardour 5.12.0, jack-audio-connection-kit-1.9.12-6, qjackctl-0.5.5-2)
If however dropouts will never be a concern for you, then you may not need to worry about it, but if youa re dealing with recording at all you REALLY should get realtime permissions set up correctly.
thanks, yeah, you’re right of course. I was just sharing this quick-fix method, dropouts are currently not a problem for me - just recording some speech.
Ardour’s error message when it fails to create a session is really very misleading, this should be addressed.
by the way, networking causes dropouts on my Fedora 29 - so I recommend disabling all networking. there’s a GUI switch in my task bar / panel to do so. maybe jackd with realtime would fix this, but I haven’t investigated (yet).
ERROR: JACK: Cannot set scheduling priority for RT thread res = 22
$ groups
(audio is listed)
My /etc/security/limits.d/audio.conf reads like this:
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
@audio - rtprio 95
@audio - memlock unlimited
#@audio - nice -19
Here is the output of realtimeconfigquickscan:
$ perl realTimeConfigQuickScan.pl
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 5.4.7 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
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... not found - not good
Kernel without real-time capabilities found
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#installing_a_real-time_kernel
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
SOLVED
Seems like one has to untick realtime in QjackCtl, works fine then.
This really isn’t solving the issue as much as ignoring it. This tends to indicate that your system is still not configured correctly for realtime audio, so if you are planning on recording on it, this can be important.
Based off your post this part is where I might focus:
Typically a true realtime kernel isn’t needed these days, but if your kernel is not configured properly it can prevent realtime usage of your system. What distribution are you using, and if you know where did you get the kernel from?
Everything else looks pretty good based off what you have posted, but you apparently aren’t getting realtime permissions still and that could be a cause.
Hi Seablade, thanks for looking into this. I was kind of afraid this is the answer.
Take a look at this thread on the Pd-mailinglist by Jonghyun Kim in 2015, he had the same issue and nobody put him on the right track. He concluded unchecking realtime is the solution, just like me.
I am on kubuntu 19.10 with a 5.4.7-050407-lowlatency kernel
True, that was some time ago and at that time IIRC Ubuntu especially was a bit of a mess in terms of realtime permissions, so it may or may not be related to what you are running into.
The following applies if the kernel is the issue, which I am not 100% convinced on, but not in easy access of a Linux machine right now to confirm.
I hate to suggest to anyone that isn’t very familiar with Linux to try a different Kernel, but in this case that may be the best option. I generally tend to suggest the KXStudio repos: https://kx.studio/Repositories for most audio usage on Ubuntu or Debian based distros, but only do this if you are very comfortable with linux in general. But it should have an appropriate kernel precompiled in it that you could use that should fix that issue, and generally tends to have a better selection of precompiled packages for audio usage.
Or, an alternative if you have not set up to much on your system, try AVLinux as a distro rather than Ubuntu, as AVLinux is generally set up out of the box for this purpose and is a good distro for audio and multimedia usage because of this. http://www.bandshed.net/avlinux/