3 ms·

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?

by trasz 4y ago

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.
      - PaulDavisThe1st 4y ago
        > It's not "thousands" 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 I have no idea what this is supposed to mean.
        trasz 4y ago
        >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.

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?

by 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.
    - PaulDavisThe1st 4y ago
      > It's not "thousands" 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 I have no idea what this is supposed to mean.
      - trasz 4y ago
        >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.