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?
I do not understand your report. Please explain it in proper English. We can help via IRC.
PipeWire can be a drop-in replacement for pulseaudio:
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.
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? (
> || (
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.
Another option could be to have a eselect-pulseaudio so can coexist with pulseaudio proper and have the selected libraries used.
I am not sure if you can do something systemwise...
but if you do this:
LD_PRELOAD=/usr/lib64/pipewire-0.3/pulse/libpulse.so.0 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/libpulse.so -> /usr/lib64/pipewire-0.3/pulse/libpulse.so.0
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. :)
I just found out... pipewire is not compiled for 32 bits so 32 bits application probably wont work.
I will open a new bug.
multilib support really is of secondary priority while $summary wasn't even started yet.
*** Bug 750014 has been marked as a duplicate of this bug. ***
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 :)
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).
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.
(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).
; autospawn = yes
autospawn = no # for pipewire
How is this decision going to be made, one way or another - who makes the call?
(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
It's about letting it replace rather than killing pulseaudio. People will have the choice.
Unless something has recently changed, I do not believe the upstream is planning on replacing libpulse.so 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.
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.
(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.