Repository navigation
PipeWire support #705
Description
Activity
it would be nice if we could have some way to vote on this feature, or donate to funding it. for example a bounty reward scheme. Many thanks
Trying to implement PipeWire support: https://github.com/goosesima/cubeb-pipewire
test_audio already works with PipeWire.Reacted by Dreamcat4, Andrea Pappacoda, SopaDeMacaco-UmaDelicia, Levi Behunin, Valentin Bugrov and TheBlueRubyIt's probable that we'll prefer any new backend to be written in rust at this point. But this looks fairly small so it's probably no problem to port.
Reacted by Henry John KuptyReacted by Theo Paris, xcfrg, Gleb Samsonov and saatwatKinda sad that Mozilla doesn't implement it itself. Since it's a pulseaudio successor on Linux desktop it should have Tier 1 attention.
Reacted by GooseSima, xcfrg, toasterrepairman, TerminallyDied, mara004, Tommy Nevtelen, Nicolas Mazzon, Ruben A, pixelsuft, TheBlueRuby and 6 moreReacted by Andrea PappacodaAnother bump to this issue, this feature is needed.
I am interested in this topic. However, it's sad that we are short of resources. I can take this for now but probably need to find some time to do this
Reacted by Dreamcat4, Levi Behunin and mara004@ChunMinChang
mpv-player recently added pipewire support -- mpv-player/mpv#8569 -- mpv-player/mpv#9587 -- mpv-player/mpv#9734It is only audio out though.
Boop.
Reacted by Alberto Fabbri and lukeThe PipeWire project is very clear that the Pulse API is to be preferred for now: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#what-audio-api-do-you-recommend-to-use.
Can someone outline the reasons why we shouldn't follow what they say and talk with PipeWire directly? What would be the benefits?
Logically, since cubeb is talking directly to pipewire, it can harness all of its features while being low latency, instead of talking to a translation layer such as pipewire-pulse.
Additionally this can make cubeb only support pipewire, which prevents the need for pulseaudio, jack, and alsa support all together.
Has this claimed been verified in practice? I've verified that
cubebbehaves with much lower latency and higher resilience when the server ispipewire, despite usinglibpulse. It isn't clear that the translation layer has any meaningful overhead, which is something that would explain why the pipewire developers themselves recommend using a higher level API.cubebwon't drop support for other backends anytime soon, in any case, this is about using a new backend. Jack and Alsa are already not tier-1 anyway, but people use them in practice.Note that
cubebonly needlibpulse, we're talking a few hundred kilobytes on disk here and some memory forpipewire-pulse(about 65KB here locally on my Linux desktop).Please keep in mind that we're not opposed to writing a new backend, it's just that other works take priority if this new backend doesn't provide meaningful benefits in practice. There's a lot of other things we can do instead of writing a new backend that might be more beneficial.
If someone shows up and writes a high quality pipewire backend in rust, I don't see why we wouldn't review it carefully, and use it (for example, if it has all features and is more performant, etc.). We're not going to add new backend in C or C++ to cubeb at this point.
Reacted by sewnie and Alberto Fabbri- Capture apps with audio for getDisplayMedia()
Bump
Reacted by Alberto FabbriHas this claimed been verified in practice? I've verified that cubeb behaves with much lower latency and higher resilience when the server is pipewire, despite using libpulse. It isn't clear that the translation layer has any meaningful overhead, which is something that would explain why the pipewire developers themselves recommend using a higher level API.
I was curious about this, so I tried it out. Note that this can be reproduced with some wav/opus etc. audio, and PW-play stands for PipeWire and PAplay for PulseAudio. I tested this under pipewire's pulse emulation.
I found that, for audio out,
pw-play audiofilevspaplay audiofilehad 0.3 Watts and 0.5 Watts of excess (versus idle) power consumption respectively. This was really surprising since I didn't expect them to behave differently. The savings for using PipeWire are measurable.Mostly unrelated but easier to test, I also noticed that
pw-play audiofileis more responsive to Ctrl-Z (SIGSTOP) compared topaplay audiofile, the latter taking a few seconds before playback actually stops. The same is for restarts withfg(SIGCONT).Another weird bug I've been noticing lately is that Firefox sound breaks after suspend, whereas PipeWire clients like mpv do not. Maybe a Firefox issue, but probably a Pulse emulation issue since setting mpv to be a pulseaudio client also breaks (silences) its audio output.
Given that the sound system on a laptop is low-powered anyway, I think that it would make an even bigger difference for pro-audio users, but I cannot verify this as I do not have the hardware to check this. I know this is not directly testing cubeb, but I hope this proxy test is useful.
Reacted by jim3692Firefox's cubeb-pulse implementation is totally broken on pipewire. See mozilla/cubeb-pulse-rs#87
Oh yeh there's also this mozilla/cubeb-pulse-rs#86
- Capture apps with audio for getDisplayMedia()
Bump
And let's not forget this all-important feature for screensharing in chat apps. As it stands, since screensharing with audio is not a thing in firefox, I have to use chromium (gross, FF is the best!!) when I want to watch the game with my buddies. Please, don't make me keep using chromium it sucks compared to firefox.... Except if I want to use this one common feature.
Why PipeWire?
* Users and distributions moving from PulseAudio to Pipewire.Why PipeWire indeed? I tried replacing PulseAudio with PipeWire a few months ago and my speakers blew up the next day. That's not the "feature" that they seem to think it is.
Needless to say, I went back to PulseAudio to listen through my headphones. Though, through the experience, I learned about the ALSA dmix/asym plugins and have done as much as I can to ensure that that's used instead of PulseAudio (as I saw on a page about the dmix plugin, PulseAudio and PipeWire are solutions looking for a problem). In fact, the one advantage I see to Chromium over Firefox is that it allows you to use ALSA without starting up PulseAudio (no, setting media.cubeb.backend to alsa doesn't do a thing). The only thing I've ever had against PulseAudio has been it putting dot files in $HOME, but that's solvable through a custom $XDG_CONFIG_HOME/pulse/default.pa (which I also use so that PulseAudio uses the dmix device instead of hw:0).
Eh, maybe using apulse instead of PulseAudio proper will be enough, especially since I've made the PipeWire/WirePlumber service files I had in ~/.config/systemd/user (from when I unfortunately tried them out) point to /dev/null (hopefully, that will be enough to ensure that PipeWire/WirePlumber never start up).
Reacted by runiq, Stefanos, Alberto Fabbri, Benedikt Reinartz, Liv, fmalmsjo, Julius, Mark Dixon, luke, kabuspl and 12 moreAntigravity vibecoded the solution in about an hour: https://gitlab.com/Psypherium2010/firefox-native-pipewire This is an updated version of abandoned solution by Goosesima.
Tested working on youtube.com (output) and gemini.com (input) on a system with ZERO pipewire-pulse or pipewire-alsa libs.
Edit: Original C version deprecated. Rewritten in Rust. Renamed to "cubeb-pipewire-rs". Now passes all gtests. Added even more gtests for High-res audio (up to 192k). It passes those also.
Edit#2: Previously only output functioned, now it has fully working Input/Output+Duplex. input and output device generic names now appear in about:support, alongside default/supported formats and rates.
Edit (01 Sep 2026): Updated helper compilation/install script for current nightly 157.0a1, using it right now to edit this comment.
157.0a1 still has the bug where video freezes when youtube is fullscreen. I have a feeling that might just be extension issues, because audio continues playing and is entirely unaffected.The crossed out part turned out to be a flaw in an unrelated vibecoded extension, disregard.
Also, Firefox default spellcheck dictionary should add the word "vibecoded". Someone could easily vibecode a PR to add all the new English to the FF dictionary.
Reacted by Puqns67 and jim3692
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Why PipeWire?
PipeWire native support pros: