The Linux 2.6 kernel introduced a number of changes, and one of the largest was the inclusion of an entirely new sound subsystem. The Advanced Linux Sound System, or ALSA, began life as a self-contained project offering an alternative to the Open Sound System (OSS) included in earlier kernels. With ALSA maturing to a 1.0 release during the 2.6 kernel development cycle, it was soon adopted as the official standard for Linux audio.
ALSA has been widely adopted by distributions, but with its built-in OSS emulation, you probably wouldn't even realise you're using it. Learning about ALSA can pay off though, since it improves on OSS in many ways, and has quite a few neat tricks up its sleeve.

The M-Audio Revolution 7.1, a high quality sound card with oodles of outputs

I decided to learn a bit more about ALSA recently when I upgraded my PC. It was the first major upgrade I'd performed in a few years, so I decided to replace just about everything, including the sound card. For years now I've been using a Creative SoundBlaster Live, the de facto standard for Linux gamers due to the driver's solid game support. It also has hardware mixing that lets multiple applications talk to the sound card simultaneously, without the need for a sound server sitting between apps and the card.

I like to dabble in audio production work though, so I decided to upgrade to something with better input and output quality than Creative's efforts. The best option seemed to be the M-Audio Revolution 7.1, with its home theatre-ready outputs and high quality Envy24HT audio processor that handles 24-bit audio at up to 192kHz. It's a very different kettle of fish to the old Live card though, with no hardware mixing and no OSS driver. It was time to read up on ALSA and find out how to make the best of my latest toy.

ALSA infrastructure
Under OSS, sound cards are exposed directly to applications as a series of device nodes under /dev. It's a simple arrangement, and it works quite well in typical setups where a system has a single soundcard with a typical set of inputs and outputs, but it starts to fall short when you need to handle more complex arrangements.

ALSA's layered approach has driver modules building on core subsystems that ease the development work for driver writers. This ALSA kernel layer exposes device nodes through to userspace, much like OSS, but they're not designed to be accessed directly by applications. Instead, developers use libasound the core ALSA library, to access the sound devices in a high-level manner. The standard ALSA tools, including recording, playback, and volume controls, all use the libasound interface as well.

Moving control of the sound devices away from the low-level hardware drivers and in to a centralised library outside of the kernel opens a number of possibilities. ALSA lets you define system-wide and per-user setups that control how the sound from applications is routed through to your sound card, with various possibilities available along the way. Per-user configuration occurs in the "~/.asoundrc" file.

ALSA's design incorporates various functional layers, and supports both OSS and ALSA applications.

Installing ALSA

If you're running a modern distribution, ALSA isn't something you need to install -- it's an integral part of the system, and most distributions now default to using ALSA drivers wherever possible. To check whether or not you're using ALSA, look for installed ALSA kernel modules with lsmod:

lsmod | grep '^snd'

If you're using ALSA, you should see a number of modules listed. One of these, usually the top entry, will be the driver for your card -- in my case, it's snd_ice1724.
For older systems, if upgrading isn't an option, you can download the ALSA drivers and tools from the ALSA website, http://www.alsa-project.org.

Software Mixing
The first thing I wanted to do with my new card was to regain some of the automatic mixing that my Live card performed transparently in hardware. I'd grown quite accustomed to being able to play sound in multiple programs at once, and it wasn't something I was keen on giving up. ALSA can mix multiple channels in software using its dmix plug-in.

Before doing anything, make sure that ALSA is working properly with the default configuration. Find a WAV file to test with, and play it with the 'aplay' command:

aplay test.wav

While it's playing, open another terminal and run the same command. You'll soon notice that without hardware mixing support, the second attempt to play the file fails while the first is still running.
Open the .asoundrc file in your home directory, creating it if you need to, and enter the following configuration:

pcm.swmix {
  type dmix
  ipc_key 313
  slave {
    pcm "hw:0,0"
    buffer_size 4096
  }
}


Save the configuration, and run aplay again, this time telling it to use the swmix device we just created:


aplay -D swmix test.wav


Try it again in another terminal while the first continues to play, and if all has gone well, the second instance should begin to play. If you hear some crackling, you might like to experiment with the buffer_size paramater. Increasing it should improve reliability, but it will also increase latency, which can be a problem when trying to keep audio in sync while watching movies.

If you're happy with your dmix setup, you can tell ALSA to use your new dmix virtual device by default by adding this to your .asoundrc:


pcm.!default {
  type plug
  slave.pcm "swmix"
}