4 ms·

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 t

by 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.
PaulDavisThe1st 4y ago
Also: > Also maybe bit width, and number of channels, and sampling rate No, those are part of the setup for the PCM (I/O) API. An application sets those when using the device. The controls I am referring to are independent of audio streaming by an application.

by trasz 4y ago

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.

PaulDavisThe1st 4y ago

Also: > Also maybe bit width, and number of channels, and sampling rate No, those are part of the setup for the PCM (I/O) API. An application sets those when using the device. The controls I am referring to are independent of audio streaming by an application.