Created attachment 250151 [details] patch Nowadays it is a common expectation that when a new audio device is connected, like headset, the audio IO is switched to go through this new device. This is typically done in desktop environments using PulseAudio - audio is routed to the new device automatically, in a centralized fashion. This is how it works in Firefox, but it currently doesn't work in Chromium. I am suggesting to make PulseAudio default, since most users run Chromium in desktop environments and users would benefit from it behaving nicely.
Why not pipeware?
(In reply to Vladimir Druzenko from comment #1) Because most/all desktop environments use PUlseAudio by default, unless I am mistaken.
1. I'm using FreeBSD as single OS on desktop from 2009 at home and at work and never used pulseaudio or pipewire. 2. AFAIK pulseaudio is deprecated by upstream and superseded with pipewire. For example Ubuntu 24.04 is with pipewire by default instead of pulseaudio.
(In reply to Vladimir Druzenko from comment #3) I also use FreeBSD as a sole desktop OS since late 1990s. But today XFCE4 seems to use PulseAudio by default. Also: the chromium port doesn't currently support the PipeWire audio backend. I am not sure if chromium itself does.
The firefox port also doesn't have the pipewire support. I suggest that the attached patch should be committed in the mean time. Then the following items should be fixed: 1. Support PipeWire in www/chromium 2. Support PipeWire in www/fireefox 3. Support PipeWire in mail/thunderbird 4. Support PipeWire in all desktop environments: KDE5, Gnome, XFCE5, with published instructions on how to easily enable it. Once PipeWire is supported everywhere, change the default to PIPEWIRE in browsers, mail clients, etc. It would likely take months to support PipeWire everywhere.
1. Check your patch - option PIPEWIRE is in OPTIONS_DEFAULT. 2 and 3. Fifefox and Thunderbird have patches (in ports) with pipewire support. 4. KDE support pipewire on FreeBSD for more than year - I wrote patches for disable it(!). I don't use other DEs. P.S. I'm using FreeBSD for servers and as 2nd OS on desktop from late 1990s too, but full migration on desktop was finished in 2009 only.
(In reply to Vladimir Druzenko from comment #6) > Check your patch - option PIPEWIRE is in OPTIONS_DEFAULT. But the option's description says that it is for screen capture, not sound. > KDE support pipewire on FreeBSD for more than year [...] KDE crashes when the file system has too many files because it keeps every file in the system open, as amazing as it might sound.
Duplicate of bug 246449?
*** Bug 246449 has been marked as a duplicate of this bug. ***
Committed.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=89e432ced730385869e5bf6df4b705facbd1c947 commit 89e432ced730385869e5bf6df4b705facbd1c947 Author: Yuri Victorovich <yuri@FreeBSD.org> AuthorDate: 2024-05-04 02:02:20 +0000 Commit: Yuri Victorovich <yuri@FreeBSD.org> CommitDate: 2024-05-04 02:06:57 +0000 www/chromium: Change default audio output to PULSEAUDIO to make chromium to play nice with desktop environments PR: 278521 246449 Approved by: chromium@FreeBSD.org (maintainer's timeout; 4 years on bug#246449) www/chromium/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Please revert this.
(In reply to Oleh Hushchenkov from comment #12) Any reason?
(In reply to Yuri Victorovich from comment #13) It adds extra huge dependency to minimalistic setups without DE. Messing with default options is a wrong way from very beginning. As a commiter, you can create slave ports with different audio backends. Like: www/chromium-pulse www/chromium-sndio www/chromium-alsa I would be grateful for ALSA enabled build.
(In reply to Oleh Hushchenkov from comment #14) I am curious, why would you need chromium-alsa? It is certainly possible to flavorize browsers on audio backend, instead of creating slave ports. (I don't think that slave ports are a good solution here.) I will ask on the ML whether someone would object to this. One potential problem would be that www/chromium builds for a very long time, like 24 hours, and having many of them would exacerbate this situation.
(In reply to Yuri Victorovich from comment #15) > I am curious, why would you need chromium-alsa? Skype and Teams work better with ALSA backend. I used to build chromium from sources to enable ALSA, but it takes too long on my computer now. > One potential problem would be that www/chromium builds for a very long time, like 24 hours, and having many of them would exacerbate this situation. Building chromium from sources is much bigger problem for people without modern 16-core CPU. The reason to have binary packages with different audio backends is to help users who prefers non default one. Custom build is not a problem for smaller apps, but chromium is simply too huge for most of users to build it from sources. Thank you.
(In reply to Oleh Hushchenkov from comment #16) Instead of reverting this change, I will create another PR with the flavorization suggestion, for www/chromium and www/firefox.
(In reply to Yuri Victorovich from comment #17) Discussion about the flavorization can take years.
(In reply to Oleh Hushchenkov from comment #18) With a patch - 14 days in case that maintainer wouldn't respond.