Rolling your own minimal embedded Linux for the Raspberry Pi -- part four: audio

This series of articles is about building up a custom, minimal Linux installation for the Raspberry Pi (or similar), for use in an appliance. As I've complained repeatedly, the Raspberry Pi units -- particularly the small ones -- are ideal for low-volume embedded use, but all the official Linux releases for the Pi are oriented towards desktop-type operation. To assemble a Linux installation suitable for embedded operation means, essentially, starting from the very beginning, with a kernel and a shell.

The previous article in the series, on managing services and remote access was fairly complicated but this one, I hope, will be a lighter read. It's still not trivially simple -- I envisage a system where everything has to be configured manually -- in an appliance-oriented Linux we can't rely on udev, DBus, systemd, and all the other heavyweight infrastructure that a desktop or server Linux would have.

Constraints

Although many desktop Linux systems now use Pulse or JACK for complex audio processing and routing, for an embedded system it's likely to be better to rely on native ALSA support. ALSA is already quite sophisticated, except perhaps where integration with graphical tools is concerned. I question whether the complexity of Pulse is really necessary on most desktop Linux systems -- but I'm sure it's rarely necessary in an appliance.

I'm assuming that, in an embedded system, there will only be one audio device. It isn't all that difficult to handle multiple devices with ALSA, but the absence of management frameworks like DBus creates more work for the system builder, if you want the user to be able to switch devices at runtime.

The built-in audio hardware on the Pi 3B range is.... adequate. It's OK for speech and general warning beeps, but it's not exactly hi-fi. On the other hand, more-or-less any general-purpose USB audio device will work with the Pi, given the appropriate drivers. The Pi 3's share the internal USB bus with the networking components, and early models (or early kernels) were prone to drop-outs in USB audio. This doesn't seem to be a problem for the latest models (or the latest kernels), at least at CD audio sampling rates or lower. In any case, it doesn't make a huge difference to software configuration what kind of audio device you use, but supporting multiple devices in a minimal appliance will be a bit of a challenge. At the time of writing, I'm not sure whether the Pi 4 will change this situation.

Initial checks

As a first step, if you plan to use the Pi's built-in audio capabilities, ensure that audio is not disabled in firmware. In the boot partition, in config.txt, ensure there is a line like this:

dtparam=audio=on

Some Pi models (or some kernels) automatically route the built-in audio to the HDMI when an HDMI monitor is connected. There are software tools to change this, and there are HDMI in-line dongles that will extract the audio to a headphone jack if you're using an HDMI monitor without audio support. In any case, it's important to be aware that, if audio seems to be working but you're not hearing anything, the problem might not be in software -- you might just have your speaker/headphone connected to the wrong port.

Software required

Most of the required software is in kernel modules. If you have kernel modules in the conventional tree structure, and an up-to-date modules.dep file (e.g., from running depmod) then loading just the device-level module will suffice -- the module-loading infrastructure will take take of the dependencies. If you're handling modules explicitly, you'll need to work out all the dependencies, either by trial-and-error, or by examining the modules.dep from a desktop Raspbian system.

In the Raspberry Pi 3 series, the built-in sound generator is supported by the snd-bcm2835 module. Its dependencies are snd-pcm, snd-timer, and snd. Most USB sound devices are supported by snd-usb-audio, whose dependencies are snd-hwdep, snd-usbmidi-lib, snd-rawmidi, snd-seq-device, snd-pcm, snd-timer, and snd. I don't really understand why the USB audio module has dependencies on MIDI modules -- I presume that USB MIDI devices and USB PCM devices are supported by the same module.

Although it is possible, in principle, to produce audio by writing to the ALSA devices in /dev/snd (of which, more below), in practice I think every application or library that uses ALSA does so through the libasound.so library. This library is in the libasound2 Raspbian package.

Unless you're very lucky, or very knowledgeable, it's probably worth installing the basic ALSA utilities like alsamixer and aplay. These are all in the alsa-utils package. In the experimental stage, aplay -L is particularly useful, as it displays a list of output devices. This will usually be a long list, even if only the built-in audio is enabled, as there will be multiple virtual devices with different capabilities.

There will be, for example, different devices for the 3.5mm audio jack and the HDMI audio channel. An additional important distinction is between the hw and plughw devices -- in most cases the plughw device is more appropriate, because it will do the appropriate sample rate and format conversions when playing audio with properties that not directly supported by the hardware.

/dev/snd devices

If the driver modules are installed and initialized properly, you should see entries created in the /dev/snd directory. You don't need udev for this to happen -- the pseudo-devices are created directly by the kernel. With a single PCM audio device (like the built-in audio hardware), you should see something like this:

$ ls -l /dev/snd
crw-rw---- 1 root root 116,  0 Feb 29 09:59 controlC0
crw-rw---- 1 root root 116, 16 Feb 29 09:59 pcmC0D0p
crw-rw---- 1 root root 116, 17 Feb 29 09:59 pcmC0D1p
crw-rw---- 1 root root 116,  1 Nov  8 20:17 seq
crw-rw---- 1 root root 116, 33 Feb 29 09:59 timer

In a desktop system, however, the group ownership of these devices is conventionally changed by udev to audio. This is a sensible change, even in an embedded system -- you probably don't want the kind of processes that produce audio running as root. In the absence of udev, you'll need to make the ownership change in some script -- probably the same script that loads the kernel modules.

Then, all being well, any process that is a member of the group audio will be able to play audio.

Next: running X applications on an appliance; or go to the series index.