Ardour kills jackd on FreeBSD and cannot start it unless root user

Hi.

OS: FreeBSD 12.2-RELEASE

I installed ardour-6.3.0 via FreeBSD ports and finally successfully got it running. However there are a couple of issues. I am posting to the forum because the bug tracker would not let me setup an account. It keeps telling me

APPLICATION ERROR #2800
Invalid form security token.

I tried several times with no delay, to make sure that it didn’t time me out, to no avail.

Ardour tries to start jackd with this command line, which fails to run.

/usr/local/bin/jackd -t 200 -p 2048 -R -T -d oss -n 2 -r 48000 -p 1024

When that command is run manually from the command line, it produces this error:

JACK compiled with System V SHM support.
cannot use real-time scheduling (FIFO at priority 10) [for thread 9150464, from thread 9150464] (1: Operation not permitted)
cannot create engine

The problem is, JACK requires root privileges to run with the -R switch for realtime scheduling.

I previously tried the older ardour version 2.8.16 because it is also pre-packaged in FreeBSD. I was able to get around this problem because the Options dialog had a checkbox to unckeck Realtime, which caused it to run jackd with -r rather than -R. I have found no such option in ardour 6.

The jackit package (jackd) includes a system startup script that allows you to enable jackd to be run as root on startup. However, that does not work because ardour does not have permissions to acces the communication files for it in /tmp when running as a non-root user.

Even if I run jackd as the same user and then run ardour, it fails because ardour is persistent about killing off any instance of jackd before it checks to see if it is already running. I finally had to write a wrapper script for launching ardour to get around this but there is still a problem as I will describe below.

Here is the script:

#!/bin/sh

# First launch ardour in background
ardour6 &

# If ardour launches jackd it's self, it always runs jackd with -R for real time
# high priority mode.  jackd must be run as root to do that.  If I run it as root
# from the system startup script, ardour does not have permission to access the
# jackd communication files in /tmp.

# Delay a few seconds before starting jackd because ardour kills any existing
# daemon on startup.
sleep 4

# Run jackd with the same parameters that ardour uses, except change -R to -r
# to disable real time scheduling.
jackd -t 200 -p 2048 -r -T -d oss -n 2 -r 48000 -p 1024 &

# After that, ardour recognizes that it's running and offers a dialog to connect
# to the existing jackd daemon.

This works fine as long as I select a recent session on startup.

If I select New Session on the initial dialog, it gives me a dialog that says

JACK is already running.  Ardour will connect to it and use the existing
settings.

and has a Connect to JACK button. However, it immediately kills jackd by sending it a signal 31. So then, when you click on the Connect button, it fails and pops up an error that says it could not reconnect to Audio/MIDI engine.

If I run ardour as root, it still kills jackd on startup, if it is already running. I click New Session, and then click Open in the Session Setup dialog, it takes me to an Audio/MIDI Setup dialog which shows Stopped in red letters next to the Audio System Start button. The only difference is, at this point ardour is able to successfully re-launch jackd and the application comes up.

In summary,

  • Ardour is overly insistent in killing any existing jackd process, even after it detects it is running and prompts to connect to it.

  • It forces you to run it as root without special wrapper scripts to launch jackd at the right time, because ardour starts jackd in real time scheduling mode (have I missed a way to change this?).

Regards,
Vincent

After further testing, I confirmed that the problem is the ‘-T’ option. Apparently when ardour runs jackd it connects and then disconnects from it causing jackd to exit.

From the jackd manual.

-T, --temporary
    Exit once all clients have closed their connections.

So it appears to be a bug in ardour6. It should not run jackd with ‘-T’ if it is going to disconnect and then try to reconnect without re-launching jackd.

I can run jackd from the command line using the exact same arguments that ardour launches it with, except without the ‘-T’, and it stays running and ardour comes up just fine.

This is not a bug. Our policy is that if Ardour is used to start JACK, then Ardour should do its best to ensure that JACK stops running when Ardour stops.

If you want a “more persistent” instance of JACK, do not use Ardour to start it. Your script has the time ordering completely wrong - if you plan to use Ardour with JACK (which we generally do not recommend for most users), but you plan to start JACK outside Ardour, then JACK needs to be running first.

In addition, yes, Ardour absolutely that the user has access to RT scheduling, and we consider lack of such access to be a configuration error.

Hi Paul.

The reason for the sleep in the script that I posted, is that, when jackd is started with ‘-T’, it would immediately die when ardour starts up, if it is already running. If I start ardour directly, without the script, and without jackd already running, ardour could not start it because it is trying to start in real-time scheduling mode, which it does not have permission to do.

Is there any way to tell ardour6 not to try to start it in real-time mode?

There is an older ardour-2.8.16 port in the FreeBSD packages, which I tried first, and it had a checkbox in the startup dialog to disable real-time.

In FreeBSD, non-root users do not have permission to to run jackd in real-time mode. I have been doing a lot of searching and have not found a way to either give a non-root user the permission, or to give ardour, running as non-root, permission to talk to jackd if jackd is running as root.

You mentioned that is not recommend for most users to run ardour with JACK. However, I see no way to change that. When I startup ardour, when I get the “Audio/MIDI Setup” dialog, that shows “JACK” as the setting for “Audio System” and it says "Stopped next to it in red letters. If I click “JACK”, it just turns the button blue but gives me no option to select anything other than “JACK”.

How do I tell ardour not to use jack?

If I click “Start”, since ardour cannot start jackd in real-time mode, I get an error window that says,

Could not reconnect to Audio/MIDI engine.

I click “OK” and the error window goes away leaving the “Audio/MIDI Setup” window. I cannot get past that to get ardour to come up in the audio editing screen.

In addition to the permission issue when running jackd with ‘-R’, ardour also runs it with ‘-T’ to “Exit once all clients have closed their connections”.

I know you said,

This is not a bug. Our policy is that if Ardour is used to start JACK, then Ardour should do its best to ensure that JACK stops running when Ardour stops.

However, even if I run jackd externally as the same user, if I use that option, jackd immediately terminates as soon as I launch ardour. So ardour must be connecting to it and then disconnecting at startup. So it is not that I want a “more persistent” instance of JACK, as you mentioned, I just need it to stay running until ardour exits.

So, I have found no way to launch ardour directly from the desktop icon or menu and have it work, unless jackd is already running as the same user (without ‘-T’).

I now have it working by running it from a new wrapper script, that I wrote, that launches jackd with ‘-r’ (no real time), and no ‘-T’ option from the FreeBSD system rc script. Then my script stays in a loop, monitoring for ardour to exit, and then stops jackd when it does.

In my case, I primarily am interested in ardour because it appears to be a really nice alternative to audacity for audio file editing (and because audacity now has gtk library problems on FreeBSD). I don’t see that I need any real-time hardware audio input ability at this time.

This solution is working for me for now. However, I am still unclear why you do not consider this a bug in ardour for the FreeBSD platform. Any user who is not skilled enough at systems administration and/or script writing to work around these issues is not going to be able to run ardour on FreeBSD without running the application as root.