3 ms·

Please DO tell, I'm literally ALL EARS: (I would LOVE to write an ALSA driver for a different transport mechanism, but I'm not even remotely clear on how the d

Please DO tell, I'm literally ALL EARS: (I would LOVE to write an ALSA driver for a different transport mechanism, but I'm not even remotely clear on how the different parts of ALSA relate, and this is after months of studying https://dri.freedesktop.org/docs/drm/sound/kernel-api/alsa-driver-api.html https://dri.freedesktop.org/docs/drm/sound/kernel-api/alsa-d... and I can't seem to make head nor tails of the different layers, partial layers, etc. I am sufficiently familiar with callback-api's and running audio codec's on the bare metal and via microcontrollers.) Additionally, how does Device Tree and Device Tree Overlays fit into this picture? Are ALSA transports limited to PCI, USB, etc? I haven't found a single ALSA driver tutorial online from the last decade. I've had a plethora of OTHER nonsense, such as why a given soundcards multichannel support only functions as "Surround Sound 5.1", replete with high-pass-filters on the primary pair of outputs it thinks are "Front L & R"... In terms of ALSA configuration, there appear to be a zillion ways (distro specific) to do so, and none of them appear actively used on my boring old Ubuntu 16.04 system, and I'm not even sure where this mystical blackbox asound.conf stuff is actually occuring these days, but suffice it to say that there are no userland applications that actually appear to address the audio interface properly, and there appear to be WAYYYYY too many abstraction layers hiding crucial hw configuration details from the people who need to use it: aka every computer audio person ever. I guess what is missing for me is this info on what part of ALSA one needs to write when trying to bring-up new hardware, how DMA can be used, in case of trying to directly interface a la ASoC, or how externally controlled audio devices (an MCU running the codec I2S interfaces, for examples) could be used to load a buffer up and present it to the computer (as the buffer interrupt rate will be closer to 1-2khz even with a 32 frame buffer, vs the strict requirements of the codec themselves) It almost seems as if that info is not online, or that my search terminology is incorrect

PaulDavisThe1st 7y ago
I wrote several ALSA drivers in the early 2000's. It hasn't changed much since then, but I'm not close enough to ALSA anymore at the kernel level ot offer any advice. What I can tell you is that stuff like "Device Tree" and "Device Tree overlays" are concepts restricted to one specific class of audio interface (based on HDA and its concepts), and do not exist in any of the devices you would actually buy to function as an audio interface. There are no "new" ALSA driver tutorials because, IIUC, ALSA hasn't really changed much in the last decade. Just like CoreAudio and the older Windows APIs (they finally have some new ones worthy of the name "audio API"). Your complaint about "why a given soundcards multichannel support only ..." is really just a reflection of the screwed up nature of HDA and its cousins. Again, if you go and actually buy a "real" multichannel soundcard, you won't run into this issue. If you're stuck with what a mobo or SoC maker gave you, then the problem is typically with the fact that they changed the h/w setup and relied on a BIOS hack to make it work. Driver stuff is "broken" with respect to much newer device hardware, but that's hardly suprising when Android ripped out ALSA and so nobody working on mainline kernels has much motivation to make ALSA work with the sort of audio hardware that shows up in things like phones. I do know that on very contemporary RPi systems, things like Ardour and JACK (both of which I wrote, by the way) work out of the box. There are two primary audio "transports" as you call them today: USB, which is more or less fully and totally supported by the class compliant ALSA driver (thanks, iPads, for enforcing a "no driver" policy") and HDA-via-PCI which is technically supported but the specs allow so much wiggle room that hardware makers (not audio hardware, mobos and SoC stuff) regularly and routinely break things. Most of your complaints seem to be centered on the HDA-via-PCI family of devices, and there's really not a lot Linux can do there. MS provides BIOS patches, Apple builds their own hardware - what's Linux supposed to do with a useless standard that is routinely ignored? I appreciate that "i just want my laptop audio to work" is a legitimate issue (although for the most part, they just do). But that's a tiny corner of what ALSA and audio is all about, and we're badly hurt by the (non)standard HDA and all of its misfeatures (which, as I noted Apple and MS workaroudn in different ways).
- hootbootscoot 7y ago
  Oh, I'm specifically referring to pro-audio (a Tascam 8x8 I/O, and a Presonus 1804) interfaces, that my Ubuntu 16.04 system was pretending were "surround sound" interfaces, so it's something configuration related, not ALSA/driver itself. (I'm exclusively interested in pro-audio, vs whatever the OP of this comment was concerned with) I have 2 interests with regard to this: 1) writing a driver for a home-brew soundcard with an MCU running the DAC/ADC TDM interfaces, and interfacing with the computer via SPI, as it's clock is a function of the audio sample clock running the whole shebang, and I never saw an SPI transport for ALSA in my life 2) just generally trying to get to the bottom of how linux/ALSA sees my soundcard hardware (the specific multi-channel audio interface being interpreted/configured as a surround sound interface etc.) I mentioned the Device Tree Overlays as it appears that this is how the Bela system manages it's PRU supported audio codecs in Alsa mode, but consider it a clueless comment off-topic... Thanks for writing back, I appreciate it! I'm a big Ardour fan. Jack is standard for everything in pro-audio these days, and yes, I know that you literally have spent 30 ++ years in this realm, hence my questions... By the way, when they ask for "quantizing audio" in Ardour, it's already there! I can say that the following works GREAT in Ardour: 1) strip silence function 2) snap the audio bits created by #1 to grid/quantize value.
- hootbootscoot 7y ago
  I guess I'm not entirely clear on what I would need to implement to use ALSA's PCM interface with an arbitrary transport, given a defined memory area and buffer size. I appear to be fuzzy on the topic of what parts I need to write and what is already provided, generally. The class-compliant USB interfaces do indeed generally "just work" (with the configuration issues I mentioned on my particular system, but I'm not clear on where this occurs, "channel mapping" or somesuch calling my 8 outputs a singular surround interface etc...)

PaulDavisThe1st 7y ago

I wrote several ALSA drivers in the early 2000's. It hasn't changed much since then, but I'm not close enough to ALSA anymore at the kernel level ot offer any advice. What I can tell you is that stuff like "Device Tree" and "Device Tree overlays" are concepts restricted to one specific class of audio interface (based on HDA and its concepts), and do not exist in any of the devices you would actually buy to function as an audio interface. There are no "new" ALSA driver tutorials because, IIUC, ALSA hasn't really changed much in the last decade. Just like CoreAudio and the older Windows APIs (they finally have some new ones worthy of the name "audio API"). Your complaint about "why a given soundcards multichannel support only ..." is really just a reflection of the screwed up nature of HDA and its cousins. Again, if you go and actually buy a "real" multichannel soundcard, you won't run into this issue. If you're stuck with what a mobo or SoC maker gave you, then the problem is typically with the fact that they changed the h/w setup and relied on a BIOS hack to make it work. Driver stuff is "broken" with respect to much newer device hardware, but that's hardly suprising when Android ripped out ALSA and so nobody working on mainline kernels has much motivation to make ALSA work with the sort of audio hardware that shows up in things like phones. I do know that on very contemporary RPi systems, things like Ardour and JACK (both of which I wrote, by the way) work out of the box. There are two primary audio "transports" as you call them today: USB, which is more or less fully and totally supported by the class compliant ALSA driver (thanks, iPads, for enforcing a "no driver" policy") and HDA-via-PCI which is technically supported but the specs allow so much wiggle room that hardware makers (not audio hardware, mobos and SoC stuff) regularly and routinely break things. Most of your complaints seem to be centered on the HDA-via-PCI family of devices, and there's really not a lot Linux can do there. MS provides BIOS patches, Apple builds their own hardware - what's Linux supposed to do with a useless standard that is routinely ignored? I appreciate that "i just want my laptop audio to work" is a legitimate issue (although for the most part, they just do). But that's a tiny corner of what ALSA and audio is all about, and we're badly hurt by the (non)standard HDA and all of its misfeatures (which, as I noted Apple and MS workaroudn in different ways).

hootbootscoot 7y ago
Oh, I'm specifically referring to pro-audio (a Tascam 8x8 I/O, and a Presonus 1804) interfaces, that my Ubuntu 16.04 system was pretending were "surround sound" interfaces, so it's something configuration related, not ALSA/driver itself. (I'm exclusively interested in pro-audio, vs whatever the OP of this comment was concerned with) I have 2 interests with regard to this: 1) writing a driver for a home-brew soundcard with an MCU running the DAC/ADC TDM interfaces, and interfacing with the computer via SPI, as it's clock is a function of the audio sample clock running the whole shebang, and I never saw an SPI transport for ALSA in my life 2) just generally trying to get to the bottom of how linux/ALSA sees my soundcard hardware (the specific multi-channel audio interface being interpreted/configured as a surround sound interface etc.) I mentioned the Device Tree Overlays as it appears that this is how the Bela system manages it's PRU supported audio codecs in Alsa mode, but consider it a clueless comment off-topic... Thanks for writing back, I appreciate it! I'm a big Ardour fan. Jack is standard for everything in pro-audio these days, and yes, I know that you literally have spent 30 ++ years in this realm, hence my questions... By the way, when they ask for "quantizing audio" in Ardour, it's already there! I can say that the following works GREAT in Ardour: 1) strip silence function 2) snap the audio bits created by #1 to grid/quantize value.
hootbootscoot 7y ago
I guess I'm not entirely clear on what I would need to implement to use ALSA's PCM interface with an arbitrary transport, given a defined memory area and buffer size. I appear to be fuzzy on the topic of what parts I need to write and what is already provided, generally. The class-compliant USB interfaces do indeed generally "just work" (with the configuration issues I mentioned on my particular system, but I'm not clear on where this occurs, "channel mapping" or somesuch calling my 8 outputs a singular surround interface etc...)