> I still don't really understand Linux audio layers and how all this stuff works together
My simple understanding is that in the Linux audio stack you have the following layers:
- kernel-driver for local sound devices (provides exclusive access, no mixing/multiplexing).
- application-level audio-frameworks/APIs which are device-agnostic (pulse, ALSA, jack), can support, mix and multiplex multiple concurrent streams/applications.
- these different application-level frameworks can have several different back ends (for real HW, BT, virtual devices, network targets, etc, other Linux application-level audio-frameworks. )
(Someone correct me if I’m wrong)
Applications target a framework, but not all target the same, so the frameworks needs to be able to “plug together” so the speak.
This leaves the possibility if the following scenario:
App written for ALSA -> ALSA -> ALSA’s Pulseaudio backend -> PulseAudio -> Real hardware
PulseAudio in particular is very featured, modular and pluggable which is why most desktops Linux distros uses this by default these days.
It supports things like transparent network streaming between various kinds of targets and lets you compose “audio graphs” if need to.
And that’s probably why it was chosen for the experiment in this blog post.
ALSA is (confusingly) two things: a userspace library and API, complete with plug-ins and configurability and even mixing, and also the kernel API that underlies it to talk to the physical hardware.
So a typical chain ends up being legacy app -> ALSA -> PulseAudio -> ALSA -> kernel, because ALSA both frontends PA for legacy ALSA-only apps to use it, and also backends PA to talk to the real hardware.
But ALSA isn't the only backend for PA. For example, Bluetooth audio output will go via BlueZ and into kernel socket APIs instead, since Bluetooth audio is a network protocol, not something handled in the kernel. And then there's FFADO, a userspace driver for FireWire audio devices. And you can put JACK on top of that. And then you can put PulseAudio on top of JACK. Or you can out JACK on top of PulseAudio, but that'd be silly. And PA can go over the network, both from app to a remote PA daemon, and also from PA daemon to PA daemon. And there's also netJACK if you want to put that on a network.
And now PipeWire is replacing JACK and PulseAudio and impersonates their APIs and also ALSA and lets everything talk to everything else.
Basically it's complicated, but also very flexible. In the end though, there is usually one "default" setup that you get if you don't do anything on a typical distro, and that's, these days, apps -> [ALSA ->] PulseAudio -> {ALSA -> kernel, BlueZ -> kernel} for most typical use cases (native PA apps and ALSA apps, local audio and bluetooth backends).
> Or you can out JACK on top of PulseAudio, but that'd be silly
It doesn't give you low latency, but if you don't care about that this is a nice way of using JACK applications without interrupting other applications that might be using PulseAudio; for development it's pretty handy.
My simple understanding is that in the Linux audio stack you have the following layers:
- kernel-driver for local sound devices (provides exclusive access, no mixing/multiplexing).
- application-level audio-frameworks/APIs which are device-agnostic (pulse, ALSA, jack), can support, mix and multiplex multiple concurrent streams/applications.
- these different application-level frameworks can have several different back ends (for real HW, BT, virtual devices, network targets, etc, other Linux application-level audio-frameworks. )
(Someone correct me if I’m wrong)
Applications target a framework, but not all target the same, so the frameworks needs to be able to “plug together” so the speak.
This leaves the possibility if the following scenario:
App written for ALSA -> ALSA -> ALSA’s Pulseaudio backend -> PulseAudio -> Real hardware
PulseAudio in particular is very featured, modular and pluggable which is why most desktops Linux distros uses this by default these days.
It supports things like transparent network streaming between various kinds of targets and lets you compose “audio graphs” if need to.
And that’s probably why it was chosen for the experiment in this blog post.