FF 32-bit support's probably going to be like it's (direct) ALSA support, community driven

Simply that the sound plays without any distortion or skipping whenever I'm watching a video while running something heavy on the machine. With pulseaudio I never set out to remove it from the start, only as a reaction to it messing up the sound, this would happen within a day or two after I set up a new machine. Pipewire has improved things a lot, it took three or four months before I noticed skipping and uninstalled it.

Indeed. Additionally, for me, tho this doesn't apply to most Linux users, at least to the extent they apply here, particularly since most install from distro (or flatpack/snap) binary packages.

As already mentioned I'm a Gentooer. While they do have prebuilt binaries available these days, as I suspect most gentooers I prefer my own customized builds.

But one thing a gentooer building and importantly _upgrading_ packages themselves *quickly* learns is that having unused packages installed isn't just bad security practice, when you're building the upgrades, it's *expensive* in time and compute resources. There's a very high incentive to just uninstall those things you don't /really/ need, or even the ones you might need occasionally, but find yourself upgrading more often than you actually run them. And more to the point, that goes for the build options (gentoo USE flags) that control optional features on your leaf packages but pull in additional dependencies to supply those features, as well.

Put simply, having a package installed really is a different expense proposition when you're building /and/ /building/ /upgrades/ yourself, than if you're simply installing prebuilt binaries.

But that's the general case I could have replied to directly above. Here there's more specific points:

> Because pipewire makes things like screen sharing work reliably

It's not just screen sharing. In fact, here screen sharing would be a net-negative as the only conceivable screensharing would be malware so better not to have it available to be abused.

But the same mechanism is used (on wayland, X of course lets any app have at it) for screenshotting and at least on plasma, for plasmashell taskmanager plasmoid thumbnailing. For the latter, fortunately kwin's taskswitcher plugins aren't affected since kwin's the plasma wayland compositor, and with a near 25 MegaPx desktop (3 by 4k bigscreen TVs as computer monitors) and multiple desktops, window-stacking is often avoided, so focus-follows-mouse and the keyboard-triggered kwin task-switchers are enough and I don't need nor have configured any plasmashell taskbars or the like. Screenshotting would be more useful, particularly for filing kde related bugs since I track live-git (via the gentoo/kde project overlay packages available for that purpose) for most of my kde stuff, but spectacle, plasma's screenshotter, requires pipewire.

But it's not worth it just for that. I can word-describe the problem in bugs I file, and if they aren't immediately fixed (as bugs against live-git often are), someone else generally eventually comes along and provides screenshots where I can't due to missing pipewire.

> because with an audio server running *not* talking to the audio server means going through an extra layer, because using pipewire makes it easier to control where different audio goes (or comes from)...

But no audio server here to talk to, so it's not running and talking to alsa directly isn't an extra layer for the gentoo distro firefox. For firefox-bin, the gentoo-packaged mozilla-built binary (or for the mozilla-packaged user-installed binary), there's the apulse shim library as an extra layer talking to the prebuilt binary via the pulse/pipewire api, but that's still thinner than the non-shim full version of either would be.

And with only a single active audio device to talk to, there's no /need/ for pulse/pipewire device-routing.

Multi-stream audio merging, assuming your hardware can't handle it (my current hardware doesn't but my old hardware did), can still be useful, but alsa can software-merge streams via dmix of properly configured. I've had mixed results trying to get it working (it seems to work sometimes but not reliably), probably because the configuration and documentation for it is a bit arcane and I'm still doing something not quite right, but in theory it's available from alsa.

Turns out, however, that most of the time I actually prefer my primary audio stream uninterrupted. This actually kind of surprised me when I switched to less capable hardware that didn't handle that itself, but I found most of the time I prefer /not/ having sound effects and even second "feature" streams interfering with my enjoyment of whatever I'm already playing!

So it turns out that's not something I'd want to install pulse/pipewire for either, both because alsa can at least theoretically handle it if properly configured, and because it turns out I don't actually want multiple streams most of the time anyway.

Now one thing I /did/ find worth digging into the alsa documentation and text-editing the alsa config for, was the alsaequal 10-band equalizer. I believe a pulse-based equalizer is significantly closer to plug-and-play, but after setting up a bunch of presets and a script to activate them, plus adding another menu to my existing custom hotkey-activated menu setup so activating a new eq preset is a two-key sequence (using an "extra" key on my logitech keyboard as the first one), I'm quite happy indeed with how that turned out. =:^) (Tho FWIW I did run a firefox eq extension before that, primarily for youtube.)

All that said, reports suggest pipewire's a more stable solution than pulse was, and definitely, pipewire's window snapshotting and thumbnailing functionality make it more practically useful than the audio-only pulse, so I'll probably switch to it "someday", maybe when/if I ever get that threadripper hardware upgrade I want and will be rebuilding for the new hardware anyway... But that could be a few years...