On the ALSA Web site, you read that ALSA stands for the Advanced Linux Sound Architecture. Normal users normally don't think about such things as sound architectures, so before I say more about ALSA and why it's advanced, I must present a brief description and history of the Linux sound architecture.

A sound architecture may provide a variety of audio-related functions, but it must include at least a low-level connection between the soundcard driver and kernel services and a higher-level audio software programming interface to simplify applications development. Until the 2.5.x development track, the Linux kernel utilized an audio API now known as OSS/Free. OSS here stands for Open Sound System, an audio API originally written in 1992 by Hannu Savolainen. Independent developers contributed drivers and other work to the OSS/Free system, but by the late 1990s the OSS API was showing its age. Around that time, a Czech system administrator named Jaroslav Kysela began work on what eventually became the ALSA project. Like Linux itself, ALSA began with rather modest goals: Jaroslav simply wanted more out of his Gravis UltraSound soundcard than the existing API could deliver, and he was willing and able to meet the demands of the task. Like Linus Torvalds, Jaroslav eventually found himself at the center of a group of talented developers, all dedicated to the development of a superior audio API for Linux.

ALSA's features and popularity grew to a point when users and developers began lobbying for utilizing ALSA to replace the OSS/Free system packaged with the kernel sources. Testing began with the 2.5.x development kernels, and from the 2.6.x kernels onward ALSA has been the default Linux sound architecture.

As mentioned, ALSA's developers have concerned themselves with designing a truly superior sound system for Linux. On the ALSA Web site we read this description of the project's most significant features:

This article is not intended to be a guide to installing or programming ALSA, nor does it describe every feature. I merely consider the features in the list above rather generally and briefly describe how I take advantage of ALSA on my own system.

For most normal users, perhaps the first and most important question is "Does ALSA support my soundcard ?" Linux support for audio hardware has been problematic due to the unwillingness of many manufacturers to provide either drivers or the specifications from which Linux drivers could be written. Notable exceptions have occurred, however, and by now ALSA supports many of the most popular soundcards and audio boards, including hardware from Creative Labs, RME and M-Audio. ALSA's driver support extends to serial and parallel port interfaces as well as to PCMCIA and USB hardware. ALSA even goes beyond hardware, providing a dummy driver and a most useful virtual MIDI driver. See the ALSA Soundcard Matrix for the current list of supported cards and chipsets.

Figure 1. The alsaconf Soundcard Configuration Utility

Mainstream Linux distributions try to identify and install the correct driver for your soundcard during the configuration stage of an initial installation. Usually a standalone sound configuration utility is included for tweaking beyond the original installation. ALSA provides alsaconf (see Figure 1), which is fine for simple card configurations, but it's not so good with systems having multiple cards, nor does it handle loading the virtual or dummy drivers. Fortunately, it's a simple matter to load and unload ALSA drivers (more about that in the following section).

I've used ALSA with quite a variety of soundcards. My current systems (desktop and laptop) enjoy ALSA support for an SBLive and a PCI128 on the desktop machine and a CS4232 audio chipset on my laptop. The external MIDI hardware is active on the soundcards, the EMU10k1 synthesizer is fully operational on the SBLive and both machines employ the virtual MIDI module. I also have a Core Sound PDAudio-CF PCMCIA card working nicely with the laptop and ALSA driver, giving me an excellent digital audio interface for that machine.

Prior to the 2.6.x kernel series you had to build and install the ALSA system yourself, after which you could make the necessary arrangements to load the modules and make any necessary additions to /etc/modules.conf. Loading the modules is accomplished either by replacing the OSS/Free kernel modules tree with the ALSA tree or by using a script that loads and/or unloads them manually. For example, I use the following script to load the ALSA drivers for the kernel 2.4.18 sound system on my laptop:

  echo "Installing ALSA..."
  modprobe snd-cs4232             # load CS4232 module
  modprobe snd-seq                # load ALSA sequencer module
  modprobe snd-pcm-oss            # load OSS/Free PCM compatibility module
  modprobe snd-mixer-oss          # load OSS/Free mixer compatibility module
  modprobe snd-virmidi            # load ALSA virtual MIDI module
  sbiload -p 65:0 -4 /etc/std.o3  # load 4-operator patches into OPL3 (using ALSA's sbiload utility)
  echo "ALSA installed !"

This method is not typical, though. Usually you simply install the drivers and reboot. The modules are probed during startup; they're installed in the /lib/modules/2.x.x tree. I sometimes need to switch between OSS/Free, OSS/Linux and ALSA on the laptop, hence the script above.

The ALSA mixer mutes all channels by default. You must unmute and set channel values with a software mixer (alsamixer) and then run alsactl store. Also, add this command to your .bashrc or other shell startup script to recall the stored settings, alsactl restore.

ALSA's modularity also provides the ability to configure low-level driver module parameters. The normal user may not have much use for this feature, but it can be a show-saver in some instances. For example, my laptop's on-board audio is handled by Crystal Semiconductor's CS4232 chipset. ALSA supplies a module for that chipset, so I installed it but got no joy. After some queries to ALSA guru Takashi Iwai, I added this line to my /etc/modules.conf file:

	options snd-cs4232 snd_port=0x534 snd_cport=0x538 snd_mpu_port=-1
	snd_fm_port=0x388 snd_irq=5 snd_dma1=1 snd_dma2=0

This information defined the card capabilities with values similar or identical to those found in the laptop's BIOS. The BIOS reported a slightly different value for the base sound port (snd_port), but Takashi verified the correct base address for the audio port in this hardware is indeed 0x534. There is no MPU MIDI interface hardware (snd_mpu_port=-1), but all other option values are unchanged from those found in the BIOS.

With these modules loaded, my laptop has PCM and CD sound services, along with an OPL3 FM synthesizer and support for applications requiring the legacy OSS/Free API. The virtual MIDI module gives me access to a virtual second soundcard with four virtual MIDI ports that can be accessed like true MIDI hardware.

I'm going to stretch the definition of modularity here and include ALSA's PCM plugin layer. These plugins extend the capabilities of PCM devices, providing amenities such as sample rate conversion and direct mixing of multiple audio streams. The .asoundrc file is where you can optimize these plugins for use by ALSA-aware applications. For example, here's my $HOME/.asoundrc file :

  pcm.dsp0 {
      type plug
      slave.pcm "dmix"
  }

  ctl.mixer0 {
      type hw
      card 0
  }

  pcm.ladspa {
          type ladspa
          slave.pcm "plughw:0,0";
          path "/usr/lib/ladspa";
          plugins [
                  {
                   label delay_5s
                   input {
                          controls [ 0.8 0.3 ]
                   }
                  }
          ]
  }
 

Thanks to this configuration my laptop can play multiple audio streams simultaneously on my laptop (impossible without dmix). I can add a five-second delay to any of those streams too by using a pre-defined LADSPA plugin. The following series of commands launches three sound players, all routed through dmix's software mixer, with one stream treated by the LADSPA delay line:

  alsaplayer -o alsa -d plug:dmix Natacha_Atlas-I_put_a_spell_on_you.mp3" &
  aplay -Dplug:dmix -Dplug:ladspa ~/Basil_Bunting.wav &
  alsaplayer -o alsa -dplug:dmix Albert_King-Born_Under_A_Bad_Sign.mp3 &

This example makes quite a noise, but in some situations multiple audible streams can be desirable. More to the point, it's often desirable not to shut down one stream in order to hear another. The dmix plugin resolves this problem nicely.

Some cards require explicit configuration by way of .asoundrc. Check the informative ALSA Wiki for more information about customizing that file.

ALSA is SMP-friendly, which is good news for those Ardour users who own dual and multi-processor machines. Alas, I'm not one of the lucky ones, so I have no personal account of ALSA's performance on SMP boxes. But, the absence of complaints about it on the Ardour and ALSA mail-lists seems to indicate that SMP support is transparent and a non-issue.

ALSA complies with the requirements of applications that employ Linux threads. For you non-programmers, threads are a robust means of handling simultaneous data streams within a program. Thus, a program might be designed to carry audio data in one thread while another thread updates the program's GUI, and neither thread impacts the performance of the other. ALSA's threads support ensures that its activities behave nicely in a threaded environment, following the rules and doing the right thing in its process thread even when other processes go wrong. Although not an apparent concern for the normal user, threads are an important aspect of modern audio software design, working behind the scenes to improve an application's performance. ALSA's explicit support for threads benefits developers and users alike.

ALSA's libasound provides library access to your soundcard driver's functions and services. Applications developers have been quick to take advantage of ALSA's features, and the ALSA package itself includes many utility programs based on libasound. I've already mentioned the alsaconf and alsactl programs and the alsamixer GUI soundcard mixer. In the dmix example above, the aplay program is ALSA's command-line soundfile player; arecord is its recording sibling. Other useful ALSA applications include the aconnect MIDI port connection tool, the amidi sysex send/receive utility and the amixer command-line mixer. All of these applications are small command-line programs that access ALSA library functions to perform specific tasks. In addition to being useful programs for normal users, they also provide excellent examples for developers.

Developers can use libasound to access these interfaces:

Each interface has its own unique set of services. For example, the PCM interface handles digital audio, the raw MIDI interface handles MIDI data, the mixer interface manages the channels and other mixer elements and so forth.

The ALSA sequencer interface deserves special attention. MIDI applications designed to take advantage of this interface are registered as ALSA sequencer clients, allowing free and multiple connections between such clients by way of ALSA's aconnect utility. Figure 2 shows off Matthias Nagorni's kaconnect, a GUI that facilitates those connections. Figure 2 also demonstrates multiple inputs on a single destination, a single output source with multiple destinations and the use of the virtual MIDI port to connect to a softsynth.

Figure 2: Matthias Nagorni's kaconnect

Many modern Linux MIDI applications already function as ALSA sequencer clients. I urge developers to consider it as a must-have feature.

As seen in Figure 2, the ALSA library provides an interface to the virtual MIDI driver. This driver provides four virtual MIDI ports that appear to your machine as actual hardware. Thus, I can run MIDI applications on my laptop with no MIDI hardware (ports or synths) simply by selecting a virtual port for output and connecting it to an ALSA-aware softsynth such as ZynAddSubFX or the ALSA Modular Synth.

With the adoption of ALSA as the default Linux sound system, a new world of improved audio resources awaits developers and users. However, since 1992 many excellent sound and music applications have been written for the now-deprecated OSS/Free interface. ALSA wisely provides an OSS/Free emulation layer that acts transparently when a non-ALSA audio application is run. There's no need for the normal user to reconfigure anything; ALSA simply appears as OSS/Free to the running program. Of course, the application doesn't gain the advantages of native ALSA software, but the emulation layer does give extended life spans to many useful programs written for the older API.

In my experience, ALSA's OSS/Free emulation has been excellent. I've yet to encounter an OSS/Free-specific application that didn't work with ALSA. It's quite possible there's one or more ALSA-resistant programs out there, but I personally have yet to discover one.

Many other features can be explored in the ALSA system, but I must end this brief presentation. ALSA documentation is available in the form of UNIX man pages, HTML pages on the ALSA Web site and user reports on the ALSA Wiki. Active mail-lists are available for developers and users, and the ALSA community is responsive to bug reports, polite suggestions and lavish praise.

Lavish praise indeed then to Jaroslav Kysela, Takashi Iwai, Frank van de Pol and all the crew listed on the ALSA Contributors page. Those guys rock, and thanks to them my Linux box rocks too.