3 ms·

>"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 eit

by 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.
      - PaulDavisThe1st 4y ago
        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.

by trasz 4y ago

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.
    - PaulDavisThe1st 4y ago
      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.