Pulseaudio does network audio right and I have been using it for that purpose since it first existed. So from my prospective the mistake was adding in all the other junk.

The root cause of all the complexity is (was?) the lack of standardization for hardware interfaces. The lack of some globally usable way of dealing with latency at the OS level is another issue. A thing like Pulseaudio is a natural reaction to the current situation in that it tries to both hide the complexity of the hardware interfaces and deals with the latency issue entirely in one program.

So the problem isn't Pulseaudio. The problem is the environment that media is forced to exist in.

If you end up with a giant ball of hidden complexity, that's a strong indication that you're dealing with that complexity at the wrong level.

Both PulseAudio and systemd seem to have the "throw everything out, start from a beautiful abstract interface and work down" mentality, which is a recipe for the mess that they've ended up as. Sometimes the best thing to do is pass the ugly complexity one layer up - which is, I think, one of the things that Unix does mostly right.

PulseAudio supports network streaming, but it's certainly not the main selling point. Important features are:

* Mixing several streams in software, if there's no hardware support (th e FreeBSD sound driver does that as well)

* Dynamic switching between several audio interfaces without stopping the stream, e.g. switching to a Bluetooth headset during a phone call

* Reducing power usage by supporting different latencies for each client application, and then running the hardware with the lowest currently requested latency

Supposedly network transparency came later.

Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call).

Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage.

Also, i don't think Alsa had dmix (user-space software mixing) at that point in time.

As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.

Yes, doing the mixing in kernel space is nice: it's obvious, simple, reliable, monolithic. Unfortunately the Linux developers don't want to go that way, because they think mixing is a problem for user-space.