I’m trying to run Ardour with Pipewire’s JACK emulation, on NixOS, but Ardour isn’t having any of it. It works fine with ALSA as long as it can claim an audio device exclusively, which makes me suspect things aren’t quite the way they should be - I thought Pipewire would have prevented that.
Ardour’s Audio/MIDI setup dialogue box shows JACK as “Stopped”, and attempting to start it gets a short delay and then an alert box complaining that it failed to reconnect.
I’m also normally pretty good with figuring this out, so I’m really just asking for pointers, like what Ardour was looking for and where, when it gives this output:
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JACK command line will be: -t 200 -p 2048 -R -T -d alsa -n 3 -r 48000 -p 512 -d hw:Pro73016834,0 -X seq
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
<Snip 5 repeats of the last 2 lines>
jack server is not running or cannot be started
Renoise is connecting just fine, and Qjackctl is doing an excellent job of connecting stuff, so I’m confident about that side of things, and I’m 99% sure Ardour’s just looking in the wrong place. I’ve also made sure that the sample-rate etc. requested via Ardour match the settings shown in Qjackctl.
I’ve also tracked down and removed any old pipewire-related configs, to rule out any Roadrunner/Wile E Coyote road-sign issues. However, it’s entirely possible that this is part of life with NixOS on the Unstable branch.
I recently switched to Pipewire. Found out for now I prefer to start Ardour and Carla (which I mainly only use for the Patchbay) via the command line.
Remember JACK isn’t actually running. Pipewire is fooling the apps into thinking JACK is running. So you don’t start the JACK server. You set your apps to use JACK but don’t have any of them start the JACK server either.
Below is how I run things with apps that use JACK. Very basic but it’s all I need for now. And I don’t have any need to run qjackctl so I don’t know if it would work the same as the way I run the apps below.
Start a terminal and open multiple tabs.
First tab: pw-top (of course not required but I like information)
Second tab: PIPEWIRE_LATENCY=“128/48000” carla
Third tab: PIPEWIRE_LATENCY=“128/48000” ardour
These can be run in any order. This is just the way I do it.
You may already know all that but for those who don’t maybe it’ll help get you started.
Thanks for the pointer about PIPEWIRE_LATENCY; I hadn’t properly explored it, so it’s good to know about that avenue for the future.
Good thinking about dropping in useful information for others who could be searching for the answer, too.
However, the answer turned out to be different… and somewhat embarrassing. The transport was stopped.
I use Qjackctl to manage connections because, as you correctly pointed out, Pipewire means there’s no actual JACK server running. Because of that, I’d stopped paying attention to the transport state, and hadn’t noticed that the other transport controls were greyed out.
I did have the Messages window open in the hope that it would give me some clues. For the first time ever, I actually clicked on its Status tab and read through the details shown there… and that’s when I noticed the word “Stopped.”
So I hit the Play button and tried starting Ardour again, and it immediately informed me that JACK is already running, and would I like to auto-connect?
Hopefully this post should shorten the head-scratching-to-facepalm pipeline for anybody else who manages to inflict this on themselves.
I should clarify something about the Qjackctl UI, to explain my confusion as well as to help anybody else who runs into this.
There are two sets of start/stop controls/indicators. One for the state of the server, being the nice, big buttons at the top left with “Start” and “Stop” written on them.
Then there are the tapedeck-style controls for the state of the transport, in the bottom row under the status window. These are the important ones.
Also, this may not be as 100% solved as I thought. After exiting both Ardour and Renoise, the transport was reset to Stopped, so naturally Ardour couldn’t connect. However, it’s still failing to connect and wanting to start the server itself after I’ve set it to Rolling, so I have more detective work to do yet. However, at least now I’m a little more confident about where I should be digging.
I’ll update this once I’m sure I have a more reliable answer.
At this point in time you still have to manually tune it for devices depending on bus. Notably for USB, pipewire’s default latency is about 8 times worse compared to jackd2.
Also keep in mind that pipewire’s emulation of JACK-latency API is not yet complete. So in case you need to record overdubs they won’t align. Likewise, external timecode sync options are useless for the time-being.
–
Meanwhile you can use Ardour/ALSA (direct connection to hardware) for production (even with pipewire installed for testing).
Well, that settles the broader issue: back to JACK and PA, for now, because syncing with other apps is my reason for reviving JACK. Thanks for being explicitly clear; now I can avoid wasting time down a hole with no rabbits in it.
I’ve been happily using Pipewire for a couple of months now, and this is the first issue I’ve run into on this go-round, so I’m impressed with it so far.
Yes, pipewire is indeed impressive, and will be the future.
Casual desktop audio works reliably, and large part of JACK user’s are also covered.
As for the rest, it’ll need a bit more time, and also user-involvement (test, report bugs):
That explains why I was never able to use that trick again, leaving the question of exactly what fluke enabled it that one time.
Thanks again for the clarification.