4 ms·

The audio thing is so true. OSS is the unix de-facto standard. All problem with OSS was fixed in OSS4.

PaulDavisThe1st 4y ago
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.
- trasz 4y ago
  OSS is definitely not the right thing for end applications to use, I fully agree here, but what's wrong with OSS as a kernel API, compared to ALSA?
  - PaulDavisThe1st 4y ago
    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)
    - trasz 4y ago
      >"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?
      - PaulDavisThe1st 4y ago
        > 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!
        trasz 4y ago
        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.
elpescado 4y ago
> OSS is the unix de-facto standard Is unix actually used for "serious audio"? If not, talking about "de-facto standards" doesn't make any sense.
- oriolid 4y ago
  Does MacOS count?
  - elpescado 4y ago
    Does macOS use OSS?
    - oriolid 4y ago
      No, but it is used for "serious audio" as in professional music and other media production and is Unix as in Apple went and paid Open Group to certify it as one. I thought this was fairly common knowledge and you'd be trying to refute one or other. But yes, a specific Unix system (macOS) is used for stuff that most people would consider serious audio, and OSS is not involved unless it's hidden somewhere under layers of Core Audio.
- NexRebular 4y ago
  Well... there is quite a bunch of "serious audio" software available for IRIX.
  - elpescado 4y ago
    Yeah, if I had to guess, I'd bet on IRIX too. But it seems that IRIX uses [AL (Audio Library)](https://nixdoc.net/man-pages/IRIX/man3d/alIntro.3d.html https://nixdoc.net/man-pages/IRIX/man3d/alIntro.3d.html), not OSS.
    - smm11 4y ago
      Irix "uses?" I'm sure there are one or two SGI boxes still ticking out there, but I haven't booted mine in months.

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.

trasz 4y ago
OSS is definitely not the right thing for end applications to use, I fully agree here, but what's wrong with OSS as a kernel API, compared to ALSA?
- PaulDavisThe1st 4y ago
  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)
  - trasz 4y ago
    >"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?
    - PaulDavisThe1st 4y ago
      > 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!
      - trasz 4y ago
        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.

elpescado 4y ago

> OSS is the unix de-facto standard Is unix actually used for "serious audio"? If not, talking about "de-facto standards" doesn't make any sense.

oriolid 4y ago
Does MacOS count?
- elpescado 4y ago
  Does macOS use OSS?
  - oriolid 4y ago
    No, but it is used for "serious audio" as in professional music and other media production and is Unix as in Apple went and paid Open Group to certify it as one. I thought this was fairly common knowledge and you'd be trying to refute one or other. But yes, a specific Unix system (macOS) is used for stuff that most people would consider serious audio, and OSS is not involved unless it's hidden somewhere under layers of Core Audio.
NexRebular 4y ago
Well... there is quite a bunch of "serious audio" software available for IRIX.
- elpescado 4y ago
  Yeah, if I had to guess, I'd bet on IRIX too. But it seems that IRIX uses [AL (Audio Library)](https://nixdoc.net/man-pages/IRIX/man3d/alIntro.3d.html https://nixdoc.net/man-pages/IRIX/man3d/alIntro.3d.html), not OSS.
  - smm11 4y ago
    Irix "uses?" I'm sure there are one or two SGI boxes still ticking out there, but I haven't booted mine in months.