Ardour 8 Pipewire-ALSA

Hi, Here I share the new Ardour 8 ardour-pipewire-alsa.desktop to run it with ALSA-PIPEWIRE support, this shortcut is very useful for some soudcards that have the crackling audio issue with PIPEWIRE-JACK, this configuration shortcut is useful to run Ardour in very lowlatency modes without audio distortion and use ALSA with the flexibility of PIPEWIRE.

Just paste this script into a simple text editor like gedit, Kwrite etc. and save it as ardour-pipewire-alsa.desktop in /home/youruser/.local/share/applications folder so it can be accessible in the applications menu, load it and in the Audio/Midi setup select ALSA, select the soundcard to use and the buffer configuration.
I recommend qpwgraph for connections cause is more user friendly.
*this script is for Ardour 8, if you want to use it with 7.5 or 6X versions you need to modify the Exec= parameter if you know how to.

The Script Below

[Desktop Entry]

Name=Ardour Pipewire-ALSA
GenericName=Ardour Digital Audio Workstation
Icon=ardour.png
Exec=env ARDOUR_ALSA_DEVICE=pipewire Ardour8
Type=Application
Categories=AudioVideo;Recorder;AudioVideo;AudioVideoEditing;

Screenshots


2 Likes

Duplicate of

Also do not use this script if you use MIDI device, or care about MIDI: see

ideally update pipewire and use pipewire with JACK instead.

Other than that this is indeed a valid workaround until you have the chance to acquire a version of pipewire that does not produce crackles on your system.

Thanks Robin for your advice, in My case, I never had good luck with any version of Pipewire-Jack, always have Xruns and Sound Crackling in buffer configurations below 512, but with this configuration I can make large projects without issue, also midi is working a breeze with no latency problems.
I recognize Pipewire is in an early stage, but also recognize that it’s the future of linux audio system, However I respect and appreciate your opinion.

They are close to a 1.0 release.

Even with large projects there is no crackling here (running pw from source), and others also do not experience this issue with recent versions.

My main complaint is still that configuring pipewire is way to complicated, but that is a different story.

3 Likes

yeah, that’s right, also the results can vary with different distros, in my test it work better with Arch and Fedora than X-Buntu-Debian in my lenovo v15 hardware and usb audio, however i think wont look back to Jack, I like so much plain ALSA in Ardour, but it take all the audio source of my sound card, and I can’t use OBS at the same time.

New Ardour PIPEWIRE-ALSA .desktop shortcut Update for Ardour 8.1


[Desktop Entry]

Name=Ardour Pipewire-ALSA
GenericName=Ardour Digital Audio Workstation
Icon=Ardour-Ardour_8.1.0
Exec=env ARDOUR_ALSA_DEVICE=pipewire Ardour8
Type=Application
Categories=AudioVideo;Recorder;AudioVideo;AudioVideoEditing;

#Follow instructions on top

Hi Robin!, testing Pipewire for a year I need to say YOU ARE CORRECT, Pipewire is still not ready for prime time or pro-audio usage, the latency in Pipewire is more than Jack, also the xruns is considerable more than Jack, no mater the kernel, distro or hardware also some bugs, I think I’ll stay on Jack for now until the big pro like You and Paul approve it for pro-audio stuff, thanks for all your advises!

Are you testing 1.0 or 1.0.1 yet? That release claims latency the same as jackd.

I’d been trying all versions but 1.0.1, from the beginning up to 1.0, it doesn’t communicate well with Ardour and in Traction Waveform 12 use a loooot of DSP more than Jack

Did you select “Pro Audio” for your sound card in pavucontrol under the Config tab?

From FAQ · Wiki · PipeWire / pipewire · GitLab
Since 0.3.81 this profile will use IRQ based scheduling with linked devices when there is 1 capture and 1 playback device. This results in the same latency as can be achieved with JACK on the device

Thanks for the advice, I’ll try it!

Ironically, you can get lower latency by not using IRQ based scheduling, but instead just using the IRQ to calibrate a DLL.

1 Like

Thanks Paul for the advice, for now I’ll stay on pure Jack, it’s robust and stable, pipewire need some care.

It wasn’t really advice. You can’t actually do what I was describing on Linux, and the closest you can get to it is via Pipewire. That’s why I said it is ironic that PW is using IRQ-based timing to get low latency.

Ok, I think I’m not understanding, but a little, so pipewire latest version doesn’t use IRQ-Based timing and for that it work better than Jackd or vice versa?

With 1 capture & 1 playback device (and they are linked i.e. the same hardware, probably), current PipeWire uses the same scheduling design as JACK, and thus achieves (they claim) the same latency.

My point is that this is ironic, because from what I understand of PW’s design, it ought to be possible to do better than JACK using the “normal”/“default” scheduling design in PW.

1 Like

Ok, I was so exited with Pipewire by the multi-backend feature, but testing it in different distros it’s kinda temperamental when using it for audio production even using the pipewire-alsa / pipewire-jack, I think I’ll stay on Jack until Ubuntu 24.04 be available that will be full Pipewire compiled exclusively for Ubuntu 24.04, to se how it work, but for now I can say there’s still no substitute for Jack with it stability and low xruns functionality in Linux, but say Pipewire is a great audio back-end for multimedia usage, but for pro-audio still need some love.

When I run this script, I keep getting "The audio backend was shutdown because:

ALSA I/O error." How do I resolve this?

Is there anything else in Window > Log?

A common issue is that you use a too low buffersize and the system shuts down after many consecutive dropouts.

Then again, Ardour is only expected to work correctly with direct hardware access. If you use pipewire’s emulation, Audio/MIDI alignment will be incorrect, and likely overdubs when recording audio may also not align. if you [have to] use pipewire, use pipewire-jack.

it was the buffer haha I switched from REAPER and I could handle lower buffer in there for some reason, so I raised it and the problem went away in regular alsa.

I’ve since done more tweaks and improved performance further, especially noticeable on DSP meter