I have seen a few comments here lately saying that the devs recommend using ALSA instead of JACK. Why is that?
I tried searching but came up empty. A link would suffice. Thanks.
- Ardour/ALSA is a lot easier to set up, especially if you need MIDI.
- Ardour/ALSA supports multiple devices. This is required when using USB-microphones along with a different playback device.
- it is possible to correctly calibrate systemic latency when using USB devices on Linux. jackd has to be restarted in order to set systemic latency, which voids the measurement. – This is important when recording overdubs.
- likewise JACK does not support to set systemic MIDI latency at all – This is important when recording MIDI overdubs, or recording MIDI while listening to ardour playback.
- Ardour/ALSA performs a tiny bit better compared to JACK
You only need JACK, if you want to share the soundcard with other JACK applications.
3 Likes
I recently upgraded to Debian 11 and did a fresh install of my music software, including Ardour.
The install script asked me if I wanted to install jack.
Perhaps not necessary if you want to steer people towards ALSA?
On most GNU/Linux distros installing JACK, also [asks the user to] set(s) up realtime privileges for the user.
Installing JACK is an easy and convenient way to perform this distro specific setup which is needed regardless if you actually use JACK or not.
Hmmm,
I think at this point it muddies the water and most new Users don’t know or care about JACK and experienced Users who need JACK already have it and (on Debian-based stuff anyway) the jackd package will take care of all the privileges stuff when you install it.
The installer gives the impression JACK is either a required companion application to Ardour or at least highly recommended… Then people come to IRC or the forum and you guys really backpedal JACK as a “well I guess you could but we don’t really recommend it” sort of thing. Seems like the installer script hasn’t been looked at in a while and this is something that just may need to be updated for the current state of affairs…
While I’m opining… Why can’t the Ardour bundles just have the executable bit set on the bundles? Mixbus uses the same bundling and they exe just fine so it’s not like it can’t be done… Two stupid hurdles to installing Ardour in Linux (a) Your File Manager doesn’t allow you to execute ‘.run’ scripts… (some very fine multimedia OS’s enable this by default… 
) and (b) The run script isn’t executable… Now (a) isn’t obvious but (b) should be (IMHO)…
They have, but most browsers unset it when downloading the file as safeguard, as they should.
Nope. Mixbus comes in a .tar file, and the .run file inside the tar is +x.
This requires twice the space (you first have to un-tar). We’d like to think that Ardour users are smarter, and don’t need this extra hand-holding and disk space waste.
Also other apps, notably nvidia-driver and steam come as .run files, just like ardour’s installer.
It was only updated a just before the 6.9 release, and as I said before, installing jackd is the easiest way to setup distro-specific realtime permissions (we ask to install qjackctl because the jackd package is also name differently on different distros). Besides, JACK is handy in some circumstances and there is no downside to installing it.
When you first start Ardour, the default is to not use JACK, but ALSA.
1 Like
Fair enough… I stand corrected, wasn’t aware it was a safety measure on the Browser side. Although I don’t really know why someone new to Ardour or Mixbus would need one or the other to be easier, a new user could be going either way to try both they both should be as easy as possible IMHO…
Jack is useful for connecting external apps, especially if you have other devices on your LAN which can benefit from netjack. The other useful feature is for firewire audio interfaces which require ffado (the alsa firewire stack is not really good, I have a couple of old MOTU 8pre in our rehearsal room and believe me, the ALSA motu-firewire driver is complete garbage, it almost destroyed my ears when toying around with it + the channel indexing is random: hw channel 1 ends up as system:capture_3 for example).
If all you use is ardour + plugins, and your device is well supported by ALSA, jack is really optional.
Hi, there!
Any advice on ardour running over pipewire? Here (debian testing/unstable) I moved to pipewire with pipewire-pulse and linked libraries to have pipewire to take control over jack.
The capture fron any non-default input audio has a artifact sounding like some bad resampling. The same happens on audio files used as background sound in obs-studio scenes.
Thanks in advance.
Best, Alexandre
Our position on Pipewire right now is that its JACK implementation is not finished and cannot be considered suitable as a replacement for JACK1 or JACK2. We have every confidence that this will happen.
There is absolutely no reason to ever consider using Pipewire-Pulse, at least not with any pro-audio/music creation apps. None of them ever used the PulseAudio API, so if they were ever used with PulseAudio, it was merely an artifact of PulseAudio taking over the “default” ALSA device role.
We do not have a good sense of how good the Pipewire ALSA implementation is. Most people trying Ardour with Pipewire have tried it with Pipewire’s JACK support.
2 Likes
Hi there, Paul
Thanks for the prompt reply. Do you think removing pulseaudio from here
will result in a fully functional system? I tried that but couldn’t have
alsamixer working. Is there any suggestion of audio mixer/volume control
that would work without pulseaudio?
Best, Alexandre
Years ago, Pulseaudio was a bit of a problem on systems used for low latency audio to the extent that some users would remove or disable it completely to avoid the configuration headaches. In my experience, this hasn’t been an issue since Ardour made it possible to select ALSA as the audio backend, as doing so takes full control of the sound device. It seems the relationship between Pulseaudio and JACK has improved since then, but I quit using JACK once Ardour no longer required it, so someone else would have to give more insight on that aspect of Linux audio.
I think your issues are likely due to the experimental nature of Pipewire, and I would recommend removing it until it has reached a stable state before messing with Pulseaudio as some desktop applications depend on it.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.