It might (just barely) be an accurate description of (some) of the issues, but it is absolutely not "so true".
OSS is not a de-facto standard, and has many issues that led to us moving on from it back in the late 1990s.
It might offer you precisely what you want, but it does not solve all the problems, and in addition is still absolutely the wrong API to offer for application development. Hint: you don't use open/read/write/close to do video, and for some similar reasons and some different ones, it's the wrong model for audio too.
I've been doing audio development on Linux (and macOS and tangentially Windows) for more than 20 years. I wrote device drivers for pro-audio interfaces, application frameworks (JACK) and large applications (Ardour); I used to have to spend the closing part of the aughts and early part of the 2010's explaining to seriously misinformed people what all the problems with OSS were. That doesn't mean that there have not been issues with audio on Linux, but OSS (4 or otherwise) is not the answer to those problems and never was.
Why do you think ALSA was developed? Do you imagine that it was just a temporary whim of a developer somewhere "oh, I think I'll write a new driver stack for audio on linux"?
The issues are too many (and too old) for me to list them all, but the biggest of all was that OSS tries to do everything inside the kernel, which is (a) inefficient (b) prevents the use of floating point (the preferred sample format for mixing) (c) makes inserting processing elements within audio streams much more complex (and likely to be rejected because of Linus' practice of mechanism not policy). Even macOS, which originally implemented its audio mix engine in the kernel, gave up on this idea, and moved it into user space (coreaudiod).
OSS's API also made dealing with pro-audio interfaces quite difficult, because of channel layout. I can't recall if OSS4 fixed this, but OSS also did not offer mmap. When it comes to device control, you really not want to export thousands of OSS_IOCTL_FOOBAR constants to describe every control on every device, so ALSA made an attempt to create a parallel control API (parallel to the I/O API). This has been partially successful, but not entirely (note that on other platforms, there is frequently a dedicated device control app; more recently a few h/w makers have shifted to provide a web interface for device control)
>"oh, I think I'll write a new driver stack for audio on linux"
Linux is kind of famous for this approach. From what I've seen most problems with OSS were either problems with Linux implementation, and could be fixed without inventing a new proprietary API, or problems of OSS being too low-level, and thus could be fixed by providing a higher-level API on top of OSS (which userspace part of ALSA kind of is, but my question was about the kernel API). From what I can tell pretty much every single one you've mentioned above fits into those two categories - except device control, but I honestly have no idea what it is; can you give some real-life example?
> except device control, but I honestly have no idea what it is; can you give some real-life example?
You want to adjust the gain level used for capture. Or hardware gain control for playback. Or which input stream will be captured. Etc. etc.
By your apparent definition above, the kernel API doesn't matter, it is inward facing, and really just affects device drivers. Nobody cares, because within a couple of months ALSA had all the drivers OSS had, and then rapidly gained many more (partly it was much better structured for writing drivers than OSS was).
Even without an application framework like JACK though, it matters what the API presented to user space is, and ALSA made the deliberate choice to essentially completely hide the actual kernel interface and wrap it in libalsa. This allows for interposition (without using LD_PRELOAD) and very flexible configuration, all occuring in user space. Fun fact: "reading" audio data with ALSA is actually done with an ioctl() call!
Okay, gain. Also maybe bit width, and number of channels, and sampling rate, and maybe five other things. It's not "thousands"; there is a limited number of things one can adjust in DACs and ADCs.
>By your apparent definition above, the kernel API doesn't matter
Replacing a standard, portable API with a proprietary one doesn't matter to Linux - but it makes life harder for everyone else.
On an RME9652, there are 3136 gain controls on that single device alone.
On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
> Replacing a standard, portable API with a proprietary one doesn't matter to Linux
>On an RME9652, there are 3136 gain controls on that single device alone.
Not that I don't believe you, but quick googling shows this card doesn't have analog, so... what do those gain controls do?
>On most Intel HDA-compatible chipsets (i.e. the builtin audio for just about every off-the-shelf motherboard in existence these days), there are between a dozen and 500 controls.
Again, what for? I don't remember Windows or OSX showing 500 controls for internal sound card. More like five - two gains, two input/output dropdowns, left/right.
>I have no idea what this is supposed to mean.
OSS wasn't perfect, but was portable. ALSA is proprietary. Forcing it is no different from other vendors forcing their proprietary replacements for open solutions.
The device has a matrix mixer, so there's a gain level for (at least) every input to every output. More than that, however.
Yes, Windows and macOS won't show you those controls, and neither will Linux (for the most part). However, ALSA provides a standardized API to access them, and utilities like alsactl and amix can be used to set them in a device independent way.
You seem to be using the word "proprietary" in a very different way than most people in this world and on HN use it. ALSA in GPL'ed, part of the Linux kernel, and part of most typical Linux run-time environments, and has been worked on by hundreds of individuals. OSS4 was developed by 4Front Technologies, and they made money by developing non-GPL, non-open-source device drivers under contract. There are no such drivers within ALSA, and there have even been some attempts to port ALSA to other posix-y OS's, generally but not entirely limited to the user-space component.
OSS was not portable to anything except a few other Unix-y systems that also used OSS. That did not include Solaris or macOS/OSX, and at the time OSS was developed for Linux, it was not available for any of the *BSD systems (that came later). The only sense in which it was "portable" was that it provided /dev/dsp as did several other Unix-y systems, which is useful for doing party tricks on the command line, but very little else. ALSA still (or used to) provide that too, for back-compatibility with a tiny number of toy applications that used it.
OSS is not a de-facto standard, and has many issues that led to us moving on from it back in the late 1990s.
It might offer you precisely what you want, but it does not solve all the problems, and in addition is still absolutely the wrong API to offer for application development. Hint: you don't use open/read/write/close to do video, and for some similar reasons and some different ones, it's the wrong model for audio too.
I've been doing audio development on Linux (and macOS and tangentially Windows) for more than 20 years. I wrote device drivers for pro-audio interfaces, application frameworks (JACK) and large applications (Ardour); I used to have to spend the closing part of the aughts and early part of the 2010's explaining to seriously misinformed people what all the problems with OSS were. That doesn't mean that there have not been issues with audio on Linux, but OSS (4 or otherwise) is not the answer to those problems and never was.