Tag: pipewire

I bought a new laptop to do some more serious work on, and while I was setting up the audio, installing JACK Audio Server and friends, I wondered what would be the proper path forward for a Slackware DAW (Digital Audio Workstation) when Slackware 15.1 is released with all the improvements over the 15.0 stable release.
Should I stick with JACK or look into Pipewire to get rid of the Jack server? Jack can be a bit finicky at times on this new laptop. The audio hardware uses Sound Open Firmware, which is new to me and often I need to restart JACK once or twice via QJackCtl before I actually get sound out of the laptop.

To make an informed decision, let’s first examine what PipeWire actually aims to improve. I confess that because of what I learnt during  my research, the article is a bit biased but hey! Feel free to contribute to the discussion at the bottom of the page!

State of affairs

Linux audio has historically been a layered affair. ALSA talks to the hardware, and one (or more) sound servers sit on top:

• PulseAudio: handles desktop/consumer audio mixing, Bluetooth, networked audio. As we all know, its drawback is a high latency. It’s definitely not “DAW-friendly”.
• JACK: the professional audio server. It delivers ultra-low latency and a flexible routing between apps. But it comes with a steep learning curve and is not trivial to manage. It is rather hostile to consumer-grade applications that rely on Pulseaudio, unless you bridge them.
• PipeWire: built as the solution to all of the above problems, aiming to replace both and also (importantly) acting as a drop-in for each.

This is how the audio stack on Linux looks from the point of past/present and future:

You see where I am going…

 Pros of switching to PipeWire for a DAW

1. One server to rule them all
   The benefit that I see is the elimination of complexity. We would get rid of having to run two parallel audio servers. In the legacy setup, PulseAudio mostly handles browser audio, Bluetooth, and desktop sounds while JACK is running the DAW. Getting them to cooperate requires that you install a Pulse-JACK bridge (via the pulseaudio-jack package) which is a temperamental setup. PipeWire replaces both of those audio servers with a single daemon that implements all three protocols simultaneously via pipewire-pulse, pipewire-jack, and pipewire-alsa compatibility modules.
2. JACK applications just work, unmodified
   PipeWire aims to offer capture and playback for both audio (and video, let’s not forget!) with minimal latency and support for PulseAudio, JACK, ALSA and GStreamer-based applications. This means that programs like Ardour, Carla, Hydrogen, Guitarix, and every other piece of software I added to my Slackware DAW project will connect to PipeWire’s JACK compatibility layer without recompilation. The ABI is compatible; programs don’t know they’re talking to PipeWire.
3. Latency has matured significantly
   Early PipeWire had a reputation for higher latency than native JACK. That criticism is much less valid today. Already long before the 1.x releases, the latency was reduced as low as using just JACK on top of ALSA.  PipeWire supports the same realtime thread priorities and can be tuned with “quantum” (buffer size) settings comparable to JACK’s “period/frames” parameters.
4. Video routing and screen capture come along for free
   The daemon can be configured to be both an audio server (with PulseAudio and JACK features) and a video capture server. This matters for screen-casting, OBS, webcams, and Wayland portal-based screen sharing. They all go through the same flow that handles your audio.
5. Flatpak and containerised applications work properly
   Yeah, I use Flatpak. Particularly to have a Signal messaging app on my desktop. Multimedia is an issue there. But PipeWire uses a Polkit-like security model, asking Flatpak or Wayland for permission to record screen or audio, rather than relying on audio/video group membership.
   This is a solution for a genuine pain point with JACK plus PulseAudio in any sandboxed context.
6. WirePlumber provides intelligent session management
   The PipeWire session manager WirePlumber (which replaced the older pipewire-media-session) automatically handles device routing decisions. This means for instance, you simply plug in a USB audio interface and It Just Works. With JACK you would have had to restart the server or run manual scripts.

Caveats (Especially for a DAW)

1. Extreme latency requirements still favour native JACK
   For professional studio scenarios demanding the absolute floor of latency (sub-8ms round trips, preferably below 5ms even, dense plugin chains) the picture is more nuanced. Under JACK, you can isolate cores, prioritize IRQs, and force absolute determinism. Under PipeWire, your latency will jump if anything interrupts real-time threads. PipeWire is getting better, but native JACK under a PREEMPT_RT kernel remains the gold standard for this specific use case.
   For most home studio and ‘prosumer’ DAW setups, you will not notice the difference.
2. Configuration requires a different mental model
   Well what’s new. I am still not fully comfortable using JACK and QJackCtl’s patchbay metaphor. PipeWire on the other hand uses WirePlumber for policy management. Quantum (buffer size) and sample rate tuning is done differently. There’s yet another learning curve.
3. Slackware’s ‘pipewire-enable.sh’ script has a precondition you must not ignore
   An important operational point is the check whether JACK is installed and the daemon is running. If that’s the case you should opt in consciously and disable JACK server manually, not have it silently taken over by PipeWire.

Is the JACK Server Still Needed?

The short answer: no, not as a running daemon. But of course there are layers below that answer: what about the runtime dependency on JACK because all those audio applications were compiled against JACK?
When pipewire-jack is installed (my add-on to the pipewire package in Slackware), it provides a drop-in JACK compatibility library. Programs that link against libjack.so will, after PipeWire is enabled, actually be talking to PipeWire under the hood. The jackd process itself does not need to run.
What does that look like:

• libjack.so is the library that applications link against. It is still needed because it provides the ABI that JACK-aware programs call into. PipeWire provides its own version of this library when pipewire-jack is installed.
• jackd / jackdbus is the server binary. This is no longer needed as a running process once PipeWire takes over as the audio server.
• qjackctl is the control GUI for JACK. Fortunately this can be replaced by qpwgraph (from the same author who created qjackctl). Qpwgraph is the PipeWire-native patchbay application, obviously inspired directly by qjackctl.

And therefore the practical implication: if you have JACK installed on your Slackware DAW system alongside PipeWire, you need to ensure the JACK server does not start at login while PipeWire does start. The “pipewire-enable.sh” script in Slackware handles the PipeWire side; you simply should not start the daemon, jackd.

Connecting it all – the patchbay

What are the considerations when moving from qjackctl to qpwgraph?
As I said earlier, the author of qjackctl also wrote qpwgraph and the similarities are obious. Qpwgraph is a Qt-based graph and patchbay for PipeWire, and it saves your wire sets. It is the natural successor to qjackctl as part of a  DAW project that uses PipeWIre. The interface is visually very similar to qjackctl’s patchbay view, but it shows PipeWire’s full graph: the audio ports, MIDI ports, and video streams; all together. The connections that you create are saved by WirePlumber and restored on the next login.
If you still prefer qjackctl, that is not an issue because it can also connect to PipeWire via the JACK emulation layer.Its JACK-specific transport controls and the JACK server start/stop buttons become meaningless however.

What’s in the future for Slackware DAW

Given all of the above, this is what I think:

If you run an amateur home studio or you are a musician whose priority is “everything just works with minimal fuss“, switching from JACK to PipeWire looks like the future. Run ‘pipewire-enable.sh‘ once, install qpwgraph (it’s already in my repository) and use it as your new patchbay.
After you switch to PipeWire, the “Pro Audio” profile in pavucontrol (yes, it is a Pulseaudio tool) used in combination with a PipeWire audio server provides raw, direct access to all available input/output channels on your USB audio interface, bypassing standard stereo mixer restrictions. It is ideal for professional interfaces with multiple inputs/outputs, supporting low-latency and enabling advanced routing for your DAW.

On the other side of the spectrum you have your ultra-low-latency professional use. It’s the use-case for a dedicated professional recording studio, where you would be looking at sub-5ms latency requirements, a PREEMPT_RT kernel, hardware with specific JACK-tuned drivers. In this scenario, the traditional JACK-only configuration remains the preferred setup of your DAW.

The good news is that PipeWire does not break the JACK ecosystem. It absorbs it. If you are comfortable having a JACK-based signal flow (Carla, Ardour, Guitarix chains), you can migrate to PipeWire transparently and your setups will continue working. The most obvious difference being that there is no more need to manually start a JACK server or maintain a bridge to PulseAudio.

Your ideas

My biased story tried to convince you that a switch from JACK to Pipewire in Slackware DAW may be the right thing to do, but I also write this to convince myself 🙂 I am very much a person of “don’t try to fix what is not broken” but I see the benefits for most of us, Slackware users.

Still, there is a hard choice to be made. Should I recompile all my audio applications in the absense of JACK package to get rid of that dependency altogether? Or should I keep JACK, and keep all packages dependent on its libraries, and leave it up to you, the user, to run “pipewire-enable.sh” and replace qjackctl with qpwgraph? The former is cleaner but the latter gives more options.
Let me know your thoughts in the comments section below!

Eric