Not expecting an answer for this but always found strange.
I know this is more complicated then this simple question but
-In Linux, drivers are provided by the kernel, which is what Linux is.
-ALSA is one of these drivers.
-ALSA driver is limited to only 1 audio source at a time.
Rather then all these layers of audio added over the years
ALSA, JACK, PulseAudio, Pipewire, etc.
Couldn’t this have just been handled on a driver level, allowing the possibility for more then one audio source at the driver level?
Or does how it is handled currently using mulitple audio layers make more sense to be used?
Again I am sure there are different reasons for this but just seems strange.
The short answer is no, same as on other all OS (macOS, Windows).
First of all, mixing is not something a driver should do. Conceptually it should just expose the soundcard’s interface as-is. More importantly the kernel must not perform any floating point operations (it may clobber FPU state). Besides that, various user-space applications have different demands (buffersize, sample-rate), potentially requiring resampling, which should definitely not happen at driver level.
The problem with Linux, unlike macOS, is that there is no central authority who can mandate the use of a single user-space audio interface (like Steve Jobs did for OS X).
To add to what @x42 said … on macOS this stuff used to be done in the kernel, but starting at least 10 years ago, apple moved it out. If you check the running processes on a modern macOS system you will find coreaudiod running, which is basically their version of pipewire. Applications that do audio I/O talk to coreaudiod (they don’t know that they do this), and coreaudiod coordinates everything and interacts with the hardware via the kernel driver.
As I recall, ALSA does have the ability to use multiple audio interfaces, mix them, etc. and also to apply special processing to audio.
I suspect, however, that this is a separate layer above the part of ALSA that deals with interfacing with hardware.
Despite that capability being there, it’s not really suitable for managing desktop audio, so there’s always been something else that does that (ESD, aRts, Pulse audio, Pipewire) that does that.
As such, these capabilities of ALSA are not that useful and are rarely used these days.
I’ll also point out that it’s good software/system design to separate out functionality (separation of concerns) and to layer different capabilities like this. Having everything in one monolithic package is poor design.
…which is why we ended up with JACK and pulseaudio on top of alsa, and now pipewire trying to replace those 2, but it still needs a lot of work especially to get ultra low latency like JACK does.
Thank you guys for all of these replies some great information.
Yeah when I brought this up I did not think/mean this could be handled entirely hardware / kernel / driver level, there would have to be some kind of layer for the user to interact with.
I don’t know just always seemed like a lot of approaches / layers which at times could be a little confusing, but overall I guess each one does make sense because they are all dealing / solving different use case/issues.
As far as MacOS yeah that makes sense because they have the unique situation where basically everything is a part of their “ecosystem”, so they can make bigger decisions. Even in their situation though probably still pretty difficult to get everything compatible, but easier when you own / control everything!!!
