[cycloptic]

I'm not sure what larger issue you're pointing at and I don't think it makes sense to chalk this up to anything else; no sound server can magically figure out how to read that data sheet either. A random userspace daemon (that is optional) is just not the right place to put a fix for that. The burden for a fix likely falls on your distro to ship the correct udev rules, but figuring out what those are for all variations of hardware that use that driver is another story. With that who knows, the Windows and Mac driver could actually be doing something strange by default that just happens to work for most users, but isn't worth replicating if someone writing udev rules decides they want to do the "right" thing. See where I'm going with this? It's not just a quick fix, and I don't even know if it's the right one. Some other distro somewhere might even have a different way to do it. If you're really interested to make progress on this, you'll have to ask your distro's audio maintainers.

[RossBencina]

I think you put it well by writing "Pipewire is probably not going to make your ALSA configuration issues go away."

I never claimed there was a quick fix, but I kinda hoped that Pipewire/Redhat have the leverage to fix whatever needs to be fixed in the ALSA API to make userspace audio a seamless experience.

My naive impression is that the ALSA driver model is "broken"[1] -- most likely because many parts that need to seamlessly work together are atomized into different subsystems with no one organisation held responsible. As you seem to be suggesting, correct operation appears to depend on correct configuration by either the distro and/or the end user.

There should be nothing to configure. The driver architecture should be structured such that it is not possible to ship a "working driver" that then requires individual distro maintainers to intervene for the user to experience "working audio". For example, if the mixer hardware needs to be configured for correct operation, that configuration should be part of the driver or kernel, not some auxiliary file that may or may not be correct in a given distro.

[1] where by "broken" I mean that it incapable of providing the kind of zero configuration plug and play experience that is available on Windows with ASIO, or with CoreAudio.

[PaulDavisThe1st]

Ross, the main issue with ALSA these days is not the API at all. It's the cases where the people responsible for the code cannot get (easy) access to the information required to program whatever hardware mixer is present in the device.

This can be true for devices following the Intel HDA "specification" (which is still so loosely constructed when it comes to the mixer that it's barely a specification at all). It's also true for many of the USB interfaces out there - the audio/MIDI I/O part works flawlessly on Linux (thanks to iOS' "no driver" requirement), but there's no way to configure the hardware mixer. MOTU went with a web-based configuration process for some of their devices, which is truly lovely since it works on any device with a web browser. But companies like Focusrite (and many more) continue to refuse to openly provide the information required for the ALSA internals to control the hardware mixer on these devices. In some cases, they have been reverse engineered, but often only partially.

Note that the same limitation applies when using those devices on iOS: you cannot configure them fully, unless the manufacturer makes an iOS version of the "device control panel".

[PaulDavisThe1st]

Another reply from me ... another thing that ALSA doesn't do well, by itself, is allowing device sharing by multiple applications. In that regard, it is a lot like ASIO and at least one of other N Windows audio driver models. On Linux, the general design decision surrounding this has been to use a user-space daemon to provide this functionality - an approach that eventually even Apple ended up with (they refactored stuff, and moved coreaudiod from the kernel into user space).

So that means that systems like PulseAudio, JACK and PipeWire are where the "seamless experience" are going to happen, not really in ALSA. To use the comparison with CoreAudio, ALSA operates (1) as if every application enables hog mode. Try that sometime on macOS ... and watch your "seamless experience" completely fall apart :)

This is where PipeWire does offer some real hope. Whereas PulseAudio and JACK deliberately target different use cases/workflows, PipeWire seeks to unify them in a similar way to what coreaudiod does on macOS (device sharing, multiple sample rates, buffer sizes, etc. etc.)

Note that there is a cost to this, even on macOS. You cannot get the absolute minimum device latency on macOS, which you can on Linux. But most (all?) users on macOS seem OK with, either because they just don't know that or because they do and think that the convenience tradeoff is worth it. I imagine that if/when PipeWire reaches its full goals, it will impose a similar burden (though perhaps with an option to avoid it by disabling some functionality).

The key point, however, is that applications (2) are going to continue to either the ALSA or the JACK API for doing audio/MIDI I/O. ALSA ... because it's there, and has several 3rd party libraries built on top of it to make things simpler for developers. JACK ... because it's insanely well designed [:))] and gets the job done, portably and efficiently.

(1) well, it mostly does. The library that apps actually use to talk to ALSA can do device sharing, but it's never been widely used for that, and the design is bit ... well, it's not ideal.

(2) all apps except Skype and Firefox, which join the hall of shame for actually deciding to use the "native" PulseAudio API, something the original author of PulseAudio strongly recommended against.

[cycloptic]

If somebody wants to try to convince upstream to do it then they can, but that's a lot more involved task then getting a distro to do it.