A User's Guide to ALSA

Full details regarding installation are available on the ALSA home page (see the on-line Resources), so I mention here only a few details and clarifications. If you're using a distribution or customized Linux system based on a 2.6 kernel, ALSA already is installed. Distros and systems based on earlier kernels require a manual ALSA installation.

Installing ALSA is not especially difficult, and the way has been cleared at least partially by packages supplied by audio-centric Linux distributions/bundles, such as AGNULA/Demudi for Debian, PlanetCCRMA for Red Hat and Fedora and AudioSlack for SlackWare. Mandrake users can install one of Thac's packages (see Resources). Regardless of your base system, you must uninstall the OSS/Free modules before installing the ALSA package. Normally this task entails little more than moving the older modules into a temporary directory, in case you want or need to put them back, and making sure that the kernel's soundcore.o object file remains in its original place, usually /lib/modules/your-kernel-number-here/kernel/drivers/sound/. After removing OSS/Free you need to install the ALSA packages by way of your package manager of choice.

ALSA configuration has improved greatly over the years, but it still can be a tricky procedure, especially if your system has more than one sound device or if the device is connected to your computer on the USB or PCMCIA bus. Obviously, I can't go into the details regarding every possible configuration, but fortunately the ALSA Web site contains a large number of configuration pages for supported devices, often including tips and tricks from other users.

Basic configuration can be done with the alsaconf utility (Figure 1). alsaconf works well at recognizing single devices, but it might not do so well with systems containing multiple devices. Don't worry; it's still fairly simple to accommodate multiple audio and MIDI devices, and we return to that task in a few moments. For now, let's proceed as though you have only one audio device for your machine.

Figure 1. The alsaconf configuration tool is good for finding sound hardware on systems with one sound card installed.

After alsaconf has set up basic support for your sound device, you need to activate its playback and record channels. By default, ALSA started with all channels of your device muted. It may be an annoyance for some users, but it certainly reduces the likelihood of inadvertently blowing up your speakers when you first start your new system. You can set your sound device's channel capabilities with ALSA's alsamixer utility, a character-graphics mixer complete with sliders and switches for each channel of the detected device (Figure 2). Use the arrow keys to select a channel, use the <> keys to unmute/mute channels, and use the spacebar to select a channel as a recording source (capture, in ALSA-speak). When you've set your mixer preferences, run the alsactl utility to save and recall your settings (alsactl store|restore).

Figure 2. By default, ALSA starts with sound muted, so you need to set audio channel values with alsamixer.

As you already can see, ALSA thoughtfully provides a number of useful tools to help configure the system. If you want to know more details about using those tools, simply run the utility with the -h option or use the man command to see a more detailed description. The following examples display the manual pages for the utilities I've mentioned already:

Now that we've considered some of the basic installation and configuration details, let's look at how we might set up a more complicated system. For the following example, I've used the configuration details for my laptop system, a Pentium II 366MHz HP Omnobook 4150 with a combined audio/video chipset manufactured by NeoMagic.

Setting up laptop audio support under Linux can be a complicated task, and it just so happens that my hardware is slightly problematic. Thankfully, ALSA supplies the tools I needed to resolve my difficulties with finding the correct chip and driver identification.

The alsaconf utility tries to identify your system's audio and MIDI capabilities and then it writes a basic configuration file to /etc/modules.conf. However, in the weird world of laptop sound support, things may not always be what they seem. For example, alsaconf correctly identified my laptop audio chip as a NeoMagic NM256. However, the configuration failed, reporting that I should use either the basic SoundBlaster16 driver (sb16) or one of the Crystal Sound drivers (cs423x).

On the advice of ALSA guru Takashi Iwai, I tried using alsaconf to set up the driver for the CS4232 chipset features, selecting the cs4232 module from alsaconf's list of non-PnP ISA chipsets. When I chose to probe for all possible DMA and IRQ settings, my machine locked up, freezing the keyboard and forcing a power-down and cold boot. To be fair, I must mention that alsaconf warned me that might happen. Happily, when I rejected the more aggressive search, alsaconf completed its task gracefully and added the following section to my /etc/modules.conf file:

	# --- BEGIN: Generated by ALSACONF, do not edit. ---
	# --- ALSACONF version 1.0.4 ---
alias char-major-116 snd
alias snd-card-0 snd-cs4232
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss
alias snd-card-1 snd-virmidi
alias sound-slot-1 snd-card-1
	# --- END: Generated by ALSACONF, do not edit. ---

Alsaconf merely set up a series of aliases for the general and card-specific services ALSA can provide for my machine. For normal use this section should remain as alsaconf generates it. By the way, the entries for the virmidi modules are there because I'm running Red Hat 9 with the ALSA packages from PlanetCCRMA, a suite of components for setting up a low-latency, high-performance Linux audio/MIDI workstation. PlanetCCRMA installs the virtual MIDI modules by default.

Next, I edited the driver options in /etc/modules.conf. In this section, I can customize various features of my sound chip, setting I/O port and IRQ addresses, enabling or disabling onboard synth capability and defining the DMA channels.

I ran alsaconf -P to see a list of the legacy non-PnP modules:

# alsaconf -P
opl3sa2 cs4236 cs4232 cs4231 es18xx es1688 sb16 sb8

Next, I probed the CS4232 driver for its default options settings:

# alsaconf -p cs4232
port=0x534 cport=0x538 isapnp=0 dma1=1 dma2=0 irq=5

I could have accepted these values and had a working audio system, but thanks again to Takashi Iwai, I discovered that I also could enable an onboard synth chip, the Yamaha OPL3, an inexpensive 4-operator FM synthesizer notorious for its ubiquity in inexpensive sound cards and its general cheesiness of sound. Takashi also advised entering and disabling an option for a physical MIDI port, simply to indicate its presence as a chipset feature. Thus, my current options section in /etc/modules.conf now includes this more complete configuration for the CS4232:

options snd-cs4232 port=0x534 cport=0x538 mpu_port=-1
↪fm_port=0x388 irq=5 dma1=1 dma2=0 isapnp=0

With this configuration, I now have working audio I/O and a cheesy onboard FM synthesizer. However, the synthesizer needs a set of sound patches before it can make any sound, and of course ALSA supplies the needed utility (sbiload) to load the patch data into the synth—ALSA even supplies the patches. I use the loader as follows:

sbiload -p 65:0 --opl3 \
/home/dlphilp/soundfiles/sbi-patches/std.o3 \
/home/dlphilp/soundfiles/sbi-patches/drums.o3

The options include the required target port (determined with aconnect -o) and a switch for either OPL2 or OPL3 support; the OPL2 is only a 2-operator FM synth. The example's patches are included with the ALSA tools (see locate *.o3 and locate *.db for locations). A few other patch sets for the OPL3 are available on the Internet, and Patch editors also are available.

At this point, I opened alsamixer to set the channel status for the CS4232. Figure 2 shown above displays the results. I now could play OGG and other music files (PCM), listen to my music CDs (Aux1) and watch and listen to DVDs and other video formats (Aux). I could record analog audio through either a microphone input or line-in jack, and I even could listen to MIDI music files played by the soundchip synth (Aux1). By default, I can do only one of those activities at a time, but ALSA supplies a neat plugin for software mixing, which I describe later.

By the way, on Red Hat or Fedora the entire ALSA system can be started and stopped with these commands:

/etc/init.d/alsasound start
/etc/init.d/alsasound stop
/etc/init.d/alsasound restart

If you have installed the Debian packages, the file is /etc/init.d/alsa. This feature makes it easy to test new configurations. The exact location of the alsasound control can be determined with locate alsasound.