After updating and reviewing elog messages I found this: LOG: postinst Contrary to what some online resources may suggest, avoid setting PULSE_LATENCY_MSEC environment variable since it may break ALSA clients. JACK emulation is incomplete and not all programs will work. PipeWire's alternative libraries have been installed to a non-default location. To use them, put pw-jack <application> before every JACK application. When using pw-jack, do not run jackd/jackdbus. However, a virtual/jack provider is still needed to compile the JACK applications themselves. Per Gentoo policy installed systemd units must be manually enabled: systemctl --user disable pulseaudio.service pulseaudio.socket systemctl --user enable pipewire.socket pipewire-pulse.socket Rebooting is strongly recommended to avoid surprises from remnant PulseAudio daemon auto-spawning and surviving logouts. WARN: postinst Both new users and those upgrading need to enable pipewire-media-session: systemctl --user enable pipewire-media-session.service LOG: postinst The following can be installed for optional runtime features: net-misc/ofono for better BT headset support (daemon startup required) ___________ But that will lead to replacing pulseaudio with pipewire... Maybe the message should be adapted for setups wanting to keep pulseaudio usage and only getting pipewire installed due to some dependencies pulling it in Thanks
On systemd, if the user does none of the commands listed, literally nothing will change or happen. It could indeed be confusing, so I'll try improving the message in an already open PR. Thank you for bringing this up. As for using it for screencasting, I tried KRFB recently exactly for the purposes of testing and documenting PipeWire with PulseAudio, and KRFB crashed the first two times and on the third attempt KRDC refused to accept the server address as valid, so the only recommendation I can make for non-audio right now would be to not use KRFB and KRDC. ;) I plan on retesting screencasting once OBS ships with xdg-desktop-portal support.
After looking at the scarce documentation I could find I have concluded that for screencasting pipewire-media-session is likely needed but building it is dependent on ALSA being enabled at build time. However, this will cause PipeWire to take up ALSA devices by default, meaning that for it to coexist with PulseAudio daemon, pipewire-media-session configuration needs to be changed. Maybe I'm misremembering things but changing config based on IUSE without changing build configuration is a QA violation, so, if my guess that pipewire-media-session is needed is correct, that leaves manual user intervention as the only way to retain the old behavior. Looking at https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/0.3.22/src/examples/meson.build#L68 it seems that media-session is already dependent on ALSA in 0.3.22 that's the latest stable version in Portage tree (and still using the pre-overhaul ebuild), therefore screencasting without replacing the pulseaudio daemon might already be broken with all PipeWire versions currently offered by Gentoo.
Pipewire is going to replace pulseaudio. It's like systemd replacing other services like DNS resolver, NTP, NetworkManager... Is it possible to stick to pulseaudio? Sure, but you are own your own here... But maybe I am missing your point here. Pacho, could you please show us what you have in mind?
I also want to migrate to pipewire... but are you sure it's already possible to completely migrate? Last time I checked (I don't remember if it was looking to Fedora or Debian tracker) there were still some bugs in their trackers showing some problems with other apps... Of course they were going to addressed them... but at that time they were still in progress to fix. Then, as pipewire is already a dependency of, for example, gnome-shell... people would be forced to also migrate completely to pipewire as soon as they pull in newer pipewire. My feeling was that we were going to need to time still having both "co-existing" (as currently do with older pipewire versions). But if that is not possible, no problem... I thought it was still possible to temporally stick with pulseaudio running and pipewire only used for the software specifically needing it
I am not a heavy Linux desktop user and my audio experience is limited to built-in notebook sound or USB headset: For my setup I can say that my pulsewire to pipewire upgrade experience was good -- as OpenRC user I was facing the problem that I had to manually start pipewire (which wasn't needed with pulseaudio) and was more challenging than expected but this is solved since 0.3.26. systemd user should have a better experience from day one because of socket activation. Your last comment sounds like there is a misunderstanding: You will still be able to use pulseaudio -- just *through* pipewire. So in the end, nothing should change for you. It's only important that pipewire daemon will replace pulseaudio daemon.
With PulseAudio autospawning disabled in /etc/pulse/client.conf, it is possible to switch between pipewire and pulseaudio daemons at runtime by killing the old one and starting a new daemon. It would, however, be tricky to run them at the same time if screencasting really needs pipewire-media-session to function. Not impossible but it would likely involve manual modifications that we generally do not support, because users are likely to break their setups. As for coexistence when using the old ebuild, I would like to get some feedback on whether it's actually possible to use PipeWire 0.3.22 screencasting while running /usr/bin/pulseaudio and if that's out of the box or with modified PipeWire configuration.
Yes, this was possible. I came to pipewire due to testing screensharing feature in firefox and because of OpenRC I always had to launch pipewire manually while I had working sound via pulseaudio running in background.
Interesting, looking at source code and ebuild for 0.3.22, pipewire-media-session should be always built and started with pipewire daemon. How exactly can that co-exist with pulseaudio is unclear to me, since even without pipewire-pulse running, PipeWire still has the pw-jack (and, if it was enabled, then ALSA plugin, too), so it should be trying to take control of audio devices. Perhaps I'm missing something that would disable it's audio support by default?
(In reply to Thomas Deutschmann from comment #5) [...] > Your last comment sounds like there is a misunderstanding: You will still be > able to use pulseaudio -- just *through* pipewire. So in the end, nothing > should change for you. It's only important that pipewire daemon will replace > pulseaudio daemon. But I think that, if following ebuild instructions as they are (=> replacing the .service files and enabling pipewire-pulse.socket on systemd and equivalent in openrc), you end up running pipewire with its pulseaudio "compat layer"... but still pipewire with its possible regressions on third party apps... that they are getting fixed... but still there. I have reviewed docs in other distributions and it seems to be the case. As soon as you disable pulseaudio service and enable pipewire ones, you are really "migrating" completely to piperwire: https://wiki.debian.org/PipeWire#Using_as_a_substitute_for_PulseAudio.2FJACK.2FALSA https://wiki.archlinux.org/title/PipeWire#PulseAudio_clients But it's true that, from what I see from Fedora .spec file (that looks to be maintained by pipewire upstream), it seems that the important unit file to make the switch are the pipewire-pulse* ones. Then, to allow still to use pulseaudio for people suffering regressions, it seems the pathway could be to follow what they do for RHEL8: https://src.fedoraproject.org/rpms/pipewire/blob/rawhide/f/pipewire.spec#_305
All it does is delete the pipewire-pulse binary after it's built (not quite good to control via dedicated IUSE, I think) and the rest are actually config changes - those are not permitted to be toggled via dedicated IUSE. Also, I suspect that pipewire-pulse and associated user unit removal is a bit of an overkill as just removing the with-pulseaudio and with-jack (as well as with-audio & with-alsa should those exist inside /etc/pipewire/media-session.d/) should be enough to disable audio capabilities. The rest are there to ensure the user can't use pipewire-pulse no matter how. eselect pulse or eselect pipewire or similar would be okay, however. All that's needed is to just touch/rm the particular empty /etc/pipewire/media-session.d/with-{pulseaudio,jack} file.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e69ec3f4edb9233815a3de2a4a42b8e09a926110 commit e69ec3f4edb9233815a3de2a4a42b8e09a926110 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2021-05-08 14:53:55 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2021-05-08 18:27:45 +0000 media-video/pipewire: clearify postinst messages Closes: https://bugs.gentoo.org/786546 Package-Manager: Portage-3.0.18, Repoman-3.0.3 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> media-video/pipewire/pipewire-9999.ebuild | 56 ++++++++++++++++++------------- 1 file changed, 33 insertions(+), 23 deletions(-)
Thanks!
