PipeWire support

[goosesima]

Why PipeWire?

• Users and distributions moving from PulseAudio to Pipewire.

• PipeWire native support pros:

• Low latency.
• Capture apps with audio for getDisplayMedia()
• Less memory usage, not need in run pipewire-pulse and much stable experience.
• Don't need install other dependencies (for PulseAudio or other audio backend).

[dreamcat4]

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

[goosesima]

Trying to implement PipeWire support: https://github.com/goosesima/cubeb-pipewire test_audio already works with PipeWire.

[padenot]

It'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.

[SopaDeMacaco-UmaDelicia]

Kinda sad that Mozilla doesn't implement it itself. Since it's a pulseaudio successor on Linux desktop it should have Tier 1 attention.

[behunin]

Another bump to this issue, this feature is needed.

[ChunMinChang]

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

[behunin]

@ChunMinChang mpv-player recently added pipewire support -- https://github.com/mpv-player/mpv/issues/8569 -- https://github.com/mpv-player/mpv/pull/9587 -- https://github.com/mpv-player/mpv/pull/9734

It is only audio out though.

[apprehensions]

Boop.

[padenot]

The 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?

[apprehensions]

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.

[padenot]

Has 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.

cubeb won'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 cubeb only need libpulse, we're talking a few hundred kilobytes on disk here and some memory for pipewire-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.

[pallaswept]

• Capture apps with audio for getDisplayMedia()

Bump

[ndren]

Has 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 audiofile vs paplay audiofile had 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 audiofile is more responsive to Ctrl-Z (SIGSTOP) compared to paplay audiofile, the latter taking a few seconds before playback actually stops. The same is for restarts with fg (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.

[pallaswept]

Firefox's cubeb-pulse implementation is totally broken on pipewire. See https://github.com/mozilla/cubeb-pulse-rs/issues/87

[pallaswept]

Oh yeh there's also this https://github.com/mozilla/cubeb-pulse-rs/issues/86

[pallaswept]

• 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.

[keithbowes]

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).