3 ms·

so, that workgroup has an admirable goal, and such a guide is what I do crave, and I confess to being basically ignorant and having difficulty in comprehending

so, that workgroup has an admirable goal, and such a guide is what I do crave, and I confess to being basically ignorant and having difficulty in comprehending all the folders full of linux and legacy STUFF in alsa ... where are the drivers? what even is the driver? lol. what interfaces must a driver implement? what parts of ALSA are required when opening, configuring, and streaming to/from a device and what parts are ALSA itself and what are in the particular driver? (not at all helped by having arch's on the top folder level, right next to transports/busses) and core having been called the heart of ALSA but yet all I see there is oss ioctl and something about a sequencer!? huh? sequencer? ) Opening a device, configuring it, registering a callback function, this is all standard across API's and people are used to PortAudio, SDL, etc. I've hooked up audio converters to microcontrollers, fpga's etc and am familiar with the hw signals entailed for interfacing over I2S, TDM over I2S, control interfaces via SPI and I2C, the timing of these signals, and the particularity of crystals such as the venerable 11.2896mhz, and I would go so far as to swap out a different crystal and force a singular sample rate on the entire system forever, yes I'm a fanatic, lol... but I digress... I have no notion of what the host side of an audio interface looks like, and have never seen the "other side" of the mcu/fpga in your blackbox usb soundcard. (xmos? some glorified ftdi chip?) Am I to understand that ALSA only knows about the precise sample-clock-timing at each full audio buffer interrupt or period?! What does the host side of an audio interface look like? (some pcm_stream's? any control interfaces? is the sample clock not passed onward to the host from the device (mcu+codecs)?) I guess what I'm fundamentally puzzled about is how all these folders of ALSA "stuff" inter-relate and how the heck the sprawling collection of related modules actually relate to each other, and what one must actually do in order to bring up new hardware under ALSA... any advice, psychiatric or audio hardware related, taken to heart.

PaulDavisThe1st 7y ago
I don't have the time and these days don't really have the expertise to take you on a tour of the ALSA codebase. All audio interfaces that I'm familiar with work on basically the same principles (except for a couple that I think should be thrown on the junk pile for design reasons). They have a memory buffer which they treat as a ringbuffer, and periodically as they traverse the ringbuffer they raise an IRQ with the CPU. The CPU reads/writes from/to the buffer, and assuming that it does so on time, things continue on smoothly. These days most devices can function as DMA bus masters, meaning that the CPU does not need to explicitly move data to/from the device - the device is given an address in system memory and uses that. Very few devices have a register that can be read to determine the read/write pointer position within the buffer. Therefore a design predicated on this idea (which you'd think would be a no brainer) is going to fail for the majority of devices. So the "pcm" zone of an ALSA driver is the part that takes care of handling interrupts and data transfer. ALSA represents each direction as a separate device, a decision I was never in love with, but CoreAudio and most Windows driver APIs do the same so what can you do ... Then there's an entirely separate aspect to many audio interfaces which is far more complex and difficult. In ALSA it is represented by the "control" API, in which ALSA tries to present as many of the controls present in the device and allow them to be manipulated. Since there is a massive variation in the number, nature and interdependence of these controls, this is very challenging to present to the user. This is partly why there are often dedicated control applications for high end cards on Windows and macOS. There's no particular connection between the PCM and the control aspects of an ALSA driver, although obviously they are related and implemented together. Sample clock is not visible to the CPU. Sample clock exists only at the device hardware level. Deciding which clock source to use is an option on a few pro-level cards, and ALSA "exports" this functionality via the control API. USB audio device support is particularly problematic because the USB bus is uniquely unsuited to this purpose, and also because despite the standard, many/most devices have "quirks" that need to be accomodated in order to function fully. As a result, although there is really just a single driver per USB class, there is quite a bit of code associated with dealing with quirks of specific devices. This is decreasing for reasons I alluded to early: if you want to sell a device to iPad users, you cannot tell them to install a driver, and so manufacturers have been getting steadily more and more conformant.
- hootbootscoot 7y ago
  Thank you, Paul, for taking the time to explain this.

PaulDavisThe1st 7y ago

I don't have the time and these days don't really have the expertise to take you on a tour of the ALSA codebase. All audio interfaces that I'm familiar with work on basically the same principles (except for a couple that I think should be thrown on the junk pile for design reasons). They have a memory buffer which they treat as a ringbuffer, and periodically as they traverse the ringbuffer they raise an IRQ with the CPU. The CPU reads/writes from/to the buffer, and assuming that it does so on time, things continue on smoothly. These days most devices can function as DMA bus masters, meaning that the CPU does not need to explicitly move data to/from the device - the device is given an address in system memory and uses that. Very few devices have a register that can be read to determine the read/write pointer position within the buffer. Therefore a design predicated on this idea (which you'd think would be a no brainer) is going to fail for the majority of devices. So the "pcm" zone of an ALSA driver is the part that takes care of handling interrupts and data transfer. ALSA represents each direction as a separate device, a decision I was never in love with, but CoreAudio and most Windows driver APIs do the same so what can you do ... Then there's an entirely separate aspect to many audio interfaces which is far more complex and difficult. In ALSA it is represented by the "control" API, in which ALSA tries to present as many of the controls present in the device and allow them to be manipulated. Since there is a massive variation in the number, nature and interdependence of these controls, this is very challenging to present to the user. This is partly why there are often dedicated control applications for high end cards on Windows and macOS. There's no particular connection between the PCM and the control aspects of an ALSA driver, although obviously they are related and implemented together. Sample clock is not visible to the CPU. Sample clock exists only at the device hardware level. Deciding which clock source to use is an option on a few pro-level cards, and ALSA "exports" this functionality via the control API. USB audio device support is particularly problematic because the USB bus is uniquely unsuited to this purpose, and also because despite the standard, many/most devices have "quirks" that need to be accomodated in order to function fully. As a result, although there is really just a single driver per USB class, there is quite a bit of code associated with dealing with quirks of specific devices. This is decreasing for reasons I alluded to early: if you want to sell a device to iPad users, you cannot tell them to install a driver, and so manufacturers have been getting steadily more and more conformant.

hootbootscoot 7y ago
Thank you, Paul, for taking the time to explain this.