Linux audio has a reputation earned across two decades of OSS, ALSA, ESD, aRts, PulseAudio, and JACK, several of which existed at the same time and did not get along. PipeWire replaced most of that, and the notable thing is how few people noticed the transition happening.

The problem it solved

Before PipeWire there were two serious sound servers with incompatible priorities.

PulseAudio optimised for desktop convenience. Per-application volume, automatic switching when you plug in headphones, Bluetooth handling, network streaming. It worked, and its latency was fine for media and calls and unusable for playing an instrument.

JACK optimised for professional audio. Very low latency, sample-accurate routing between applications, the ability to wire any output to any input. It was excellent at that and hostile to casual use, and it wanted exclusive control of the hardware.

Running both meant bridges, careful configuration, and a fair amount of swearing. Musicians on Linux kept two audio configurations and switched between them.

PipeWire replaced both with one server that handles both cases.

What it is

PipeWire is a media server for audio and video. It handles graphs of streams between applications and devices, with a real-time thread that can hit latencies low enough for live monitoring.

The compatibility layers are the reason the migration was invisible:

• pipewire-pulse speaks the PulseAudio protocol, so PulseAudio applications connect unmodified
• pipewire-jack provides the JACK API, so JACK applications work without a separate server
• ALSA clients are handled through a plugin

Applications talking to PulseAudio still think they are talking to PulseAudio.

pactl info | grep "Server Name"
# PulseAudio (on PipeWire 1.x.x)

That output is the giveaway: the interface is PulseAudio, the implementation is not.

WirePlumber

PipeWire deliberately does not decide policy. It moves streams; it does not decide which device a new application should use or what happens when you plug in headphones.

That is WirePlumber’s job, a separate session manager holding the rules: device priorities, automatic switching, per-application routing, Bluetooth profile selection.

The split matters when troubleshooting. If audio plays but goes to the wrong device, that is usually policy and therefore WirePlumber. If audio does not play at all, that is more likely PipeWire or the device itself.

Video, and why screen sharing depends on it

PipeWire handles video streams as well as audio, which is how screen sharing works under Wayland.

X11 let any application read the screen. Wayland removed that, so capture goes through xdg-desktop-portal: the portal shows a picker, you choose what to share, and the resulting video stream is delivered over PipeWire.

This is why “screen sharing does not work in my browser on Wayland” is usually a missing or misconfigured portal rather than a browser problem.

Bluetooth

PipeWire improved Bluetooth audio noticeably, with support for modern codecs including aptX, LDAC, and AAC where the hardware supports them.

The old headset problem is still a physical constraint rather than a software one: classic Bluetooth cannot carry high quality audio and a microphone stream simultaneously, so using a headset microphone drops audio to the low-quality HSP or HFP profile. LE Audio fixes this properly, and both ends need to support it.

# See available profiles for a Bluetooth device
pactl list cards | grep -A20 bluez

Useful commands

wpctl is the WirePlumber control tool and the one worth learning:

wpctl status                    # everything PipeWire can see
wpctl set-default 42            # set default sink or source by ID
wpctl set-volume @DEFAULT_SINK@ 50%
wpctl set-mute @DEFAULT_SINK@ toggle

pactl still works, because the PulseAudio protocol is still spoken:

pactl list short sinks
pactl set-default-sink alsa_output.pci-0000_00_1f.3.analog-stereo

For routing, install a patchbay. Helvum and qpwgraph both draw the graph and let you drag connections between application outputs and device inputs. Being able to send one application to one output and another elsewhere, with a mouse, is the capability JACK users had and desktop users never did.

Troubleshooting

Everything is silent. Restart the user services first:

systemctl --user restart pipewire pipewire-pulse wireplumber

This resolves most transient problems and is faster than investigating.

A device is missing. Check what PipeWire sees:

wpctl status

If the device does not appear here, the problem is below PipeWire. Check whether ALSA sees it at all:

aplay -l
arecord -l

Nothing there means a kernel or driver issue rather than an audio server one.

Crackling or dropouts. Usually the quantum, PipeWire’s buffer size. Smaller means lower latency and more risk of underruns.

pw-metadata -n settings 0 clock.force-quantum 1024

Larger values are safer. Persist it in ~/.config/pipewire/pipewire.conf.d/ rather than setting it every boot.

Screen sharing shows a black screen. Check the portal is installed and running:

systemctl --user status xdg-desktop-portal xdg-desktop-portal-wlr

You need the backend matching your desktop: -gnome, -kde, or -wlr for wlroots compositors.

Per-application volume vanished. Some applications that used ALSA directly bypass the whole system. There is not much to do beyond configuring the application to use PulseAudio or PipeWire output.

Should you do anything about it?

No. If audio works, PipeWire is doing its job and there is nothing to configure.

The reasons to engage with it deliberately are wanting per-application routing, doing audio production and wanting low latency without a separate JACK setup, or troubleshooting. For everything else it is infrastructure that finally stopped being a topic of conversation, which for Linux audio is a considerable achievement.

Frequently Asked Questions

Am I already running PipeWire?

Almost certainly, if your distribution is recent. Fedora switched in 2021 and Ubuntu, Debian, Arch, and openSUSE followed. Run pactl info and look at the Server Name line: it will say PulseAudio on PipeWire if PipeWire is handling audio through its compatibility layer.

Do my PulseAudio applications still work?

Yes. PipeWire ships pipewire-pulse, which speaks the PulseAudio protocol, so applications built for PulseAudio connect without knowing anything changed. The same applies to JACK and ALSA clients through their own compatibility layers.

What does PipeWire do that PulseAudio could not?

Low latency good enough for professional audio work, which previously required JACK and a separate setup. It also handles video streams, which is why screen sharing on Wayland goes through PipeWire, and it applies per-application security policies through portals.

Why did Linux need both PulseAudio and JACK before?

They optimised for different things. PulseAudio prioritised convenience: automatic device switching, per-application volume, network streaming. JACK prioritised latency and sample-accurate routing for music production. Running both simultaneously was awkward, and PipeWire covers both cases.

How do I control per-application volume and routing?

Your desktop volume mixer works normally. For proper routing control install a patchbay such as Helvum or qpwgraph, which show every stream and let you connect outputs to inputs by dragging, in the way JACK users have always worked.

What do I do when audio stops working?

Restart the user services with systemctl --user restart pipewire pipewire-pulse wireplumber before anything else, since that fixes most transient problems. If a device is missing, check wpctl status to see what PipeWire can actually see.