Ardour crashes JACK when exporting

Everytime I export something from Ardour, no matter the complexity of the session, it messes up something with my JACK setup.

Ardour 6.9.0
Ubuntu 20.04.4 LTS
Kernel 5.4.0-91-lowlatency
Focusrite Scarlett 2i2 (I guess)
Realtime: Yes
Buffer Size: 256 samples
Sample Rate: 48000 Hz
Block Latency 5.3 ms
Xruns: 0 (<- important !!!)

Upon export all audio goes mute, I can’t close Ardour and in Cadence I see Xruns accumulating endlessly until I manage to close Ardour somehow. Sometimes I can close it after many attempts of clicking the close window X, sometimes I have to kill it ungracefully. The only way I can get my audio to work again is by restarting the pc. Restarting the pc after every export from Ardour is not the most pleasant experience, can anybody help me with that?
I already tried to get a backtrace from Ardour by running it in gdb but I got no output. This might be because there is no error on Ardours side but rather on JACKs or this is because I got the setup wrong.
the ardour debugging page says

Be sure to start JACK without the --realtime / -R switch. Also the client timeout variable should be set to a large value such as 5000 (–timeout / -t).

Well, it’s nice that they tell me the CLI flags for starting JACK but I use Cadence to manage JACK and I don’t know what equivalent setting that is here.

UPDATE: meanwhile I found the equivalent settings in Cadence GUI (I guess) and will try to get debugging data tomorrow. But if the error really is on JACKs side, I guess I wont get much information here.

When exporting ardour asks jackd to freewheel.

  • disconnect from the hardware (soundcard)
  • process as fast as possible, as slow as required

xruns cannot happen while JACK freewheels.

However, if you use a bridge (e.g. pulseaudio or external hw) those can cause issues.

So what am I supposed to do?
I’m running an Ubuntu OS, which comes with PulseAudio by default, JACK is build upon that, so of cource I have a PulseAudio bridge.
I tried to Stop the bridge while exporting from Ardour but either the stopping of the bridge or the same problem as before is still causing the entire audio setup to fail and I’m only able to recover it by rebooting my pc.

JACK uses ALSA. It has nothing to do with Pulseaudio.

Pulseaudio is mainly for desktop audio, and you only need the bridge if you want those desktop apps to be played via JACK.

Sadly I don’t have first hand experience with this.

I do not use JACK (I use Ardour’s ALSA backend, no indirection via JACK), but the issue with pulse bridges comes up often here on the forum. e.g.

Here and in other forums the message doesn’t seem to be getting through that if you are using Ardour/Reaper/Mixbus/Bitwig directly without any outside application plumbed in or out that JACK is now completely irrelevant… Audio Distro distributors are kind of unwittingly and unwillingly culpable because we keep putting out systems where JACK is the focus of the Audio setup so whether it’s pajackconnect in AV Linux, Or Cadence in KX Studio or Studio Controls in Ubuntu Studio we are promoting an Audio routing and workflow that really is 10 years old… I don’t know anything specific about Pipewire (yet) but from what I’ve read it also doesn’t really hold the answers for this problem because ideally the best performance scenario is to let Ardour connect directly to ALSA and leave the host of Desktop Audio servers for playtime…

I think if @paul or another high-falutin’ LinuxAudio developer would do a podcast or Blog article with a high-profile solid example-based case why modern Linux DAWs under normal non-modular circumstances should be used primarily with ALSA it would really help clear the air on this once and for all. I would love to divest AV Linux of JACK completely but the current climate of confusion on this subject I would probably receive death threats…lol

For me at least I get a fair bit lower DSP use when I go through Jack, and much less xruns on low latencies. My Focusrite also really prefers 4 periods to 2 or 3 periods for some reason (might be other hardware, I’ve given up trying to figure it out hah) - something I can’t set in Ardour.

48k / 64 / 3 periods is extremely unstable through ALSA whereas 48k / 32 / 4 periods runs perfectly fine through Jack on my hardware.

And for every use case where you do need to route audio and midi between applications Jack/Pipewire feels pretty essential.

(note that I dont run the pulse bridge at all)

Yes, this remains true and of course I’m not saying ANY of the other Audio servers can’t or shouldn’t be there for those purposes. I’m saying it seems a LOT of people are still under the impression that at a basic level you need JACK in order to record with Ardour and some other DAWs (like it was 10 years ago) and you can if you want of course but it is not required at all to simply use Ardour without any external modular sound needs which would include routing or using Desktop apps at the same time.

1 Like

This is unlikely.

Note that JACK reports average DSP load, while Ardour/ALSA reports worst case.

Average load is mostly useless, except it looks nicer and makes JACK look better compared to competitors. The DSP load can be low on average, but you can still get x-runs (occasional load > 100% which may be be averaged out). If you want to ensure that there are no dropouts, worst-case load is relevant.

Recent versions of Ardour have Menu > Window > Performance Meters, which can also show worst-case load when using JACK.

You may just as well double the buffersize and use 2 periods.

Effective systemic latency should be lower, and there will be fewer context switches. There should never be the need to use a period size other than 2 or 3.

Note this is all 48khz - I just checked again here. On ALSA with 2 periods I get continuous stream of xruns on both 128 and 64. (this is also true for jack btw)

With jack I can run loads of plugins and live audio on 32 / 4 periods. And completely without worry on 64 / 4.

EDIT: (On further testing, 64 / 3 seems to be fairly stable ATM through ALSA so it’s clearly 2 as buffer somewhere in my system has a problem with mainly)

1 Like

USB devices should always be set for 3 in my experience, 2 is for onboard or PCI(e) devices.

I have no issues with using USB devices at 2 periods/cycle, even at low latency (1818 VSL, Focusrite 18i6, Editrol UA-25).

The key with Linux before 5.15 to set buffers-size * n-periods / sample-rate so that it is a multiple of 1ms, and yes in most cases that requires -p3.

1 Like

Well there you go… more outdated info floating around that is no longer accurate… :roll_eyes:

nothing new, and this has not changed since 2013:

As for recent Linux:

most of those already landed earlier in Linux 5.15.7 [] and it’s been discussed here on the forum as well as linuxmusicians and linux-audio-user email list.

I suspect it’s something hardware related on my front then. I have honestly trouble shot that problem on my end quite extensively haha.

I’ll definitely be testing out running ALSA for my purely Ardour work going forward tho as 64/3periods seem to be quite stable for now.

Wow, I didn’t expect such a discussion over this.

Unfortunatelly that creates some sort of dilemma for me.

  1. I tried to use Ardour with the ALSA backend but with that I don’t get any audio to work in Ardour. No input, no output.
  2. without JACK I don’t get my second USB Interface to run.
    I execute an alsa_in -d hw:<id of hw> and get an output like that:

foo@bar:~$ alsa_in -d hw:5
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jackdmp 1.9.12
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
Copyright 2016-2017 Filipe Coelho.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 10
self-connect-mode is “Don’t restrict self connect requests”
Failed to acquire device name : Audio3 error : Device reservation request with priority 2147483647 denied for “Audio3” via RequestRelease()
Audio device hw:Generic,0 cannot be acquired…
Cannot initialize driver
JackServer::Open failed with -1
Failed to open server
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
jack server not running?

Without that device I cannot record drums which makes audio production pointless
3. Even if Ardour would work with ALSA alone, actually I need JACK because I have to route audio between applications quite a bit for live streaming.

So no matter which way I go, it doesn’t work for me, right?

Was jack still running? in this case Ardour cannot use the soundcard.

It should work if you disable all the bridges before asking Cadence to start jackd.

  1. No, JACK wasn’t running at all. I stopped it all together, created a new Ardour project, ALSA set as Audio System. but no matter what I tried to set as an input or output, I got nothing in and nothing out.

  2. Unfortunatelly I can’t test this because when I stop the PulseAudio bridge in Cadence, it restarts itself after a couple of seconds. I unchecked “Auto-start at login” which doesn’t seem to change things either.

I used to love and promote Linux, but audio is just an utter mess. This makes me so sad :sob:

Have you tried a new session?
In case you load an existing one, the master-bus output may not be connected.

While Ardour is running, with ALSA run the following command in a Terminal:

cd /tmp && wget && bash ./

It will not modify your system; it lists all soundcards, their current settings and applications using them, etc. Then copy+paste all the output of that script here.

Semi/Professional audio in Linux can be a bit finicky but it works for lots and lots of people.

Have you tried using another distro, to check if there’s something particular with your use of Ubuntu/Cadence/Ardour?
You should be able to run AV Linux from an USB stick and see if it works

Or skip Candence and start JACK using QJackCtl or start it directly from within Ardour.