Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 744622 - media-video/pipewire: replace pulseaudio
Summary: media-video/pipewire: replace pulseaudio
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 18 votes (vote)
Assignee: Gentoo Linux Gnome Desktop Team
: 750014 (view as bug list)
Depends on: 775386
  Show dependency tree
Reported: 2020-09-25 11:49 UTC by Fpemud
Modified: 2021-09-14 05:50 UTC (History)
32 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Fpemud 2020-09-25 11:49:23 UTC
This is the next step naturally since the libraries for pulseaudio emulation is installed by the the latest version of the ebuild.
maybe there would be a new virual/pulseaudio package?

Reproducible: Always
Comment 1 Jonas Stein gentoo-dev 2020-09-27 19:43:55 UTC
I do not understand your report. Please explain it in proper English. We can help via IRC.
Comment 2 Fpemud 2020-09-28 09:42:37 UTC
PipeWire can be a drop-in replacement for pulseaudio:

In pipewire-0.3.10.ebuild:
 if use pulseaudio; then
   elog "Please note that even though the libraries for PulseAudio emulation have"
   elog "been installed, this ebuild is not yet wired up to replace PulseAudio."

So I think the next step should be actually replace pulseaudio with pipewire.
Maybe a new "virual/pulseaudio" should be created and make all pulseaudio dependencies depend on this package instead.
Comment 3 Ionen Wolkens gentoo-dev 2020-09-30 02:17:45 UTC
In the event that a virtual/pulseaudio was created, apulse[sdk] may also be worth remembering as a candidate for it.

With USE=sdk it even provide headers so packages can seamlessly build without pulseaudio installed at all (and apulse wrapper is never needed), firefox notably support this:
>    pulseaudio? (
>        || (
>            media-sound/pulseaudio
>            >=media-sound/apulse-0.1.12-r4[sdk]
>        )
>    )
pipewire would need to deal with the headers issue as well if don't want to depend on pulseaudio (or maybe pulseaudio could have a USE=headers-only?)

That aside, both pipewire and apulse do raise compatibility concerns and may not be suitable for every packages.
Comment 4 Ionen Wolkens gentoo-dev 2020-09-30 02:34:48 UTC
Another option could be to have a eselect-pulseaudio so can coexist with pulseaudio proper and have the selected libraries used.
Comment 5 mercuriete 2020-10-18 20:52:05 UTC
I am not sure if you can do something systemwise...
but if you do this:

LD_PRELOAD=/usr/lib64/pipewire-0.3/pulse/ pactl info

the command returns:

Server String: pipewire-0

So you can try by yourself to replace LD_PRELOAD systemwise but I didn't try it.

another solution is to do a soft link from:

/usr/lib64/  ->  /usr/lib64/pipewire-0.3/pulse/

but I didnt try it neither.

Right now I am trying to start a steam game with pipewire but I couldnt do it.

I hope somewhere in the future we can replace pulse entirely. :)
Comment 6 mercuriete 2020-10-18 21:02:53 UTC
I just found out... pipewire is not compiled for 32 bits so 32 bits application probably wont work.

I will open a new bug.
Comment 7 Andreas Sturmlechner gentoo-dev 2020-10-18 21:10:02 UTC
multilib support really is of secondary priority while $summary wasn't even started yet.
Comment 8 Andreas Sturmlechner gentoo-dev 2020-10-18 21:28:22 UTC
*** Bug 750014 has been marked as a duplicate of this bug. ***
Comment 9 mercuriete 2020-10-19 18:46:59 UTC
ok, if the 750014 if a duplicated of this bug...

then I want to remember that not only is a replacement for pulseaudio but for jack as well.

in fact... pipewire as jack replacement is very interesting because pipewire does the bridge between alsa midi and a jack client without any bridge and it does a pulseaudio to jack sink without any further configuration.

thanks for your work, is amazing :)
Comment 10 Aidan Harris 2020-11-25 21:18:22 UTC
This will be pretty easy with the next version (0.3.16) of PipeWire which deprecates the libpulse drop-in library and instead ships its own pulseaudio daemon replacement. Now you just need to run pipewire-pulse and everything wanting to use pulseaudio will "just work" (`pactl info` shows "Server Name: PulseAudio (on PipeWire 0.3.16)").

I did run into a slight issue though, software likes to auto-spawn pulseaudio if it's not running (e.g before pipewire-pulse has started). I solved this by removing the executable bit from /usr/bin/pulseaudio which is an ugly hack but works for now. I think media-sound/pulseaudio could use a "client" and "server" useflag ("client" controlling the installation of tools like `pactl` and "server" controlling the installation of the pulseaudio server).
Comment 11 Ionen Wolkens gentoo-dev 2020-11-26 23:08:29 UTC
Haven't tried but believe you can change (in client.conf):
    daemon-binary = /usr/bin/pulseaudio
So that it'll just spawn the one you want.

That aside, if they deprecate the library I guess my previous idea to all-in-one eselect runtime libraries with apulse+pirewire won't be usable.
Comment 12 Adrian Bassett 2020-12-13 14:06:29 UTC
(In reply to Aidan Harris from comment #10)

> I did run into a slight issue though, software likes to auto-spawn
> pulseaudio if it's not running (e.g before pipewire-pulse has started).
> pulseaudio server).

Edit /etc/pulse/client.conf:

; autospawn = yes
autospawn = no # for pipewire
Comment 13 Leho Kraav (:macmaN @lkraav) 2021-02-12 12:48:49 UTC
How is this decision going to be made, one way or another - who makes the call?
Comment 14 Sam James archtester gentoo-dev Security 2021-03-22 23:52:34 UTC
(In reply to Leho Kraav (:macmaN @lkraav) from comment #13)
> How is this decision going to be made, one way or another - who makes the
> call?

It's about letting it replace rather than killing pulseaudio. People will have the choice.
Comment 15 Niklāvs Koļesņikovs 2021-03-23 09:16:26 UTC
Unless something has recently changed, I do not believe the upstream is planning on replacing et al any time soon (i.e. the original libraries and headers will be with us for a considerable while). Meanwhile pipewire-pulse works reasonably well on systemd, when using using the pipewire-pulse.socket. And on OpenRC the replacement daemon should work reasonably well, too, so long as one avoids running any PulseAudio applications before pipewire and pipewire-pulse have started. On OpenRC disabling PulseAudio autospawning is optional but probably a good idea.

In other words, it's about as replaceable right now as it will be. There's, of course, a bit more Gentoo could do to make it easier and just slightly more reliable (just slightly), and people are working on it. But it won't be quick.

Please note the word reasonably well for both systemd and OpenRC - PipeWire is still at version 0.3 after all, and pipewire-pulse was not upstream's first choice for providing PulseAudio support, but it's the only one we've got for the foreseeable future.
Comment 16 Eternal Sorrow 2021-03-23 10:04:56 UTC
The only thing that can be done right now in my opinion is add USE flag to build pulseaudio as libpulse only, without pulseaudio daemon.
Comment 17 Perfect Gentleman 2021-03-23 10:09:57 UTC
(In reply to Eternal Sorrow from comment #16)
> The only thing that can be done right now in my opinion is add USE flag to
> build pulseaudio as libpulse only, without pulseaudio daemon.

That would be good idea.
I've been using pipewire as pulseaudio replacement on KDE-OpenRC since 0.3.16. With every release it's getting better and better. I've modified ebuild to build pipewire against elogind, but I'm not sure if it works properly.
Comment 18 Niklāvs Koļesņikovs 2021-04-21 22:56:13 UTC
A user on #gentoo IRC channel with the handle catbeard has confirmed my worst fears - some desktop environments do autostart PulseAudio by default - this means that both XDG autostart and even our existing instructions for PipeWire users either need to take that into consideration, or we *really* need to make sure that the pulseaudio daemon can be disabled for good, such as, depending on USE flags, either not compiling the it or worst case just rm'ing ${ED}/usr/bin/pulseaudio during src_install phase to avoid bad things from happening.

The relevant bits from IRC conversation on #gentoo:
Startup Applications
disabled pulseaudio in that list btw
Oh, dear, yes, DEs starting PulseAudio on their own is one of the ways it could go wrong
catbeard: btw, thanks, I'll put a note on the pulseaudio bug about cinammon autostarting pulseaudio - is that correct?
Comment 19 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-04-22 06:35:05 UTC
You may start by noticing that pulseaudio installs:

Comment 20 Niklāvs Koļesņikovs 2021-04-22 13:33:58 UTC
The file is actually misnamed. ;) As a Wayland user without X, I can't verify its content on my system but I believe from its source code (discovered by Whissi) that it actually corresponds to this file:

Which, from my very best understanding, is responsible for integrating with X11 (possibly for networked sound?). However this does not start PulseAudio itself - that is done normally via the autospawn'ing that is controlled by /etc/pulse/client.conf but for some reason at least Cinnamon also starts it manually, leading to me ringing the warning bell on this.
Comment 21 Niklāvs Koļesņikovs 2021-04-22 13:41:00 UTC
After thinking some more, sorry and thank you, Michał - I now understand you meant the file the user found and disabled from autostarting is actually /etc/xdg/pulseaudio.desktop which despite the Comment= should not actually be starting pulseaudio daemon (at least I'm not aware of any cases with Plasma or GNOME where disabling autospawning wouldn't have been sufficient to stop pulseaudio from autostarting).

False alarm. Excuse the noise.
Comment 22 Michael 'veremitz' Everitt 2021-04-22 16:41:55 UTC
Coming late to the 'party' and somewhat confused by the bug title, and other issues raised in comments:

- "Replacement" of pulseaudio or transitioning from <sound provider A> to <sound provider B> might be better served by a TRACKER bug, this could conceivably be it. That said I don't believe any of {ALSA|Jack|PulseAudio|Pipewire} are going anywhere [obsolete] any time Soon™ *
+ co-existence of pulseaudio/pipewire should be as feasible as co-existence of any of the other sound daemons/packages already is. Is there an[other] issue here?

- re: Pulseaudio starting up in DE - if media-sound/pulseaudio is NOT installed (and/or media-video/pipewire), is there [still] an issue with daemon startup scripts? I'm reading comments which imply its included in Desktop Environments [ebuilds] which I believe to be misleading...

- relevant init system support (where applicable) for media-sound/pulseaudio & media-video/pipewire should probably be covered elsewhere too. Pulseaudio is normally tied into the X session of the user, and is unsupported upstream as a system service. I can't vouch for pipewire - does this run "per-user" or per-system, or rely on some other service eg. dbus?

TL;DR - what/which issue are we addressing here, and can we title the bug to reflect that, and then reference any other relevant bugs in the usual places? Thanks!

* My assertions/assumptions/knowledge of some of these areas may be incomplete. Please forgive any omissions, and provide corrections if/when appropriate. TIA.
Comment 23 Niklāvs Koļesņikovs 2021-04-22 19:25:51 UTC
Executive summary: current versions of PipeWire can replace the /usr/bin/pulseaudio with /usr/bin/pipewire-pulse but media-sound/pulseaudio still needs to be installed for libraries and headers. Originally PipeWire intended to replace them just like for JACK (landed in 0.3.26; draft PR on GitHub for Gentoo) but my understanding is that this has been indefinitely postponed if not canceled in favor of using the pipewire-pulse.

As for co-existance on the same system - they can be installed at the same time but the only way you're running pipewire and pulseaudio at the same time is by using PipeWire without pipewire-pulse (no idea how well that handles audio, if at all, but it used to be the Gentoo default before 0.3.25). <A paragraph on Linux audio stack Frankensteining omitted for brevity [and to save people from creating a monster].>

With auto-spawning disabled, switching between PipeWire's stack and PulseAudio is as easy as killing the existing daemons and launching the new one. For some reason one person on #gentoo IRC channel had to log out for the initial switch but I have confirmed that runtime replacing of the daemons is very much feasible on both OpenRC and systemd (whether any running program will reconnect to the new daemons is at least in-part up to that application).

You are correct in asserting that no currently known desktop environment includes a script for explicitly starting pulseaudio directly - instead all known ways of how PulseAudio might get started involve indirect startup governed the autospawn option in /etc/pulse/client.conf - e.g. that /etc/xdg/autostart/pulseaudio.desktop file calls pactl which in turn would start /usr/bin/pulseaudio if it wasn't already running.

You are overall correct on the init systems and system-wide being unsupported. The main thing to add is that both PipeWire and PulseAudio use optional logind integration, and both upstreams recommend system users to use the provided user units with socket activation.

As for a tracking bug, it would, IMO, only make sense if Gentoo throws some serious effort behind it to uncover all the various issues similar to the multiple slibtool trackers - otherwise it would be just an inferior version of the upstream's issue tracker. In general compatibility is good (but bugs and regressions do exist).
Comment 24 Michael 'veremitz' Everitt 2021-04-23 01:51:52 UTC
Thanks for the explanation, that puts most of the comments into context!
Comment 25 Sam James archtester gentoo-dev Security 2021-09-14 05:50:48 UTC
For those watching, note that PipeWire works pretty well at this point when emulating PulseAudio. You can disable running the Pulse daemon with a config option or even emerge 15.x with -daemon.