[n3k5]

Interesting; can you or someone please elaborate? I thought that device-specific drivers wouldn't be needed for the vast majority of audio interfaces, because they're connected via USB and all they need to do to ‘just work’ upon plugging in is implementing the relevant USB device class.

From my (programmer's) point of view, all I need to know to work with an audio interface is the number of input and output channels and the respective arrays of sample rates and bit depths. In theory, a generic USB driver can handle that. In practice, I observe that my Linux-using colleagues have 99 problems with audio, but none of those is related to plugging in a $1 dongle from AliExpress. (Therefore, I used to think that those audio interfaces ‘just work’, but now I'm curious about what I've been missing all along.)

Why is releasing Linux drivers for an audio interface even a thing?

[dTal]

That's true for the cheap dongles. Where it gets problematic are the high end "Audio Interfaces" for studio recording work. The USB Audio Class 1 standard was released in 1998 and supports 2 channels at 24/96, over USB 1.0. This is obviously anemic for all but the most basic work. The upgraded USB Audio Class 2 standard was released in 2009, but was unsupported in Microsoft Windows until an update to Windows 10 brought it in 2017. Therefore, prior to that, any manufacturer who wanted to support Windows were put in the position of writing their own drivers for anything with more than 2 channels.

https://www.thewelltemperedcomputer.com/KB/USB.html

[n3k5]

Aha, that's a good point! It was silly of me to assume that if any cheap dongle works, that should mean ‘proper’ interfaces would work at least as well.

However, it seems like that explains why we needed Windows drivers, but not why device-specific Linux drivers are a thing? Unless the implication is that manufacturers who needed to make custom drivers anyway didn't bother to make their devices class compliant?