Except that you still need kernel-side ALSA for the more modern solutions to work, as they're built on top of ALSA, which is where the audio hardware drivers are.

I think he understands that. However it seems to me that ALSA is a bit of an umbrella term for a bunch of stuff like systemd is. It's divided between kernel and userspace. And Pipewire does in fact replace much of the userspace stuff rather than simply running on top of ALSA like is sometimes implied.

I usually do not play audio from my Web browser (Firefox), but I did a quick try using a random podcast and it works without any tweak.

If you have FF playing audio while another app is also playing audio then something about your setup is different from mine. For me FF would not share audio using ALSA.

I just tried playing a random podcast from this page (in Firefox), while I have a MPD instance playing music in the background. Both sound streams are audible at the same time.

I am using Firefox ESR straight from Debian repositories, but I think it worked in the same way when I used the non-ESR build instead.

I can find no tweaked option in Firefox about:config when I filter on "audio" or "sound".

Hmm. Well it did not work for me. I can't help but wonder if you have pulseaudio or some emulation of it running.
https://www.omgubuntu.co.uk/2017/03/firefox-52-no-sound-pulseaudio-alsa-linux

But in any case everything works for me with a sound server but it's hit & miss without one.

I don’t ;) I guess your Firefox build has poor support for ALSA, maybe it was built without the --enable-alsa switch? Debian added this one 4~5 years ago, to fix several issues related to upstream changes:
- no sound after upgrading from 52.9 to 60.2
- no sound: failed to init cubeb
- does not work with ALSA but blind many users use ALSA

OK. It's interesting that FF seems to take exclusive access when using ALSA for me but not you. But it's of no matter since I think I prefer having pipewire running anyway.

Not that you care, but that's probably because mpd was running before ff. Similarly, I have timidity start at bootup to provide a virtual MIDI device, which also forces other apps to stop trying to be "smart" and pick an exclusive hardware device over the default (shared) device. Unless of course they insist, as some apps do, in which case they just fail.

One rather ridiculous example is the Linux version of Divinity: Original Sin EE. It uses separate sound initialization for regular in-game sounds and cut scenes (including the opening logo). Since it uses this "hardware first, default as fallback" technique, even if you give the game exclusive access to sound, it ends up locking itself out giving no sound on movies. Well, assuming you don't have a sound card that has hardware support for multiple sources, but most recent computers come with "Intel HD Sound" compatible devices, which apparently don't.

I'm not saying ALSA is the greatest, I'm saying that if you wanted to fix things, it's actually possible to improve libALSA rather than reinventing the wheel. When ALSA was first introduced, I switched as soon as possible, because they made technical promises that appealed to me (even if, after all this time, they have yet to deliver on some of them). If the only technical argument you can offer is "it works more easily for me" or "it's the future, deal with it", I am not convinced. You know what would work more easily for everyone? Running an OS that is actually supported by end-user software, like Windows. And if all you're interested in is games, a console would be even better, since there is no hardware deviation.

I don't know. It's not like there are not multiple APIs for audio on Windows, there are. My app will allow the user to choose if it should use the ALSA or PipeWire api for the audio backend. I think that's reasonable.

Ultimately the goal is to accomplish the task of playing sound in your apps on your hardware. If PipeWire gets that done for you I don't see that as bad. If you tried to modify ALSA such that it could do all PipeWire does you would cause incompatibilities which could make the audio landscape worse rather than better.

PipeWire is making improvements without disrupting anything. And maybe one day ALSA can be removed and PipeWire can be standalone while still supporting apps that had been written for older APIs.

.....

I have been doing some research on Debian and even Debian not only recommends something beyond ALSA, but they also state Firefox won't work.

vv221 - I think you must have something installed beyond just ALSA for this config to work:

https://wiki.debian.org/ALSA

Edit: Note your setup has my curiosity peaked.

Of course, one has to keep in mind that Debian is not the land of bleeding or even stable edge.

For some incredulous reasion, Debian chooses staleness as a packaging philosophy, which means anything Debian based gets double, or Hades help you, triple staleness. I call it the table scraps methodology. Debian is the table scraps of software packaging, Ubuntu is the leftovers of packaging methodology; putting away anything that nobody could bother with, and Mint is the freezerburned crumbs of the remains.

I say this because Debian already isn't getting fresh packages, Ubuntu is based on the LTS of an already stale codebase, and Mint is based on the twice stale codebase of Ubuntu; which inexplicably itself then has further Long Term Service.

Meaning that you can and often will be 1.5 to 3+ years removed from the latest packages.

And it's no wonder people think that PipeWire and Wayland are still, "Experimental", in spite of years of use.

Yes. That's actually the idea in the stuff I'm writing at the moment.
I need total control so there are no timing surprises, which might occur with e.g. "plughw....".
My code mostly runs on Raspberry Pies and occasionally on my Linux workstation.
I use both the Pies and the workstation as headless devices, SSH'ing into them from my Windows laptop and desktop, so there are no other processes accessing the audio devices.

{rant}
Linux is my preferred environment and I ran it exclusively on my home equipment for 20+ years, and at work I develop for Linux devices.
But the increasing dominance of Gnome and its influence on Wayland has left me feeling less attached to the whole "Linux on the desktop", so now I make like a lemming and just use Windows on the PCs my keyboard and monitor are attached to. (Apart from the Chromebook I got for a lark when I spotted one on sale a week ago.)
{/rant}

Worth noting that you can use Linux on the desktop without GNOME. There's KDE, for example, which can run under either X11 or Wayland.

Debian testing/unstable isn't so outdated. When there's no freeze, you get very up to date packages, occasionally even before the official release. It's only during freezes that it slows down, and the freeze doesn't last as long as 1.5 years.

As for debian stable, the saying goes "if it ain't broke, don't fix it". Debian stable works, and more importantly, it remains working and will not suddenly break your workflow. There are, indeed, some people who don't like to update their software because doing so may break things, or because they don't want to be forced to learn new ways of doing things; those are the people for which Debian stable is intended.