Kevin Boone

Going back to ALSA in 2024

ALSA is the low-level audio driver architecture in the Linux kernel. It’s been around for twenty years, and I suspect it’s supported by every Linux system on Earth that does audio. Still, over the last ten years or so we’ve got used to not using ALSA directly. Instead, most mainstream Linux distributions provide a sound server that wraps ALSA, and provides additional features. The most common of these wrappers are Pulse and PipeWire. Pulse seems these days to be mostly associated with Ubuntu-like systems; PipeWire is more used by Fedora and its derivatives.

Both Pulse and PipeWire work reasonably well for most people and, frankly, there’s little reason to remove them. Even systems that don’t enforce the use of an audio server, like Gentoo, still provide one, and I suspect most users install one. However, there are a few reasons why we might want to avoid these things, and just use ALSA directly.

There are good reasons to persist with modern audio servers, despite these limitations.

What to expect with ALSA alone

If you really do want to remove Pulse/PipeWire, and have the perseverance to do it, here’s what you can expect.

Audio mixing does work, despite what everybody says

One of the claimed benefits of Pulse, when it was first released, was that it would allow multiple applications to play audio at the same time. ALSA has had this support built in for at least ten years. What Pulse can do, however, and ALSA can’t, is provide separate volume controls for different applications.

There may, or may not, be audio control integration in the desktop

I use Xfce4 which does, in principle, have an ALSA mixer control. I say ‘in principle’ because, so far as I can see, it doesn’t exist in any of the mainstream Linux repositories. You’d have to build it from source.

Of course, you can always run alsamixer in a terminal – it’s just the lack of a graphical control that’s a nuisance.

You’ll probably also find that the keyboard volume controls won’t work. You should be able to map these keys to alsactl commands to change the volume but, if you have multiple ALSA audio devices, it won’t always be obvious which one you’re changing.

You’ll probably have to tell software which ALSA device to use

ALSA dates from a time before it was common to have multiple audio devices in the same computer. Now it uncommon not to. Most computers will have at least one conventional soundcard, and one or more HDMI audio channels.

You’ll probably have to tell your software which device to use, and the way to do that will vary from one application to another. For VLC, for example, I do:

$ vlc -A ALSA --alsa-audio-device=...

Working out which ALSA device to use can be a challenge. Even if the software lists the ones it knows about (as the VLC graphical interface can) the list almost certainly won’t be complete. You have to know something about how ALSA works to choose the right device. I go into this subject more in my article on bit-perfect ALSA.

For simple cases, I wrote a little Java program jalsaselector which changes the default ALSA output card.

You certainly won’t be able to change ALSA devices whilst an application is running. That’s a capability that really does need an audio server.

apulse can come to the rescue when applications only support Pulse

apulse is an application wrapper that intercepts API calls to Pulse, and converts them to ALSA operations. It works for both input and output. It’s not foolproof, because it doesn’t implement the entire Pulse API; but it’s sufficient, for example, for making Firefox do Zoom calls.

apulse has the same problem that all ALSA applications have in the modern world: it doesn’t provide an easy way to select between multiple audio devices. At the command line, you can use environment variables, like this:

$ APULSE_PLAYBACK_DEVICE=bluealsa apulse firefox

This way of working won’t give you a way to change output or input devices on the fly, once the application is running; but that’s a problem with ALSA in general, not with apulse.

Headphones will be a headache. Well, Bluetooth ones will.

Assuming that your Linux installation provides fundamental Bluetooth support – so you can list, pair, connect, and disconnect devices – you can use bluealsa to make the connection between ALSA and the Linux Bluetooth stack.

bluealsa runs as a daemon, and interacts with DBus for finding device information. Some fiddly configuration at the DBus level is necessary for it to work with non-root users.

bluealsa provides an ALSA protocol, not a card. It won’t appear, for example, in the list of cards you get from /proc/asound/cards. This means that it usually isn’t seen as a potential target by audio applications, even those with good ALSA support. You’ll have to specify the bluealsa device on the command line and, again, the way to do that varies between applications.

Because ALSA doesn’t support dynamic switching of output devices, making a Bluetooth device a default is hazardous because, if the Bluetooth device is switched off, ALSA will have no output at all.

Another problem is that the version of bluealsa in mainstream Linux repositories probably won’t support high-quality audio profiles like AptX. These are proprietary, and subject to patent complications. I believe you can get this support by building bluealsa from source, if you have the necessary dependencies. I haven’t tried this, so I can’t comment on how well it works. Without AptX and the like, the best audio quality you’ll get is A2DP. That’s not the worst of the Bluetooth audio profiles in common use, but it’s still pretty awful.

Finding the necessary documentation to set this all up is quite difficult, because Bluetooth support and ALSA support are documented – to the extent that they are documented at all – in different places. Expect some head-scratching.

All in all, while an ALSA-only system will support Bluetooth audio, I have to wonder whether it’s worth the effort.

The future

Of the Linux distributions I use, only Gentoo provides adequate documentation for using ALSA alone. Gentoo even has some documentation for bluealsa. At this time, nearly all the software you need to run an ALSA-only Linux effectively on Fedora or Ubuntu is still in these distributions’ binary repositories. How long that will remain the case, as the distributions continue to focus their efforts on Pulse and PipeWire, remains to be seen. Even now, removing Pulse from Ubuntu, or PipeWire from Fedora, is so difficult that it’s hardly worth the effort.

Gentoo, however, continues to make an ALSA-only system practicable, with a bit of effort. Well, a lot of effort, if you want to use Bluetooth audio.