I’ve recently had a bunch of problems with my audio setup on Linux after the migration to PipeWire. Here’s a summary for those who might run into similar problems.
- System: Debian testing
- Audio interface: Steinberg UR44C
First, jackd would no longer start. I worked around it by compiling jack2. But that also stopped working: the output volume dropped to almost zero. So I tried the PipeWire compatibility layer. But then I couldn’t open 44.1kHz sessions, and the 48kHz sessions would glitch. In total, I was stuck for about three weeks.
After resolving all the issues, I’m using standalone jack daemon for audio work. I was under the impression that audio was often glitching when using PipeWire as backend. But I also experienced some of glitching when working with jackd, so my assessment might be wrong. It could be because of audio plugins, or something else entirely. I’ll give PipeWire a go again soon.
Problem 1: Can’t start jackd, RequestRelease is not implemented
This was the first problem I encountered and the last problem I solved.
The main error message was “Problems starting jackd: Method RequestRelease is not implemented”. Asking on Reddit helped, I finally found out that the fix is to configure PipeWire to not reserve audio devices:
properties {
alsa.reserve = false
}By default, there’s no configure file where you can put this line, so first you need to copy the example config into /etc and edit it:
sudo cp /usr/share/pipewire/media-session.d/alsa-monitor.conf \
/etc/pipewire/media-session.d/alsa-monitor.conf
sudo vim /etc/pipewire/media-session.d/alsa-monitor.confThen find the line with “alsa.reserve” and set it to false (no quotes). Save the file, and restart the pipewire service.
systemctl --user restart pipewireI think the error message should be more friendly, for example, if PipeWire won’t release the device, it should say so explicitly and point the user at instructions on how to disable the reservation.
Problem 2: pw-jack ardour can’t open a 44.1kHz project
Solution: pw-metadata -n settings 0 clock.force-rate 44100
This is when working with Ardour and PipeWire as backend. I tried to open an Ardour project in 44.1kHz, using PipeWire compatibility mode.
pw-jack /opt/Ardour-6.9.0/bin/ardour6 /path/to/my_project.ardourArdour would say:
This session was created with a sample rate of 44100 Hz, but Ardour is currently running at 48000 Hz. If you load this session, audio may be played at the wrong sample rate.
Ardour, early 21st century
If you type “pw-jack -h”, it will tell you that it accepts “-s” as a command line argument to set the sample rate, but in my experience this doesn’t work. I asked about it on Ardour forums, and found out the solution, which is to temporarily override the sample rate for the PipeWire daemon.
pw-metadata -n settings 0 clock.force-rate 44100This can be done as a regular user. To return to the default, use a 0 instead of 44100.
Maybe the JACK compatibility layer in PipeWire is incomplete or buggy.
Problem 3: Locally compiled jackd is almost mute
Solution: Compile version 1.9.19 and not 1.9.17 (default).
Before I figured out the alsa.reserve = false thing, I was trying different things to run a standalone jackd. For example, I downloaded jack2 sources, compiled them, and got a locally built jackd which didn’t throw the “Method RequestRelease is not implemented” error. (Not sure why, maybe it just didn’t try to do the DBus negotiation. Maybe it simply opened the audio device.)
This worked for a time, but recently the locally compiled jackd would output audio at a very low volume. Ardour output meters would show a loud output, but I had to turn the headphone volume knob all the way to the right to hear a distant echo of my recording.
The UR44C audio interface doesn’t seem to have an ALSA volume control. If I run alsamixer, press F6 and select UR44C, I get “This sound device does not have any controls.”
After some trial and error I realized that the problems seems to be specific to jack2 version 1.9.17, which is currently the default (branch “develop” is set to the “v1.9.17” tag), but there’s also a version 1.9.19 on github, and this one, compiled locally, worked just fine. Unfortunately I didn’t get to the bottom of it.
I hope this helps, if anyone runs into the same problems. Drop me a line if you figured out any further details!
Maciej Bliziński 