Jump to content

Advanced Linux Sound Architecture

From Wikipedia, the free encyclopedia
ALSA
Original authorJaroslav Kysela[1]
DeveloperALSA team[2]
Release1998; 28 years ago (1998)
Stable release
1.2.16.1[3] / 12 June 2026; 2 months ago (12 June 2026)
Written inC[4]
Operating systemLinux
Type
License
Websitealsa-project.org
Image
The Linux API is composed out of the System Call Interface of the Linux kernel, the GNU C Library (by GNU), libdrm, libalsa and libevdev (by freedesktop.org).
Image
ALSA is part of the Linux kernel. Sound servers (such as PulseAudio) and higher-level APIs (such as SDL) are middleware.

Advanced Linux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.

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.[5]

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

[edit]

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).[6]

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

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.

Features

[edit]

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

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

[edit]

Additional to the software framework internal to the Linux kernel, the ALSA project also provides the command-line tools[8][9][10] and utilities[11] alsactl,[12] amixer,[13] arecord/aplay and alsamixer,[13] an ncurses-based TUI.

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

Concepts

[edit]

Sound cards

[edit]

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.[17][18][19]

Interfaces & devices

[edit]

ALSA defines multiple interfaces for accessing cards; these include pcm (including playback and capture devices), control (or ctl for short), timer, or sequencer. 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 may contain subdevices, numbered starting at 0; a subdevice represents some relevant sound endpoint for the device, such as a speaker pair. These are represented as device files in /dev/snd.[19][20]

Plugins

[edit]

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[19][21], as well as those implemented entirely in software (including connections to sound servers such as PulseAudio)[22]. 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.[citation needed]

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.[22]

Streams

[edit]

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

[edit]

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.[23]

Open Sound System version 4 is able to emulate ALSA.[24]

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.[25] ALSA API uses ioctl() calls in a way not allowed in the QNX kernel.[26]

See also

[edit]

References

[edit]
  1. ↑ "Jaroslav Kysela - Perex soft".
  2. ↑ Alsa Team, alsa-project.org, 2008-09-29, retrieved 2012-01-08
  3. ↑ "alsa-lib,alsa-ucm-conf 1.2.16.1 release".
  4. ↑ "ALSA", Analysis Summary, Ohloh, archived from the original on 2013-12-20, retrieved 2012-01-08
  5. 1 2 "Introduction". alsa-project.org. Retrieved 2012-01-08.
  6. ↑ Linux 2.5.5 release notes, retrieved 2012-01-08
  7. ↑ OSS Emulation, archived from the original on 2012-06-05, retrieved 2012-07-07
  8. ↑ "Alsa-project/Alsa-tools". GitHub. 3 April 2022.
  9. ↑ "Alsa-tools - ALSA wiki". alsa.opensrc.org. Archived from the original on 18 March 2008. Retrieved 12 January 2022.
  10. ↑ "ALSA User Info - AlsaProject".
  11. ↑ "Alsa-utils". GitHub. 4 May 2022.
  12. ↑ "Category:Alsa-utils - ALSA wiki". alsa.opensrc.org. Archived from the original on 18 March 2008. Retrieved 12 January 2022.
  13. 1 2 "How to Use ALSA Utilities to Manage Linux Audio from the Terminal". 14 May 2018.
  14. 1 2 "AlsaMixers - ALSA wiki". alsa.opensrc.org. Archived from the original on 4 April 2008. Retrieved 12 January 2022.
  15. 1 2 3 boer, maarten de. "maarten's homepage". iua.upf.es. Archived from the original on 2006-09-04. Retrieved 18 July 2021. this page will contain a list of my projects, but i need to clean up some things first. for now, use the following links, or browse the ftp: tapiir, alsamixergui, aconnectgui, polarbear
  16. ↑ Boer, Maarten de. "AlsaMixerGui". Music Technology Group. Barcelona: Universitat Pompeu Fabra. Archived from the original on 2009-02-05. Retrieved 18 July 2021. alsamixergui is a FLTK based frontend for alsamixer. It is written directly on top of the alsamixer source, leaving the original source intact, only adding a couple of ifdefs, and some calls to the gui part, so it provides exactly the same functionality, but with a graphical user interface. (Researcher, 1999-2010)
  17. ↑ Tranter, Jeff (October 2004), "Introduction to Sound Programming with ALSA", Linux Journal, retrieved 2012-01-08
  18. ↑ Phillips, Dave (June 2005), "A User's Guide to ALSA", Linux Journal, archived from the original on 2012-01-09, retrieved 2012-01-08
  19. 1 2 3 Alsa C library Doxygen documentation, October 2007, retrieved 2012-01-08
  20. ↑ "Linux ALSA sound notes". www.sabi.co.uk. 2008-01-23. Retrieved 2026-09-04.
  21. ↑ Schatz, Volker. "A close look at ALSA" (Text). Retrieved 2026-09-04.
  22. 1 2 "The Perfect Setup | PulseAudio Documentation". freedesktop.org. 2021-05-07. Retrieved 2026-09-04.
  23. ↑ ALSA SoC Layer, kernel.org, 2017-07-13
  24. ↑ "Tips And Tricks - Open Sound System". ossnext.trueinstruments.com.
  25. ↑ "Audio Architecture (QNX 6.4.1)". www.qnx.com.
  26. ↑ "ALSA and libasound.so". www.qnx.com.
[edit]
  • Official website
  • Constable, Mark. "Alsa WIKI". AlsaOpensrcOrg. Archived from the original on 29 March 2002. Retrieved 18 July 2021. Some of the reasons this site remains in existence are, no one from the official ALSA site has ever contributed anything to this site (before the official one existed, this one predates the official wiki by quite a few years), no one has officially or formally suggested a merge, no one else has shown any serious interest in helping to merge them, and most importantly there are a significant number of offsite referers and Google hits that come directly to this site because it's been here for so long.
Various layers within Linux, also showing separation between the userland and kernel space
User mode User applications bash, LibreOffice, GIMP, Blender, 0 A.D., Mozilla Firefox, ...
System components init daemon:
OpenRC, runit, systemd, ...		 System daemons:
polkitd, smbd, sshd, udevd, ...		 Windowing system:
X11, Wayland, SurfaceFlinger (Android)		 Graphics:
Mesa, AMD Software, ...		 Other libraries:
GTK, Qt, EFL, SDL, SFML, FLTK, GNUstep, ...
C standard library fopen, execv, malloc, memcpy, localtime, pthread_create, ... (up to 2000 subroutines)
glibc aims to be fast, musl aims to be lightweight, uClibc targets embedded systems, bionic was written for Android, etc. All aim to be POSIX/SUS-compatible.
Kernel mode Linux kernel stat, splice, dup, read, open, ioctl, write, mmap, close, exit, etc. (about 380 system calls)
The Linux kernel System Call Interface (SCI), aims to be POSIX/SUS-compatible[1]
Process scheduling subsystem IPC subsystem Memory management subsystem Virtual files subsystem Networking subsystem
Other components: ALSA, DRI, evdev, klibc, LVM, device mapper, Linux Network Scheduler, Netfilter
Linux Security Modules: SELinux, TOMOYO, AppArmor, Smack
Hardware (CPU, main memory, data storage devices, etc.)
  1. ↑ "Admin Guide README". Kernel.org git repositories.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Advanced_Linux_Sound_Architecture&oldid=1373115093"