Hi Mozilla team,
This is still highly relevant in 2026 — almost all major Linux distros (Fedora, Ubuntu 24.04+, Arch, openSUSE, Neon, etc.) now default to PipeWire, and the pulse-rust → pipewire-pulse path introduces measurable issues:
Unnecessary resampling: Media sources at 44.1 kHz (e.g. many music streams, Spotify Web, some podcasts) get resampled to the system's default rate (usually 48 kHz), adding quality loss and ~10-20 ms latency. Native PipeWire backend supports per-stream rate negotiation, which would avoid this in most cases.
Higher overhead & occasional instability: Users report thread overflows, pipeline crashes (especially with many tabs + effects like EasyEffects), and higher CPU usage compared to native clients (mpv, browsers with WebRTC PipeWire capture already work great).
User workarounds are limited:
Setting media.cubeb.backend = "pipewire" is ignored in release builds.
Falling back to ALSA (media.cubeb.backend = "alsa") works for low-latency but breaks per-app volume control, mixing, and device hotplug — not suitable for daily use.
Related upstream: cubeb PipeWire backend has existed since ~2022[](https://github.com/mozilla/cubeb/issues/705), but not prioritized for default/output.
Could we please get:
1. A status update — is this on any roadmap or being actively worked on?
2. Making media.cubeb.backends preference actually respect "pipewire" in official builds (even as opt-in for now)?
3. Or at minimum, enable native PipeWire for audio output on distros where pipewire-pulse is detected as the primary server?
This would significantly improve audio quality/latency for Linux users without breaking compatibility. Happy to help test patches in Nightly if there's any movement.
Thanks!
