Created attachment 264762 [details] [PATCH] multimedia/pipewire: update to 1.4.9 Patch attached, all tests pass.
Thank you, LGTM.
Created attachment 264941 [details] [PATCH v2] multimedia/pipewire: update to 1.4.9 Sorry for the churn, but would you be able to look at the small addition I've made to v2? Based on the feedback from my proposed upstream patch https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2574, I don't think they are willing to provide .desktop autostart files themselves. This is required so that desktop environments such as KDE can automatically start pipewire and pipewire-pulse as needed without user configuration. If a user wishes to run something else, they can easily override it with a "Hidden=true" .desktop entry in their own ~/.config/autostart directory.
No, we shouldn't autostart pipewire too yet. With how things are currently arranged, it is going to conflict with pulseaudio, which is also autostarted via its own mechanism. The status quo currently is that we're defaulting to pulseaudio, so properly setting up pipewire should be a user's job. I agree this is suboptimal, but it requires some work before pulling the final trigger. So please remove the autostarting bits for now until it is ready to fully replace pulseaudio.
Ok, in that case, I will investigate what needs to be done to start defaulting to Pipewire. As I understand it, it is mandatory on wayland to support screensharing with xdg-desktop-portal, so I would eventually like to help push things forward to use pipewire+pipewire-pulse as the default. For now, you can use the previous v1 patch from this bug.
Regarding your comments on https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2574, I see a way forward. I was thinking of adding a FLAVOR=libpulse to audio/pulseaudio which does not include bin/pulseaudio or any other binaries. This would ensure that applications have access to libpulse.so for pulseaudio calls (that should reach pipewire-pulse when running), but not start the server itself. What do you think? Additionally, on my testing laptop running KDE, the system seems to be running just fine when I run pipewire + pipewire-pulse at "X-KDE-autostart-phase=1", and install a "Hidden=true" pulseaudio entry in my ~/.config/autostart. I see that /usr/local/bin/pulseaudio IS running alongside pipewire and pipewire-pulse, but my audio seems to be working just fine. What is blocking us from simply removing the autostart entry from audio/pulseaudio's pkg-plist, and then adding autostart entries for pipewire+pipewire-pulse? Is there a runtime test that can be done to show any issues from the conflict of applications starting up /usr/local/bin/pulseaudio on their own?
(In reply to Siva Mahadevan from comment #5) > Regarding your comments on https://gitlab.freedesktop.org/pipewire/pipewire/-/merge_requests/2574, I see a way forward. I was thinking of adding a FLAVOR=libpulse to audio/pulseaudio which does not include bin/pulseaudio or any other binaries. This would ensure that applications have access to libpulse.so for pulseaudio calls (that should reach pipewire-pulse when running), but not start the server itself. This isn't even needed, I believe. When libpulse successfully connects to pipewire-pulse it wouldn't (shouldn't) try to run a real pulseaudio server. > I see that /usr/local/bin/pulseaudio IS running alongside pipewire and pipewire-pulse, but my audio seems to be working just fine. This looks strange to me and requires a research. Something's clearly not working and shouldn't even be started, either pulseaudio or pipewire-pulse. > What is blocking us from simply removing the autostart entry from audio/pulseaudio's pkg-plist, and then adding autostart entries for pipewire+pipewire-pulse? Mainly, a research on how all these things intended to work. Then some collaboration with upstreams might be required to work out a path for non-systemd users. Next, there should be a decision to switch, because I imagine a lot of people would be irritated by the change, much like if we decide to default to Wayland instead of X11. Ideally, I'd want a ports-level mechanism allowing user to choose what he wants to use. Finally, PipeWire nees an OSS sink, as mentioned in this comment: https://forums.FreeBSD.org/threads/pipewire-pipewire-pulse-as-main-audio-server.95257/post-675075 We now have pipewire-spa-oss, but it is remain unclear to me how well it works in practice.
(In reply to Gleb Popov from comment #6) > This isn't even needed, I believe. When libpulse successfully connects to pipewire-pulse it wouldn't (shouldn't) try to run a real pulseaudio server. I agree, so I think maybe we don't need to explore that path. I do see the binary being started, but killing it (while pipewire and pipewire-pulse are running) does not affect audio playback or the system in anyway. Everything continues to work as normal. > Then some collaboration with upstreams might be required to work out a path for non-systemd users. I think upstream has always asserted that non-systemd distros package their own way of starting pipewire (and its dependencies) correctly: * Alpine Linux has its OpenRC User services as mentioned here: https://wiki.alpinelinux.org/wiki/PipeWire#Launch_Pipewire * Gentoo maintains their own script here: https://wiki.gentoo.org/wiki/PipeWire#gentoo-pipewire-launcher * FreeBSD has an up-to-date wiki article suggesting to just start them in succession manually (which I have successfully used before the cleaner XDG autostart method): https://wiki.freebsd.org/DanielPerez/WaylandScreenShare#Pipewire > Next, there should be a decision to switch, because I imagine a lot of people would be irritated by the change, much like if we decide to default to Wayland instead of X11. I agree with this, it should be an explicit decision. I will file a new tracking bug for the matter, since I do see that the community considers Pipewire to be a very effective pulseaudio replacement and successor. FreeBSD is already committing to offer KDE+Wayland installer support in the near future as is clear here: https://github.com/FreeBSDFoundation/proj-laptop/blob/main/supported/desktop-environment.md and here: https://gitlab.com/alfix/kde-installer-dialogs. Thus, it would be good to eventually move to Pipewire by default to allow for screensharing out-of-the-box on well supported configurations. > Ideally, I'd want a ports-level mechanism allowing user to choose what he wants to use. Maybe something like SOUNDSERVER_DEFAULT={pipewire,pulseaudio,none} in Mk/bsd.default-versions.mk (https://cgit.freebsd.org/ports/tree/Mk/bsd.default-versions.mk)? Similar to how NINJA_DEFAULT is handled for example. libpulse.so will still be a dependency for most ports, but maybe the ${PREFIX}/etc/xdg/autostart directory will contain pipewire vs pulseaudio vs nothing? > We now have pipewire-spa-oss, but it is remain unclear to me how well it works in practice. I have been personally using it for many months and I see no issues at all, maybe others can attest to that.
(In reply to Siva Mahadevan from comment #7) > I agree, so I think maybe we don't need to explore that path. I do see the binary being started, but killing it (while pipewire and pipewire-pulse are running) does not affect audio playback or the system in anyway. Everything continues to work as normal. I still believe this requires researching and proper fixing. Even if running pulseaudio does no harm right now, it still might have unforeseen consequences. > I think upstream has always asserted that non-systemd distros package their own way of starting pipewire (and its dependencies) correctly: These are important data points, thanks. It makes me think that the intended way to start this stuff is the "user services" concept, which is currently missing in FreeBSD (or rather in ConsoleKit). Right now I'm in a slow process of rewriting logind in a crossplatform manner, which should solve many compatibility issues and also give us these "user services" as well. This looks like a proper way to fix, but it will take a lot of time to get ready as I'm working on it in my free time. > Maybe something like SOUNDSERVER_DEFAULT={pipewire,pulseaudio,none} in Mk/bsd.default-versions.mk (https://cgit.freebsd.org/ports/tree/Mk/bsd.default-versions.mk)? Techincal implementation isn't really a problem, the hardest part, I think, would be getting portmgr approval.
(In reply to Gleb Popov from comment #8) > I still believe this requires researching and proper fixing. Even if running pulseaudio does no harm right now, it still might have unforeseen consequences. Yes agreed. I'm not suggesting we go ahead and upgrade just yet, but just wanted to provide my anecdotal evidence from testing this scenario on my system. > It makes me think that the intended way to start this stuff is the "user services" concept, which is currently missing in FreeBSD What about writing an RC service for pipewire with "pipewire_user" and "pipewire_group" rc variables? Then we can "REQUIRE: dbus" and ensure that it starts up after dbus and has everything connected correctly. I have been using other rc scripts like "user services" in this manner with services such as syncthing. Not sure if this is the correct way to do this though. > Right now I'm in a slow process of rewriting logind in a crossplatform manner, That sounds great, thanks for your work!. This does look like the correct solution going forward though. In the meantime, lets go ahead with merging v1 of the 1.4.9 update patch attached in this bug (without any autostart desktop entry changes).
(In reply to Siva Mahadevan from comment #9) > What about writing an RC service for pipewire with "pipewire_user" and "pipewire_group" rc variables? The distinctive property of a "user service" compared to a regular one is that the service gets started whenever a user logs in. The solution you propose may work, but it is quite hacky - it requires manual configuration, the script would run before the user actually logs in, user's $HOME may not be available yet, the script would not inherit user's environment, etc. > In the meantime, lets go ahead with merging v1 of the 1.4.9 update patch attached in this bug (without any autostart desktop entry changes). You don't have a commit bit, if I understand correctly?
(In reply to Gleb Popov from comment #10) > The distinctive property of a "user service" compared to a regular one is that the service gets started whenever a user logs in. Yes got it, that is definitely the correct solution going forward. > You don't have a commit bit, if I understand correctly? That's right, I do need your help on this one :) Don't have a commit bit (at least not yet!).
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4aaec2259d097061f1a3082c32866a4f5bdc901f commit 4aaec2259d097061f1a3082c32866a4f5bdc901f Author: Siva Mahadevan <me@svmhdvn.name> AuthorDate: 2025-10-21 14:39:43 +0000 Commit: Gleb Popov <arrowd@FreeBSD.org> CommitDate: 2025-11-04 09:43:05 +0000 multimedia/pipewire: update to 1.4.9 PR: 290403 Co-authored-by: Gleb Popov <arrowd@FreeBSD.org> multimedia/pipewire/Makefile | 8 +++++--- multimedia/pipewire/distinfo | 6 +++--- multimedia/pipewire/pkg-plist | 9 +++++---- 3 files changed, 13 insertions(+), 10 deletions(-)
Merged, thanks.