Advanced Linux Sound Architecture

Some of the goals of the ALSA project at its inception were automatic configuration of sound-card hardware and graceful handling of multiple sound devices in a system. ALSA is released under GPL-2.0-or-later and LGPL-2.1-or-later.

On Linux, sound servers, like sndio, PulseAudio, JACK (low-latency professional-grade audio editing and mixing) and PipeWire, and higher-level APIs (e.g., OpenAL, SDL audio, etc.) work on top of ALSA and its sound card device drivers. ALSA succeeded the older Linux port of the Open Sound System (OSS).

History

The project to develop ALSA was led by Jaroslav Kysela, and was based on the Linux device driver for the Gravis Ultrasound sound card. It started in 1998 and was developed separately from the Linux kernel until it was introduced in the 2.5 development series in 2002 (2.5.4–2.5.5).

In the 2.6 version, it replaced the previous system, Open Sound System (OSS), by default (although a backwards-compatibility layer does exist).

ALSA has a larger and more complex API than OSS, so it can be more difficult to develop an application that uses ALSA as its sound technology. While ALSA may be configured to provide an OSS emulation layer, such functionality is no longer available or is not installed by default in many Linux distributions.

4 more chapters are free with a Lably account.

Features

ALSA was designed with some features which were not, at the time of its conception, supported by OSS:

Hardware-based MIDI synthesis.
Hardware mixing of multiple channels.
Full-duplex operation.
Multiprocessor-friendly, thread-safe device drivers.

Besides the sound device drivers, ALSA bundles a user-space library for application developers who want to use driver features through an interface that is higher-level than the interface provided for direct interaction with the kernel drivers. Unlike the kernel API, which tries to reflect the capabilities of the hardware directly, ALSA's user-space library presents an abstraction that remains as standardized as possible across disparate underlying hardware elements. This goal is achieved in part by using software plug-ins; for example, many modern sound cards or built-in sound chips do not have a "master volume" control. Instead, for these devices, the user space library provides a software volume control using the "softvol" plug-in, and ordinary application software need not care whether such a control is implemented by underlying hardware or software emulation of such underlying hardware.

Applications

Additional to the software framework internal to the Linux kernel, the ALSA project also provides the command-line tools and utilities alsactl, amixer, arecord/aplay and alsamixer, an ncurses-based TUI.

There also are GUIs programmed by third-party developers, such as GNOME-ALSAmixer (using GTK), Kmix, XFCE4-mixer, LXpanel, QasHctl, QasMixer, Pavucontrol, AconnectGUI, tapiir, polarbear, ALSAmixerGUI (using FLTK), ZynAddSubFX, Yoshimi, and even more.

Architecture

ALSA consists of the following layers:

Part of the Linux kernel, which includes the core framework, and device drivers for (physical) sound cards;
a userspace library (alsa-lib), which provides API abstractions for applications, as well as the implementation of plugins (and virtual sound cards and devices based on them).

Concepts

Sound cards

Typically, ALSA supports up to eight physical sound cards (or cards for short), numbered 0 through 7. Each sound card may also be addressed by its id, which is usually an explanatory name such as "Headset" or "ICH9". Sound cards are supported in the kernel via device drivers.

Interfaces & devices

ALSA defines multiple interfaces for accessing cards; these include pcm (including playback and capture devices), control (or ctl for short), timer, raw MIDI (rawmidi), or sequencer (seq). For individual sound cards, these interfaces are represented as devices, corresponding to device files in /dev/snd.

Each card may contain a control device (for the control interface), which provides control elements (such as volume control); and any number of devices associated with other interfaces.

Some devices (such as pcm, rawmidi) may contain subdevices, numbered starting at 0; a subdevice represents some relevant sound endpoint for the device, such as a speaker pair.

Plugins

In addition to physical cards, ALSA also supports virtual sound cards via the plugin system; this includes plugins that transform input/output from physical devices, as well as those implemented entirely in software (including connections to sound servers such as PulseAudio). Plugins (and the virtual sound cards and devices they create) may elect to support only some of the above interfaces, and may or may not define multiple devices or subdevices.

Common cards and devices include:

hw (hw:[card]:[device]:[subdevice]): provides direct access to the underlying physical device, with no software mixing or stream adaptation support;
- For example: ctl.hw:CARD=0 (control interface on sound card 0); pcm.hw:CARD=1,DEV=3,SUBDEV=2 (sound card 1, PCM audio device 3, subdevice 2)
plughw (plughw:[card]:[device]:[subdevice]) and dmix (dmix:[card]:[device]:[subdevice]): similar to hw, but provides software support for additional features such as sampling rate conversion;
default: this is an alias for the default sound card or device;
pulse: the PulseAudio sound server.

Streams

An ALSA stream is a data flow representing sound; the most common stream format is PCM that must be produced in such a way as to match the characteristics or parameters of the hardware, including:

sampling rate: often 44.1 kHz on home stereos, or 48 kHz on home theaters, yet up to 88.2 kHz, 96 kHz, or even 192 kHz for hi-fi audio production or reproduction.
sample width: measured in some number of bits per sample (such as 8, 16, 24, or 32 bits/sample)
sample encoding: such as endianness
number of channels: 1 for mono, 2 for stereo, or 6 for AC-3/IEC958

Implementations

The ALSA System on Chip (ASoC) layer aims to provide better support for ALSA on embedded systems that use a system-on-chip (SoC) design.

Open Sound System version 4 is able to emulate ALSA.

QNX uses a sound system derived from, but not directly compatible with ALSA. The header file and library names are still "asound", same as the ALSA names. ALSA API uses ioctl() calls in a way not allowed in the QNX kernel.