IN DEPTH Inside Linux

Matt Holder delves into the depths of our audio stack to learn about PipeWire and what came before it.

CREDIT: Magictorch

In parts one and two of this Inside Linux series, we covered the Linux kernel and learned all about the different layers and subsystems that enable us to interact with all of the hardware connected to our computers. In part three we looked at graphical displays and how Wayland has been developed to replace the venerable X server.

The aim of this fourth part is to help you understand how the audio subsystems on your Linux distro work together, to give you a professional grade system that can be used for pretty much any purpose.

Once we have introduced the various systems, we will move on to describe how PipeWire can be used to provide some of the missing functionality from Wayland (such as the capture of apps and displays).

The Open Sound System (OSS) project started over 30 years ago and was developed for use on both BSD and Linux. The code was released under multiple licences, and the final release of OSS was in 2019, but it was superseded by the turn of the century on most Linux distros.

Get us ALSA here

Due to perceived issues with OSS, the Advanced Linux Sound Architecture (ALSA) project was first released in 1998. Until 2002, it was developed as a standalone project and then became part of the Linux kernel. In a similar way to OSS, ALSA provides a device driver between the kernel and userspace applications. The ALSA API is more complicated than OSS, which can make the creation of apps more complicated (although these days, this issue is abstracted to the graphical toolkit being used and the sound servers we will soon discuss). At conception, ALSA supported more features than OSS (such as hardware mixing of multiple channels and thread-safe drivers). Continued development of OSS likely means that the feature sets supported by both systems are largely the same. Both OSS and ALSA only support a single application being able to interact with the audio hardware at any one time. This is very limiting – imagine not being able to take part in a Teams call in which we wish to share our screen and play a video for the other members of the meeting to see, or being able to play music on our favourite streaming service while still being able to hear notifications from our applications. To counteract this limitation, sound servers have been developed, which sit on top of ALSA. Applications therefore interact with the sound server, which in turn mixes any audio sources together, routes them to different applications and then, where needed, interacts with the hardware via ALSA.