[akira2501]

Consumer grade audio hardware has not gotten any more "nuanced" for several decades now. For the vast majority of use cases OSS was perfectly fine and it offered more than enough API to handle new features.

For the small minority of uses cases where you might have two sound cards and you may want to do some kind of sample accurate combined production between the two at very low latencies, sure, OSS was _somewhat_ inadequate.

So we ended up with a giant complicated audio stack where the boundaries between kernel space and user space are horribly blurred and create insane amounts of confusion and lost hours to benefit the 1% of users who might actually use those features.

It was a complete mistake.

[vetinari]

The OSS was inadequate the same day, when it was introduced; it couldn't even handle hardware available at the time (GUS, for example). It was really just mapping of the Soundblaster to a device file. For a single process, of course, all the others would have to wait, mute -- for mixing multiple inputs, you would need that dreaded daemon. Or GUS-like hardware, but with enough channels, so that yo won't run out of them. But then, mixing them in CPU is more effective, than pushing them all over external bus.

In a modern computer, you might have more sound cards than you are aware; the onboard sound codec, the outputs on your graphic card (that thing that pushes sound over DP/HDMI is a separate "sound card"), you might have some usb device (soundbars on monitors are usually usb sound devices), heck, even microphones from the last two decades have their own output. Webcam? Another sound device. Gamepad? That one too. And that's before anyone connects anything bluetooth. So it is not a small minority, in fact, it is the vast majority.

Audio stack boundary is in user space; period. It does stuff, that doesn't belong to kernel and is a perfect candidate for a daemon.

[akira2501]

> it couldn't even handle hardware available at the time

I would not call the GUS "consumer hardware." It was also the cast that most games offered support for it, but most companies did not put significant effort into it, and the support was either broken or buggy.

> For a single process, of course

ALSA is no different. dmix is purely in userspace. Which is why it has IPC keys that you can configure, and have to configure under certain circumstances.

> you would need that dreaded daemon.

You could use any of a number of different daemons depending on your particular use case and you weren't required to make one of them work or keep it compatible with your kernel driver versions. The OSS audio API was completely stable. The ALSA audio API eventually was.

> So it is not a small minority, in fact, it is the vast majority.

The import of my comparison is that the problem with OSS is attempting to use these cards /simultaneously/ in a "sample accurate and low latency way." OSS could, of course, handle multiple different cards and devices (easy as/dev/dsp0 vs /dev/dsp1). It did not offer any way to time them with a common reference, which made them inadequate for certain types of _professional recording_ scenarios.

You have not, so far, described anything OSS could not do.

> Audio stack boundary is in user space; period.

Yea, except the timing, which is the effectively the only benefit ALSA brings over OSS. Which, by the way, is a feature that is not at all in user space.

> that doesn't belong to kernel and is a perfect candidate for a daemon.

The one you dread?