Raw ALSA can only have one program playing sound unless your hardware has support for hardware mixing (this would generally mean it's very old and also very expensive). More likely you are/were using ALSA's dmix plugin which is a small barebones version of the core functionality of pulseaudio or pipewire. They replace dmix but also give you things like per-program volume control, better latency, better power usage, better mixing, bluetooth support, the ability to do fancy things with audio routing without restarting every program playing audio, etc.

I am not sure about "better latency". The latency with Pulseaudio cannot be controlled via GUI and is often quite large (on order of hundred ms or more). In my opinion, to get minimum latency one needs to access audio card directly, without intermediate daemons.

PulseAudio optimizes for power consumption but tries to be adaptive to handle lower latency as well. PipeWire seems to optimize for latency but try to be adaptive to reduce power consumption as well. These are conflicting desires, lower latency requires higher power usage because you have to use shorter buffers instead of just giving the sound card a big chunk of audio to work through and putting the CPU to sleep. JACK could potentially still do better and ALSA could potentially still do better than even that but PipeWire's goal is to be close enough or even match JACK while still having all the other features people use PulseAudio for.

PA isn't great when it comes to latency, but JACK and PW are.

I'm not really sure what the difference between "ALSA just works" and "ALSA as configured by my distribution and including the DMIX plugin just works" is.

Like at the end of the day option 2 is still "ALSA just works".

Because the complexity of audio is hard. If you just have a desktop system with stereo speakers it is easy. However if you ever plug a set of headphones in things get hard. Should all sound now go through the headphones or not? Different people will want different answers (I have headphones plugged in all the time, but I'm not wearing them all the time, so if someone sends me an IM I need the beep to come out the regular speakers). There are monitors that have built in speakers making this harder, does the user have better speakers plugged into the computer output or not?

That is the regular desktop user. If you do any for of audio processing (pod casting, music recording) you may have a large number of different inputs and output connected, and want to do mixing of some sort. Likewise if you do videos you may have more than one "webcam" that you want to mix. These are fairly common use cases (many people have a dream of being a musician or an actor, and so have this type of setup that they are trying to use in the efforts to make it big)

> Should all sound now go through the headphones or not?

The correct answer to that specific question: as a sane default, all sound should now go through the headphones. That's a sane default on the Iphone, probably on Macbooks, and it also happens to be the one that at least a stock Gnome or Ubuntu desktop chooses. In fact I have trouble thinking of a saner default than that one!

Forgetting about sane defaults seems to be a common problem in FOSS communication. It's unfortunate, because describing something as unknowable can convince a new developer to avoid inspecting the code around that particular problem.

E.g., it took a long time for Gnome to get the sane default I describe above. I'd bet that lurking in the appropriate mailing list history is at least one didactic post from an audio developer explaining how we can never truly know what a user's preferred setup could be.

Because they do things many users find useful:

-Per-application volume control

-Seamless hardware switching mid-stream (plug in headphones)

-Different channel configurations into the same device simultaneously

-Cross-application volume ducking

Because ALSA doesn't allow two programs to use the same audio card simultaneously. ALSA is good for exclusive access, when you want to remove everything between an application and audio card.

Also ALSA cannot do other nice things, like switching audio output when you plug an USB audio card.

It can and does as it was configured by most distributions.

The dmix plugin does, not ALSA.

pulseaudio exists because it's user friendly.

JACK exists becase some people need low latency and dynamic control over non-trivial audio routing.

pipewire attempts to bring the best of both worlds and make it container friendly for security purposes.

> JACK exists becase some people need low latency

Wouldn't latency be lower if the application would access audio card directly without any daemons in between?

Then you would only be able to do fraction of functionality JACK provides you. May be enough for the most simple use-cases, but people who reach for JACK aren't usually after those.

The answer is, surpisingly maybe, no. JACK (and PipeWire) manage to add features without adding any latency to what ALSA can provide. Will it consume more CPU? yes, it does...

Most of the things people below say ALSA didn't have, OSSv4 actually had. But basically, they made it proprietary, Linux switched to ALSA, and when OSSv4 became open source again it lost traction. But from my experience at the time, it had none of the problems ALSA had, it had none of the problems pulseaudio had, and it had none of the problems ESD had.

This is a clear case of when ideology won over an objectively better product to the detriment of all users for more than a decade.

Ehhhh OSS is really not great, even v4. Re-using Unix file I/O functions for audio sounds clever, but falls apart pretty quickly in the real world. Even in the best case where you manage to shove every audio feature into open, read, write, and ioctl, it's never going to feel good to use (type safety...).

I don't mourn the loss of OSS.

OSS relies on mixing in the kernel, which is bad for reasons explained here: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ...

Also with OSS you still can't seamlessly switch between devices, bluetooth or arbitrary signal routing between apps. So, no... good riddance.

Firefox can't do sound with raw ALSA. No, I know that doesn't explain why PulseAudio exists. But I think Pipewire can do more - isn't it supposed to be able to move video around as well as audio? Or something.

I also just use raw ALSA. It's there anyway, it works, and I don't need more daemons (I don't need NetworkManager either).