The Full Wiki

More info on Advanced Linux Sound Architecture

Advanced Linux Sound Architecture: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

Alsa v1.0.14 ubuntu7.1 en.png
Screenshot of Alsamixer 1.0.14
Original author(s) Jaroslav Kysela
Developer(s) ALSA team[1]
Initial release 1998
Stable release / 2009-12-28; 17 days ago
Written in C[2]
Operating system Linux
Type Audio
License GPL and LGPL

Advanced Linux Sound Architecture (known by the acronym ALSA) is a Linux kernel component intended to replace the original Open Sound System (OSS) for providing device drivers for sound cards. 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, goals which it has largely met. A couple of different frameworks, such as JACK, use ALSA to allow performing low-latency professional-grade audio editing and mixing. Led by Jaroslav Kysela, the project started from a Linux device driver for the Gravis Ultrasound sound card 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).[3] In the 2.6 version it replaces OSS by default, although a backwards-compatibility layer exists.



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

To provide these features cleanly, ALSA has a bigger and more complex API than OSS, so it can be harder to develop applications that use ALSA as their sound technology. However, ALSA also provides an optional OSS emulation layer, so the simpler and more portable OSS API can be used.

Besides the sound device drivers, ALSA bundles a user space library for application developers who want to use driver features with a higher level API than 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 which is as similar as possible across disparate hardware. It does this in part by using software plugins. For example, many modern soundcards or built-in sound chips don't have a "master volume" control; for these devices the user space library provides a software volume control instead using the "softvol" plugin, and ordinary application software needn't care about the difference.


This section provides an overview of basic concepts pertaining to ALSA[4][5][6][7].

Typically, ALSA supports up to eight cards numbered 0 through 7. Each card is a physical or logical kernel device capable of input, output or control of sound and can also be addressed by its id which is an explanatory string such as Headset or ICH9. If a card is omitted, it means card 0, that is the default card where most sounds are played and which is determined by the operating system. Cards have devices numbered starting at 0. A device can be of playback type, meaning it outputs sound from the computer, or other type such as capture, control, timer, or sequencer. If a device is omitted, it means device 0. A device can have subdevices numbered starting at 0 that represent for example a speaker pair or some other relevant sound endpoint for the device. If the subdevice is -1 or omitted, it means any available subdevice. The interface is a description of an ALSA protocol for access, such as hw, plughw, default, and plug:dmix. The hw interface provides direct access to the kernel device, however, no software mixing or stream adaptation, while plughw or default enables sound output where the hw interface would produce an error.
An application typically describes sound output combining all of the previous information in a device string, in a form such as interface:card,device,subdevice or interface:CARD=1,DEV=3,SUBDEV=2. The device string is case sensitive.
An ALSA stream is a data flow representing sound. The most common stream format is PCM and its encoding must match that of the hardware or sound will not play. Parameters are sampling rate which is 44.1 kHz on home stereos, and 48 kHz on home theaters, a sample width measured in bits, such as 8, 16, 24 or 32, a sample encoding, a number of channels, 1 for mono, 2 for stereo, or 6 for AC-3/IEC958, and ALSA also need buffer parameter that determines how often CPU attention is required.

See also


  1. ^ - Alsa Team
  2. ^ Ohloh Analysis Summary - ALSA
  3. ^ Linux 2.5.5 release notes
  4. ^ Tranter, Jeff (October 2004). "Introduction to Sound Programming with ALSA". Linux Journal. Retrieved 2007-12-01.  
  5. ^ Phillips, Dave (June 2005). "A User's Guide to ALSA". Linux Journal. Retrieved 2007-12-01.  
  6. ^ "HOWTO ALSA Complete (includes dmix)". July 2004. Retrieved 2007-12-01.  
  7. ^ "Alsa C library Doxygen documentation". October 2007. Retrieved 2007-12-01.  

External links

Got something to say? Make a comment.
Your name
Your email address