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
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: https://wiki.archlinux.org/index.php/PipeWire#Drop-in_replacement_for_PulseAudio/Jack_(Experimental) 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." elog fi 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: >DEPEND="${CDEPEND} > 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.
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). Edit /etc/pulse/client.conf: ; 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 > call? 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.
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: catbeard Startup Applications ... catbeard disabled pulseaudio in that list btw pinkflames ... Oh, dear, yes, DEs starting PulseAudio on their own is one of the ways it could go wrong ... pinkflames catbeard: btw, thanks, I'll put a note on the pulseaudio bug about cinammon autostarting pulseaudio - is that correct? catbeard ya
You may start by noticing that pulseaudio installs: /etc/xdg/autostart/pulseaudio.desktop
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: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/master/src/daemon/start-pulseaudio-x11.in 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.
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.
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.
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).
Thanks for the explanation, that puts most of the comments into context!
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. See https://wiki.gentoo.org/wiki/Pipewire.
(In reply to Sam James from comment #25) > 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. > > See https://wiki.gentoo.org/wiki/Pipewire. You really can't. I'm on openrc/sddm/kde, I cannot disable pulse and enable pipewire. Any attempt to disable -daemon on pulse results in a block due to numerous other desktop related use flags. Setting daemonize = no inside /etc/pulse/daemon.conf does nothing, as does setting autospawn = no inside /etc/pulse/client.conf. I have these set and on a fresh login: $ ps -A|grep -e puls -e pipe 7255 ? 00:00:00 pulseaudio 7983 ? 00:00:00 pipewire Note, no pipewire-media-session is running. I have copied the contents of /usr/share/pipewire to /etc and relevant section already looked like this: context.exec = [ #{ path = <program-name> [ args = "<arguments>" ] } # # Execute the given program with arguments. # # You can optionally start the session manager here, # but it is better to start it as a systemd service. # Run the session manager with -h for options. # { path = "/usr/bin/pipewire-media-session" args = "" } # # You can optionally start the pulseaudio-server here as well # but it is better to start it as a systemd service. # It can be interesting to start another daemon here that listens # on another address with the -a option (eg. -a tcp:4713). # { path = "/usr/bin/pipewire" args = "-c pipewire-pulse.conf" } ] So, no need to uncomment anything. I still have pulse running: $ pactl info|grep String Server String: /run/user/1000/pulse/native
(In reply to Luke A. Guest from comment #26) > (In reply to Sam James from comment #25) > > 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. > > > > See https://wiki.gentoo.org/wiki/Pipewire. > > You really can't. > > I'm on openrc/sddm/kde, I cannot disable pulse and enable pipewire. > You really can, and I’ve done it in exactly that environment. On two machines. > Any attempt to disable -daemon on pulse results in a block due to numerous > other desktop related use flags. > > Setting daemonize = no inside /etc/pulse/daemon.conf does nothing, as does > setting autospawn = no inside /etc/pulse/client.conf. I have these set and > on a fresh login: I don’t see why that should have no effect? You can try PA 15? Seems like this needs a new bug.
(In reply to Luke A. Guest from comment #26) > (In reply to Sam James from comment #25) > > 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. > > > > See https://wiki.gentoo.org/wiki/Pipewire. > > You really can't. > > I'm on openrc/sddm/kde, I cannot disable pulse and enable pipewire. > > Any attempt to disable -daemon on pulse results in a block due to numerous > other desktop related use flags. > This sounds odd. Very little if anything should depend on the daemon and wasn’t the USE flag new in 15? I turned it off without incident. Perhaps it’d be worth exploring what these numerous issues are. But in a new bug.
(In reply to Sam James from comment #27) > (In reply to Luke A. Guest from comment #26) > > (In reply to Sam James from comment #25) > > > 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. > > > > > > See https://wiki.gentoo.org/wiki/Pipewire. > > > > You really can't. > > > > I'm on openrc/sddm/kde, I cannot disable pulse and enable pipewire. > > > > You really can, and I’ve done it in exactly that environment. On two > machines. > > > > Any attempt to disable -daemon on pulse results in a block due to numerous > > other desktop related use flags. > > > > Setting daemonize = no inside /etc/pulse/daemon.conf does nothing, as does > > setting autospawn = no inside /etc/pulse/client.conf. I have these set and > > on a fresh login: > > I don’t see why that should have no effect? You can try PA 15? media-sound/pulseaudio Available versions: 13.0-r1^t (~)15.0-r1^t [M](~)15.0-r100 [M]**9999*l[2] {+X +alsa +alsa-plugin +asyncns bluetooth +caps +daemon dbus doc elogind equalizer gconf +gdbm +glib gstreamer gtk ipv6 jack libressl libsamplerate lirc native-headset neon ofono-headset +orc oss qt5 realtime selinux sox ssl system-wide systemd tcpd test +udev +webrtc-aec zeroconf ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" CPU_FLAGS_ARM="neon" KERNEL="linux"} Installed versions: 15.0-r1^t(21:22:21 15/10/21)(X alsa alsa-plugin asyncns bluetooth daemon dbus elogind equalizer gdbm glib gstreamer gtk ipv6 jack orc ssl tcpd udev webrtc-aec -doc -lirc -native-headset -ofono-headset -oss -selinux -sox -system-wide -systemd -test -zeroconf ABI_MIPS="-n32 -n64 -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32") Homepage: https://www.freedesktop.org/wiki/Software/PulseAudio/ Description: A networked sound server with an advanced plugin system I already have.
(In reply to Sam James from comment #28) > > Any attempt to disable -daemon on pulse results in a block due to numerous > > other desktop related use flags. > > > > This sounds odd. Very little if anything should depend on the daemon and > wasn’t the USE flag new in 15? I turned it off without incident. Perhaps > it’d be worth exploring what these numerous issues are. But in a new bug. # emerge -av media-sound/pulseaudio These are the packages that would be merged, in order: Calculating dependencies \ !!! Problem resolving dependencies for media-sound/pulseaudio ... done! !!! The ebuild selected to satisfy "media-sound/pulseaudio" has unmet requirements. - media-sound/pulseaudio-15.0-r1::gentoo USE="X alsa alsa-plugin asyncns bluetooth dbus elogind equalizer gdbm glib gstreamer gtk ipv6 jack orc ssl tcpd udev webrtc-aec -daemon -doc -lirc -native-headset -ofono-headset (-oss) (-selinux) -sox (-system-wide) -systemd -test -zeroconf" ABI_X86="32 (64) (-x32)" The following REQUIRED_USE flag constraints are unsatisfied: !daemon? ( !alsa !alsa-plugin !bluetooth !equalizer !gdbm !gstreamer !gtk !jack !orc !ssl !udev !webrtc-aec ) The above constraints are a subset of the following complete expression: alsa-plugin? ( alsa ) bluetooth? ( dbus ) daemon? ( at-most-one-of ( elogind systemd ) ) !daemon? ( !alsa !alsa-plugin !bluetooth !equalizer !gdbm !gstreamer !gtk !jack !lirc !native-headset !ofono-headset !orc !oss !sox !ssl !system-wide !udev !webrtc-aec !zeroconf ) equalizer? ( dbus ) native-headset? ( bluetooth ) ofono-headset? ( bluetooth ) udev? ( any-of ( alsa oss ) ) zeroconf? ( dbus ) # cat /etc/portage/package.use/pulseaudio.use media-sound/pulseaudio -daemon equalizer gnome -libsamplerate
(In reply to Luke A. Guest from comment #29) > (In reply to Sam James from comment #27) > > (In reply to Luke A. Guest from comment #26) > > > (In reply to Sam James from comment #25) > > > > 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. > > > > > > > > See https://wiki.gentoo.org/wiki/Pipewire. > > > > > > You really can't. > > > > > > I'm on openrc/sddm/kde, I cannot disable pulse and enable pipewire. > > > > > > > You really can, and I’ve done it in exactly that environment. On two > > machines. > > > > > > > Any attempt to disable -daemon on pulse results in a block due to numerous > > > other desktop related use flags. > > > > > > Setting daemonize = no inside /etc/pulse/daemon.conf does nothing, as does > > > setting autospawn = no inside /etc/pulse/client.conf. I have these set and > > > on a fresh login: > > > > I don’t see why that should have no effect? You can try PA 15? > > media-sound/pulseaudio > Available versions: 13.0-r1^t (~)15.0-r1^t [M](~)15.0-r100 > [M]**9999*l[2] {+X +alsa +alsa-plugin +asyncns bluetooth +caps +daemon dbus > doc elogind equalizer gconf +gdbm +glib gstreamer gtk ipv6 jack libressl > libsamplerate lirc native-headset neon ofono-headset +orc oss qt5 realtime > selinux sox ssl system-wide systemd tcpd test +udev +webrtc-aec zeroconf > ABI_MIPS="n32 n64 o32" ABI_S390="32 64" ABI_X86="32 64 x32" > CPU_FLAGS_ARM="neon" KERNEL="linux"} > Installed versions: 15.0-r1^t(21:22:21 15/10/21)(X alsa alsa-plugin > asyncns bluetooth daemon dbus elogind equalizer gdbm glib gstreamer gtk ipv6 > jack orc ssl tcpd udev webrtc-aec -doc -lirc -native-headset -ofono-headset > -oss -selinux -sox -system-wide -systemd -test -zeroconf ABI_MIPS="-n32 -n64 > -o32" ABI_S390="-32 -64" ABI_X86="32 64 -x32") > Homepage: > https://www.freedesktop.org/wiki/Software/PulseAudio/ > Description: A networked sound server with an advanced plugin > system > > I already have. and I just emerged 13.0-r1 and I get the same results as above.
(In reply to Luke A. Guest from comment #30) > (In reply to Sam James from comment #28) > > > > Any attempt to disable -daemon on pulse results in a block due to numerous > > > other desktop related use flags. > > > > > > > This sounds odd. Very little if anything should depend on the daemon and > > wasn’t the USE flag new in 15? I turned it off without incident. Perhaps > > it’d be worth exploring what these numerous issues are. But in a new bug. That flag doesn't exist on 13. # emerge -av media-sound/pulseaudio These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-sound/pulseaudio-13.0-r1::gentoo USE="X alsa alsa-plugin asyncns bluetooth caps dbus elogind equalizer gdbm glib gtk ipv6 jack orc qt5 ssl tcpd udev webrtc-aec -doc -gconf -libsamplerate -lirc -native-headset -ofono-headset (-oss) -realtime (-selinux) -sox (-system-wide) -systemd -test -zeroconf" ABI_X86="32 (64) (-x32)" 0 KiB
works fine ---------- ~ $ emerge -avtp pulseaudio::gentoo These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild R ] media-sound/pulseaudio-15.0-r1::gentoo [15.0-r1::pg_overlay] USE="glib -X -alsa -alsa-plugin -asyncns -bluetooth -daemon -dbus -doc -elogind -equalizer -gdbm -gstreamer -gtk -ipv6 -jack -lirc -native-headset -ofono-headset -orc (-oss) (-selinux) -sox -ssl (-system-wide) -systemd -tcpd -test -udev -webrtc-aec -zeroconf" 1,487 KiB Total: 1 package (1 reinstall), Size of downloads: 1,487 KiB ------------------------------------------------------------
Ok, got this thing working now. Had to delete ~/.config/{pulse,pipewire} and a call in my shell script to start pulse I'd forgotten I had.
(In reply to Luke A. Guest from comment #32) > That flag doesn't exist on 13. > Yep, that was my point. Just that I would expect totally different behaviour with 15 and nothing should've been relying on a flag which didn't exist. (In reply to Luke A. Guest from comment #34) > Ok, got this thing working now. Had to delete ~/.config/{pulse,pipewire} and > a call in my shell script to start pulse I'd forgotten I had. That'd do it. Glad you are sorted. (In reply to Luke A. Guest from comment #30) > (In reply to Sam James from comment #28) > The following REQUIRED_USE flag constraints are unsatisfied: > !daemon? ( !alsa !alsa-plugin !bluetooth !equalizer !gdbm !gstreamer > !gtk !jack !orc !ssl !udev !webrtc-aec ) These aren't conflicts per-se, but REQUIRED_USE changes you'd need to make. I was able to make them safely. leio has been working on a better approach for this though with splitting the packages.
First of all, this is my 1st message here. The pulseaudio flag (daemon) was locked by kde-plasma/plasma-pa package. So, I removed the package: # emerge --deselect kde-plasma/plasma-pa After: # emerge -a --depclean I rebooted and no more pulseaudio instances. I dont know if it is the case. It is only for information.
(In reply to Leandro Cerencio from comment #36) > First of all, this is my 1st message here. The pulseaudio flag (daemon) was > locked by kde-plasma/plasma-pa package. > > So, I removed the package: > # emerge --deselect kde-plasma/plasma-pa plasma-pa is fine with pipewire (I use it too!): https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-plasma/plasma-pa/plasma-pa-5.23.4.ebuild#n34.
For those following along, remaining steps: - Figure out blocker for stabilisation of latest versions (see bug 827546#c4; we need to avoid wireplumber always taking over?) - Need to handle libpulse packages and make dependencies more finely-grained, see bug 536780.
To expand on the above, only one daemon can have audio capabilities - either PulseAudio or PipeWire with audio support. The last state of things that I'm aware of is that PipeWire would de facto replace PulseAudio in Gentoo, and those who want to keep using PulseAudio would have to manually take steps to either not run PipeWire or to disable its audio support inside the PW session manager.
For what it's worth, Debian seem to have also given up on trying to offer choice between PA and PW and currently intend to eventually do a distro wide switch to PW: https://bugs.launchpad.net/ubuntu/+source/pipewire-media-session/+bug/1953052/comments/49 To avoid confusion, I'll make it clear that Debian 11 already can have PipeWire for audio but it's a strictly opt-in that users have to manually do. And it's likely that they'll keep offering the PulseAudio daemon for a manual opt-out but it's unlikely there will be any user friendly choice possible. Instead at some point they'll switch the default and that will be that. And, yes, that's basically what the current plan for Gentoo is, too.
To avoid confusing the user in bug 840278 I'll post the executive summary here in hopes that someone who is authorized to make the decision will see. To recap, systemd user units are good but for OpenRC the XDG launcher script is a bad idea that has a very real possibility to (semi-)randomly brick audio. The available solutions (none of which are good): 1. Do not install /etc/xdg/autostart/pipewire.desktop => Wayland screen sharing will no longer work out of the box when using OpenRC but PulseAudio will always work as it used to a year ago 2. Comment out starting pipewire-pulse in gentoo-pipewire-launcher AND conditional on -systemd USE patch WirePlumber configuration to disable all audio => Wayland screen sharing works for XDG compliant shells out of the box when using OpenRC but users who want PipeWire audio must manually undo all the changes and disable PulseAudio autospawning 3. Set `autospawn = no` in /etc/pulse/client.conf AND make media-video/pipewire a dependency in media-sound/pulseaudio => transitions all OpenRC users with PulseAudio to PipeWire (which would be fine if not for the unknown number of driver bugs remaining which PW exposes as well as uncertainty about the worst hardware/software configuration readiness to handle 5 ms latency which some PulseAudio clients may end up getting upon requesting the lowest possible latency). 4. Same as 3. but instead of disabling autospawning accelerate unmasking of media-sound/pulseaudio-daemon => still the same problems 5. Same as 2 but instead of conditionally patching WirePlumber configuration, instead make media-video/pipewire not build both ALSA and Bluetooth backends => has the dubious improvement of allowing systemd as well to have PipeWire+WirePlumber but with /usr/bin/pulseaudio sound daemon, however despite this being a known solution, no one has wanted to ACK that as a viable path (I can only guess that it's due to the fact that either both ALSA and BlueZ would need to be rolled into one IUSE or there would be a need for the much disliked REQUIRED_USE to get USE flag relationships right).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4c081daccde5db94acf5894ba2653188ad6cea0 commit d4c081daccde5db94acf5894ba2653188ad6cea0 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-04-29 00:57:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-29 00:57:06 +0000 profiles: unmask split pulseaudio packages This is a move towards making it easier for users to choose between pulseaudio and pipewire for their audio needs. We now have: - media-sound/pulseaudio (a transitory metapackage, installs no files, just enforces deps with USE flags); - media-libs/libpulse (the pulseaudio libraries, needed by clients using pulseaudio's protocol to speak to pipewire, but is not the pulseaudio daemon) - media-sound/pulseaudio-daemon (the pulseaudio daemon, to be used instead of pipewire if desired) While these are technically RC/pre-releases (and I have a strong reluctance against keywording those usually), we have a good relationship with upstream who report they've been quiet developmentwise since these tags, these versions have been tested & work well, and this will help to improve the experience for Gentoo users in choosing which audio server they want. So, all in all, a win. Bug: https://bugs.gentoo.org/536780 Bug: https://bugs.gentoo.org/744622 Bug: https://bugs.gentoo.org/827546 Bug: https://bugs.gentoo.org/841494 Signed-off-by: Sam James <sam@gentoo.org> profiles/package.mask | 6 ------ 1 file changed, 6 deletions(-)
My take on this, seeing that I have regrettably unleashed this on unsuspecting users. All in all I am in favour of solution 2 from Comment 41, with a few modifications: 1. I would use a different USE flag name here - something like "replace-pulseaudio", perhaps? All these hacks may only affects OpenRC users but I can very much imagine the case of a systemd user preferring to stick with PA for sound as well; 2. Seeing as gentoo-pipewire-launcher is generated from template at build time, it should be straightforward to omit the line starting pipewire-pulse in the USE-replace-pulseaudio case. Still, should that be undesired another option might be to make the starting of pipewire-pulse in gentoo-pipewire-launcher depend on the presence of a semaphore file, installed (in /usr/share/pipewire for instance - I'd avoid /etc here because it could lead the users to believe they could change this behaviour by hand rather than by rebuilding with different USE flags) only if USE=replace-pulseaudio is set; 3. We might want to make PW depend on "|| pulseaudio-daemon pulseaudio" for the USE=-replace-pulseaudio case. Then again, will it be necessary? I have never used the screen-sharing functionality of PW so I've got no idea what it might do with neither PA nor PW handling the sound; 4. Likely unnecessary to mention but just in case - both scenarios should clearly explain to the users what they need to do, especially if they have PA installed but have just switched to PW. WDYT? If it makes sense I can cobble together the necessary changes and discuss them further on IRC.
systemd users are not heavily impacted because they already explicitly choose to run or not run PipeWire and its related user units. Of course running both PW and PA daemons would still be a problem but as I have said time and time again, this is mostly a theoretical what-if scenario rather than an actual use case, because very few users actually use the Wayland screen capture in the first place (and are likely to prefer using PipeWire anyway, since they went through the effort of using Wayland instead of the more default X11). Furthermore in some unspecified future point WirePlumber should gain the ability to easily disable audio support via JSON drop-in configuration files, so it might not be worth engineering a bad solution to a problem that might go away in a few more months. >3. We might want to make PW depend on "|| pulseaudio-daemon pulseaudio" for the >USE=-replace-pulseaudio case. Then again, will it be necessary? I have never used >the screen-sharing functionality of PW so I've got no idea what it might do with >neither PA nor PW handling the sound; The core issue is that you can't right now disable PipeWire doing audio in the first place, because it either requires changing the scripts of WirePlumber (which no one seems to want to accept on Gentoo side due to the maintenance burden of then having to keep them up to date with upstream changes) or it would mean not installing the ALSA and BlueZ backends for PipeWire (this then would likely cause REQUIRED_USE to be needed to get the dependencies right regarding other IUSE for PipeWire and leio will not accept that for a package that all GNOME users need). But should it be possible, IMO, it does not really make sense to make PipeWire require anything related to PulseAudio, since nothing in PipeWire has any dependency on anything PulseAudio, nor does PipeWire project make any kind of promises about PulseAudio API being always usable with it. Finally, I do not want to go over everything to double check but, I think, thanks to Igor V. Kovalenko and Sam James we already have most or maybe all of 4. implemented and shipping to ~testing users (see comment 42 and related commits).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=252b10a3e7c5b5b482c98dec8cd217eba4c67c20 commit 252b10a3e7c5b5b482c98dec8cd217eba4c67c20 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-15 07:57:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-20 05:12:43 +0000 profiles: add "screencast" global USE Bug: https://bugs.gentoo.org/744622 Bug: https://bugs.gentoo.org/818253 Signed-off-by: Sam James <sam@gentoo.org> profiles/use.desc | 1 + 1 file changed, 1 insertion(+)
Once bug 859280 is fixed (see comment there for need for a news item), I think we're done.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=1d217ffd5deca9d20b61acd2a7832272d036a0e0 commit 1d217ffd5deca9d20b61acd2a7832272d036a0e0 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-29 01:44:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-29 01:44:47 +0000 2022-07-29-pipewire-sound-server: add item Bug: https://bugs.gentoo.org/744622 Bug: https://bugs.gentoo.org/859280 Signed-off-by: Sam James <sam@gentoo.org> .../2022-07-29-pipewire-sound-server.en.txt | 130 +++++++++++++++++++++ 1 file changed, 130 insertions(+)
I've just followed the instructions in that news item for switching to PipeWire, and there seems to be a problem. I currently use PulseAudio and would like to use PipeWire instead, so I followed the instructions for doing that (path 1 in the item). No changes to audio packages were made when I ran emerge. media-libs/libpulse (all versions currently available) seems to have a hard dependency on media-sound/pulseaudio-daemon, which blocks the Pipewire install even if the PulseAudio metapackage has USE=-daemon set (removes *its* dependency on pulseaudio-daemon, but not libpulse's). Have I missed a step here? Or are the instructions in the news item meant to prepare for a future change, rather than causing an immediate change? I should note that PipeWire was not previously installed, and media-sound/pulseaudio-daemon was.
(In reply to stephen.smith3141 from comment #48) > I've just followed the instructions in that news item for switching to > PipeWire, and there seems to be a problem. > > I currently use PulseAudio and would like to use PipeWire instead, so I > followed the instructions for doing that (path 1 in the item). No changes to > audio packages were made when I ran emerge. > > media-libs/libpulse (all versions currently available) seems to have a hard > dependency on media-sound/pulseaudio-daemon, which blocks the Pipewire > install even if the PulseAudio metapackage has USE=-daemon set (removes > *its* dependency on pulseaudio-daemon, but not libpulse's). That's not correct: https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/libpulse/libpulse-16.1.ebuild#n70. It depends on any one of the options in the || ( ... ) block. It's possible that e.g. ABI_X86 flags need to be changed in your /etc/portage to allow Portage to change to pipewire for you. The full (no truncation) emerge -p -uvDU @world output would be needed to debug further, but please file a new bug for that given how long this one is already. > > Have I missed a step here? Or are the instructions in the news item meant to > prepare for a future change, rather than causing an immediate change? > All the needed changes are applied in the repo. > I should note that PipeWire was not previously installed, and > media-sound/pulseaudio-daemon was.
