Writing an ALSA Driver (2007)

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).

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.