Linux ALSA sound notes

Structure of ALSA and terminology

Takashi Iwai has a nice diagram that illustrates the structure of ALSA.

• The hardware card level
• The kernel module level
• The /proc/asound kernel interface
• The /dev/snd device interface
• The ALSA library level

/proc/asound/cards (RO)
 the list of registered cards

/proc/asound/version (RO)
 the version and date the driver was built

/proc/asound/devices (RO)
 the list of registered ALSA devices (major=116)

/proc/asound/hwdep (RO)
 the list of hwdep (hardware dependent) controls

/proc/asound/meminfo (RO)
 memory usage information
        this proc file appears only when you build the alsa drivers
        with memory debug (or full) option so the file shows the
        currently allocated memories on kernel space.

/proc/asound/pcm (RO)
 the list of allocated pcm streams

/proc/asound/dev/
 the directory containing device files.  device files are created
 dynamically; in the case without devfs, this directory is usually
 linked to /dev/snd/

/proc/asound/oss/
 the directory containing info about oss emulation

/proc/asound/seq/
 the directory containing info about sequencer

/proc/asound/cardX/ (X = 0-7)
 the card-specific directory

/proc/asound/oss/
 info about OSS emulation
 the contents of the files under this directory are changed dynamically.
 when no oss emulation modules (snd-pcm-oss, snd-mixer-oss) are loaded,
 no pcm nor mixer devices will be listed.

/proc/asound/oss/devices (RO)
 the list of devices already registered

/proc/asound/oss/sndstat (RO)
 /dev/sndstat compatible list

/proc/asound/cardX/
  card-specific proc files

id (RO)
 the id string of the card

ac97#? (RO)
 AC97 codec information

ac97#?regs (RO)
 (printable) register dump

midi? (RO)
 the current of input/output on the
 rawmidi device

pcm?p
 the directory of the given pcm playback stream
pcm?c
 the directory of the given pcm capture stream

pcm stream information

pcm??/info (RO)
 the pcm stream general info (card, device, name, etc.)

pcm??/oss (RO)
 oss emulation info (shown only when the pcm is opened
 as an oss device).

pcm??/sub?
 the substream information directory

pcm??/sub?/info (RO)
 the pcm substream general info (card, device, name, etc.)

pcm??/sub?/status (RO)
 the current of the given pcm substream
 (status, position, delay, tick time, etc.)

pcm??/sub?/hw_params (RO)
 hw_params set-up on the substream
 (buffer size, format, etc.)

pcm??/sub?/sw_params (RO)
 sw_params set-up on the substream
 (threshold, etc.)

pcm??/sub?/prealloc (RW)
 the number of pre-allocated buffer size in kb.
 you can specify the buffer size by writing to this proc file:

 # echo 128 > /proc/asound/card0/pcm0p/sub0/prealloc

 to allocate 128kbyte for playback, substream #0, stream #0
 on the card #0.

device files under /proc/asound/dev/ (or /dev/snd/)
generally the file is named as aaaCxDy,
where aaa is the service name,
x the card number (0-7),
y the device number (0-).

controlC? control devices (i.e. mixer, etc.)
hwC?D?  hwdep devices
midiC?D? rawmidi devices
pcmC?D?p pcm playback devices
pcmC?D?c pcm capture devices
seq sequencer device
timer timer device

Configuring applications for ALSA

General principles:

• If the application supports several sound systems, usually choose ALSA instead of OSS, or even a sound daemon like aRts or ESoundD: even if ALSA has an OSS compatibility mode it is more limited than the native ALSA API, and the ALSA library supports software sharing and rate and format conversion, thus making sound servers redundant inasmuch they are used for those purposes.
• If an application only supports OSS output, and there are problems, check the OSS emulation notes.
• if your applications supports OSS or a sound daemon, but not yet the ALSA 0.9/1 API, choose the sound daemon over OSS, as the sound daemon can be configured to use ALSA.
• Of the sound dæmons, such as aRts and ESoundD or JACK usually aRts and EsoundD are used only to provide services already provided by the ALSA library, so they should perhaps be disabled. But JACK is often used with a lot of cute sound processing plugins, so if you use them, keep using JACK.
• Using IEC958/SPDIF output, or direct DVD AC3/... output, is not trivial on many cards. Look carefully for card specific instructions on how to enable this.

There are some other notes here and here.

XMMS

With XMMS, download the ALSA output plugin, then use CTRL-P to get the preferences panel, and in Audio I/O Plugins select the Output Plugin called ALSA 1.x.y output plugin [libALSA.so].
In order to select a particular device click on Configure once the ALSA plugin has been selected, and either select a particular audio device, or type a name, in the Audio device: field. Remember to select the corresponding Mixer card number too.

libao

libao is a library used by many sound applications like for example mpg321. The default sound system for it can be configured by creating or editing the file /etc/libao.conf and ensuring it contains the line default_driver=alsa09.

OpenAL

OpenAL is a library used by many sound applications, in particular games. There are many, mostly buggy, versions of it floating around, some of which just don't support ALSA. Recent ones support ALSA, and there is a version that supports correctly positional/3D sound (this version may have been merged into newer versions of the official OpenAL sources, but I am not sure).
Its defaults are configured by the file /etc/openalrc, which is not awesomely documented, but there is something in the Info file for OpenAL (info openal) in the chapter The openal configuration file, and here is a suitable example:

(define devices                 '(alsa sdl arts esd native null))

(define alsa-device             "dsp0")
(define speaker-num             2)
;(define sampling-rate          22050)

SDL

The SDL library is a simple portability framework often used in games, and part of the framework is an audio portability layer. This is configured using environment variables.
The relevant ones are SDL_AUDIODRIVER which should be set to alsa, and AUDIODEV or SDL_PATH_DSP which should be set to the name of the ALSA audio device, usually default or dsp0.

mpg321 or the proprietary mpg123

These have two parameters to select the sound system and device, -o alsa09 select the ALSA 0.9.x/1.x sound system API, and -a dev selects the device. As to devices try -a plughw:0,0 or -a dsp0 for example. Since both use libao for sound output you can configure the default sound system as in the libao notes.

MPlayer

Configuring MPlayer depends on whether you use the command line version or one of the many GUI interfaces like gmplayer.
With the command line version, use option -ao alsa:device=device to select an ALSA device, usually as -ao alsa:device=dsp0.
To enable AC3 software processing there are some partly erroneous instructions in the MPlayer documentation that state that surround sound can only be obtained with OSS. Probably it is better support with ALSA, selecting a multiple channel device, as in -channels 4 -ao alsa:device=surround40 or -channels 6 -ao alsa:device=surround51 if supported by your card.
With some special options it is possible on some sound card to do AC3 pass-through with ALSA.

XINE

Command line -A alsa to select the ALSA output plugins, or equivalently set audio.driver:alsa in ~/.xine/config and append :device=dmix0 to select a specific output device. Also check a number of settings beginning with audio.device.alsa_ in ~/.xine/config.

VLC

The command line option --aout alsa to select ALSA output, and --alsadev surround51 to select a specific device.

Mozilla, Firefox

Both Mozilla and Firefox only support OSS, so they must be used with OSS ALSA emulation (or perhaps the aoss wrapper). Similarly for most Mozilla and Firefox plugins.

Java

TODO

Flash

TODO

Icecast

From their Available input modules page, an example (the details on that page):

<input>
  <module>alsa</module>
  <param name="rate">44100</param>
  <param name="channels">2</param>
  <param name="device">plughw:0,0</param>
  <param name="periods">2</param>
  <param name="buffer-time">500</param>
  <param name="metadata">1</param>
  <param name="metadatafilename">/home/ices/metadata</param>
</input>

aRts

In theory, since ALSA supports sharing via the library even with cards that don't have hardware sharing or resampling or format conversion, a sound server like aRts is not needed with ALSA. But it may still be useful with older applications that have aRts, OSS or ALSA 0.5 output code, but haven't been yet updated to use the ALSA 0.9 or ALSA 1 API.
The recent versions of the aRts daemon default to the ALSA API, or they can be made to use it explicitly by using the -a alsa option to artsd, and use the -D to select a specific output device, if you are starting artsd on its own.
Usually however aRts is started within and by KDE, in which case you can configure it by opening Control Center, Sound & Multimedia and Sound System. Having done this if you wan to run aRts you click on Enable the sound system in the General tab.
To configure aRts click on the Hardware tab. Under Select the audio device choose Advanced Linux Sound Archictecture. Normally you can enable Full duplex as ALSA supports it, and most cards allow it.
It is often useful, especially with recent chipsets that internally only support 48000Hz data, to click on Use custom sampling rate and select 48000Hz, probably even if the ALSA library is configured to support resampling itself.
To select a specific output device, click on Override device location and put the ALSA device name (for example dsp0 or hw:0,0) in the corresponding field. With cards that do not support hardware mixing make sure to specify the virtual PCM device name that uses the asym, dsnoop and dmix plugins. Usually this should be called something like dsp0 for the same of programs that use that name by default, so try that.

EsoundD

In theory, since ALSA supports sharing via the library even with cards that don't have hardware sharing or resampling or format conversion, a sound server like EsoundD is not needed with ALSA. However like for aRts some applications depends on EsoundD or OSS, and EsoundD is the lesser evil.
The oldest versions of EsounD do not support ALSA at all, old versions only support ALSA 0.5, and only fairly recent versions support ALSA 0.9/1.x.
EsoundD versions 0.2.27 and earlier needed a patch to support ALSA, but the patch was incorporated in versions 0.2.28 and later. However, usually EsoundD is packaged in two different and mutually exclusive versions, one of which supports OSS, the other ALSA, or some variation thereof. For example with Debian the libesd0 package supports OSS and libesd0-alsa supports ALSA.

Timidity

Usually something like timidity -oS -iA is good, where -oS select as output an ALSA PCM, and with -iA Timidity becomes an ALSA soft sequencer. More context in a RoseGarden FAQ.

Doom 3

From version 12.86 Doom3 for Linux supports ALSA natively. A full discussion is provided in this section.

Quake 4

In theory Quake 4 uses the Doom 3 engine so its sound should be similar. However there is some kind of problem with its ALSA support, which manifests itself with error messages like:

snd_pcm_writei short write: 3763 out of 4096

and the only reliable workaround is to switch to the OSS driver API with

quake4 +set s_driver oss

This workaround should no longer be necessary starting with the 1.3 patch.

Common tasks with ALSA (060502)

arecord -D plughw:0,0 -f S16_LE -c 2 -r 22050 record.wav

OSS emulation (051101)

Takashi Iwai has written some important notes on OSS emulation.

In general OSS emulation relies on either the OSS compatibility devices, or the aoss wrapper that redirects sound to the ALSA devices instead.

This wrapper defaults to using the dsp0 virtual PCM defined in the ALSA library configuration. This can be changed by setting the ALSA_OSS_PCM_DEVICE environment variable. The ALSA_OSS_DEBUG can be set to enable some debugging messages.

A newer and somewhat more flexibile and complex method is oss2jack which creates some virtual OSS devices that are fronts for the JACK. sound server.

Some common issues:

Even if ALSA is installed, some applications are still using the OSS interface

This can be checked with a command line like:

lsof | egrep '/dev/(sound|dsp|mixer)'

If there are applications listed that still use the OSS interface, please configure them to use the ALSA interface.

OSS applications don't share the sound card

By default the OSS compatibility devices respect POSIX rules and allow only exclusive opens unless the O_NONBLOCK option is given to open(2). This can be worked around either by using the aoss program, oss2jack, the non-block configuration directive, or the nonblock_open options of the snd-pcm-oss modules.

OSS applications that only use mmap mode

Some OSS applications, notably Quake and other games, access the OSS compatibility devices in mmap mode, thus bypassing the ALSA library. Check the mmap related options in the /etc/asound.conf file syntax, and the direct and disable options to the OSS compatibility PCM device control device, for example /proc/asound/card0/pcm0p/oss.

OSS applications sound bad at higher sample rate or widths

This can be due to fragment size limits in the underlying chipset: several chipset have a limit of 4096 bytes, and any fragments larger than this get truncated. You can set explicitly the fragment size by writing the appropriate options to the OSS compatibility PCM device control device, for example /proc/asound/card0/pcm0p/oss.

The major applications that still only support OSS are Mozilla and Firefox and the Flash and Java browser plugins, and several older games.

But newer versions of the Flash plugin also support EsounD, which is far preferable in most situations as it allows for sharing.

Sharing a device

It is often desirable to be able to share a sound card among several processes running at the same time.

This requires the ability to mix the sound outputs of those processes into a single stream, that is multiplexing.

In order to achieve this with ALSA there are several different cases and techniques.

The cases depend on whether the sound card/chipset supports hardware mixing or not, and whether the processes access the sound card/chipset via the ALSA library, a sound server or OSS emulation.

In the beginning OSS often did not support sharing even if it was supported by the hardware. ALSA drivers, as a rule, will support sharing if the hardware supports it. The ALSA library supports sharing even if the hardware does not support it, but this requires some explicit configuration. For applications that use OSS, the aoss wrapper can make them use ALSA instead, which improves things.

Finally applications that use sound servers like EsounD, polypaudio, aRts, or JACK. most sound servers perform software mixing and support ALSA output.

The individual cases are:

• The card supports hardware mixing.
• The card does not support hardware mixing, but all processes accessing it run applications that use the ALSA library.
• The applications use a sound server to access the card.
• The applications use the OSS API to access the card.

# The top level shared pseudo device, with both PCM and CTL interfaces
# The device names "default", "dsp0", "mixer0" have conventional meanings.

# The top level shared pseudo device, with both PCM and CTL interfaces
# The ALSA default is "!default", but many programs like XMMS and aoss
# assume "dsp0" as default name for PCM and "mixer0" for CTL.

# Amazingly, XMMS has problems if one defines 'pcm.dsp0' to be
# 'plug' for 'pcm.asym0' and not directly as 'asym0'.

pcm.!default            { type                  plug;
                          slave.pcm             "dmix0"; }
ctl.!default            { type hw; card 0; }

pcm.dsp0                { type                  plug;
                          slave.pcm             "dmix0"; } 
ctl.dsp0                { type hw; card 0; }
ctl.mixer0              { type hw; card 0; }

########################################################################

# Buffering (period time defaults to 125000 usecs).

# Size of period, expressed either in usec or byte units:
#   period_time USECS
#   period_size BYTES

# Size of buffers, expressed either in period, usec, or byte units:
#   periods     PERIODS
#   buffer_time USECS
#   buffer_size BYTES

# The ALSA docs have examples with 'period_time' set to 0,
# when 'period_size' and 'buffer_size' are used instead,
# but this can cause trouble in later releases of ALSA.

# For OSS compatibility, 'period_size' and 'buffer_size'
# should be powers of 2. Also, many cards cannot accept
# a 'period_size' much greater than 4096, so 4096 is safe.
# On my VIA 8233A, any value for 'period_time' greater than
# 85333 usecs (precisely!) causes hiccups in sound output.
# Why? At 48kHz, 85333 usec are are just over 4096 bytes/channel.

pcm.dmix0               { type                  dmix;
                          ipc_key               13759;

                          slave.pcm             "hw:0,0";
                          slave.channels        2;

                          slave.rate            48000;
                          slave.period_size     4096;
                          slave.buffer_size     16384;

                          slave.period_time     84000;
                          slave.buffer_time     340000;

                          # Map only the first two channels
                          bindings.0            0;
                          bindings.1            1; }

# The top level shared pseudo device, with both PCM and CTL interfaces
# The ALSA default is "!default", but many programs like XMMS and aoss
# assume "dsp0" as default name for PCM and "mixer0" for CTL.

# Amazingly, XMMS has problems if one defines 'pcm.dsp0' to be
# 'plug' for 'pcm.asym0' and not directly as 'asym0'.

pcm.!default		{ type			asym;
			  capture.pcm		"dsnoop0";
			  playback.pcm		"dmix0"; }
ctl.!default		{ type hw; card 0; }

pcm.dsp0		{ type			asym;
			  capture.pcm		"dsnoop0";
			  playback.pcm		"dmix0"; } 
ctl.dsp0		{ type hw; card 0; }
ctl.mixer0		{ type hw; card 0; }

########################################################################

pcm.asym0		{ type			asym;
			  capture.pcm		"dsnoop0";
			  playback.pcm		"dmix0"; }

pcm.dsnoop0		{ type			dsnoop;
			  ipc_key		13758;
			  slave.pcm		"hw:0,0"; }

mpg123 name.mp3 -w name.wav

aplay -D dsp0 name.wav

aplay name.wav

mplayer -ao alsa1x:dsp0 name.avi

So, now is the time to test all your desired alsa apps to work with this setup.

• Some will need to be told explicitly to use dsp0.
• Others will happily use the default.

If some ALSA apps behave badly with dsp0 (crackles, stutter), check the dmix plugin configuration page. It has quite a bit of troubleshooting. Tips: look at the samplerates of the slave, maybe play with the period_size parameter, etc.; in particular many cards have limits on the period_size, usually to 4096 bytes.

Some applications use mmap'ed audio data transfer. If your application complains about not being able to use mmap, then play around with the mmap_emulation setting in the pcm.dsp0 definition.

Some applications and/or some cards will simply not work in mmap mode, so try disabling it.

Potential sound quality issue checklist

Sound hardware depends on particularly tight realtime constraints, and this can give rise to a number of issues.

Sound hardware is often also designed and manufactured without much care, especially in the case on motherboard chipsets.

There can be in particular many sound quality issues related to latency, and these are discussed in a separate document on Linux sound latency issues.

The sound quality HOWTO also has a lot of advice on quality issues.

These are issues that are generally possible, and not necessarily related to the specific chipset or sound card used:

BIOS: disable PCI Delay Transaction

For better performance and latency this BIOS setting should be enabled, but there are enough cards that don't support it well that if there are problems one should try to disable it.

BIOS: change IRQ sharing

Ideally your sound chipset should be on a dedicated IRQ, but this is often not possible on a system with many chipsets. Unfortunately some chipsets do not share IRQs well, and it is difficult to know in advance. So experiment with rearranging IRQ assignments in the BIOS, and/or swapping PCI cards around, as IRQs are assigned to slots, not cards as such.
To ensure your explicit IRQ assignments it is probably necessary to disable in the BISO the PnP OS setting (usually a good idea regardless) and to use the kernel boot parameter pci=biosirq.

System: tweaking the PCI latency timers

If your sound is metallic or crackly or slightly distorted perhaps you need to set the PCI latency times of some PCI card to less aggressive values, for example with the command:

setpci -v -s '*:*' latency_timer=20

(but reset the latency timer to 0 for the host bridge, usually with id 00:00.0). There are more details on this in the notes on sound latency. Another possible workaround is adding Option "PciRetry" "true" to the X server configuration.

System: ensure proper MTRR

The MTRR settings for your system can matter greatly to the amount of bus traffic, and this can impact the performance and quality of your sound. Check the plausibility of the contents of /proc/mtrr; main memory should be write-back, and the frame buffer of video cards (at some very high address) should be write-combinining. There are some documents and articles on the WWW that discuss MTRR settings.

System: ensure the ATA/IDE drives are on DMA

If the ATA/IDE drives (usually hard discs) are not using DMA then IO may take a lot of CPU time and this can impact very strongly sound quality. Use hdparm -v to check if DMA is enabled.

ALSA: fragment_size <= 4096

Many cards, in particular of the AC97 sort, have low limits on the size of sound samples they can accept, usually only a few kilobytes. This means that the fragment size for that card should be set to be low. This can be done inside the program writing sound data to the card, but it can also be done by defining a suitable plugin in /etc/asound.conf with the desired fragment size.

ALSA: ensure volume is less than 70%

Many cards have somewhat poor internal mixers and amplifiers, and sound will be distorted at high volume levels. Some cards have problems with too high levels of the master volume, some with too high volumes of the individual channel volumes, some with both. Some will have problems with volume setting higher than 50%, some with setting higher than 65-70%.

ALSA: check the number of channels in /etc/asound.conf

If you specify the wrong number of channels in a virtual device definition the resulting sound can be quite crackly. Some cards for example don't have a 2 channel mode, they just work in 5.1 channel mode.

ALSA: ensure all non necessary inputs are muted

Sometimes the controls for input devices are left unmuted; in theory this should affect the sound, especially if nothing is muted into them. But unmuted recording controls can collect electrical noise which gets mixed into the output. Makes sure that all non necessary input channels are muted; merely setting the capture volume to zero is not enough.

ALSA: use external amplifier and line out

To avoid sound distortion problems it is often a good idea to use an external amplifier, instead of relying on the internal amplifier on the card. Several ALSA drivers allow disabling the internal amplifier by unmuting the control called External Amplifier. If this is not possible or does not work, one can plug the external amplifier into the line-out socket of the card, if any.

ALSA: use external preamp for microphone

There are many, many issues related to mismatches in impedance and other electrical characteristics between microphones and cards. Sometimes recording is better if one uses the Mic Boost control for the microphone channel, but usually quality will not be optimal. If quality is desired, an external microphone amplifier is probably# a lot better.

Troubleshooting (060502)

An important first step: compile the relevant information using aadebug.

Also have a look at the FAQ and the drivers documentation pages (1) for troubleshooting your specific soundcard.

The ALSA tips page might have useful stuff too, and this PDF of a presentation by an ALSA developer contains a number of interesting and important troubleshooting steps and details.

Check that the ALSA drivers are compiled as modules

Make sure you have installed ALSA as modules, and not compiled into the kernel.
ALSA fails for all sorts of reasons when compiled into the kernel (this may no longer be true for kernels after v2.6.5).
Anything that mentions sound in the kernel config, even if it is not directly to do with ALSA, set it's option to M if you can.
If you compile you own kernel: when you configure the kernel, make sure you see M (for module) and not * (compiled into the kernel).

Check the ALSA driver version

Look at /proc/asound/version and that this says something like:

Advanced Linux Sound Architecture Driver Version 1.0.4.

and that the version is 1.0.4 or above.
If it is not, download and compile newer drivers for kernel v2.4, or update your v2.6 kernel to version v2.6.5 or later.
There are several ALSA installation pages on the web, which are usually distribution dependent. . Check the Wiki or documentation pages for your distribution for details.

Check the ALSA library version

How to check your ALSA library version is distribution dependent. Usually, you can use the package (e.g. RPM or DPKG) or dependency manager (e.g. APT, aptitude, synaptic, yum, up2date, YAST2) used by your distribution to check the version of installed packages.
You can also try something like

grep VERSION_STR /usr/include/alsa/version.h

and check that the version is at least 1.0.4, and usually it is best if it matches the driver version.

Check the sound drivers for your card are active

First check that the ALSA drivers are installed and have recognized your card.
Make sure that /proc/asound/cards lists your card, as card number zero. If not, make sure that the appropriate driver module is loaded.
To figure out which modules you need, use the

lspci | egrep audio

command. This usually will list the name and type of your sound chipset. The main ALSA website then contains a list of chipset and corresponding drivers.
As a wild guess, for most recent low cost AC97 based motherboards and laptops, try the snd-intel8x0 driver; for the other common sound card type, the Creative SB Live! range, use snd-emu10k1.
To make sure your card is recognized and the right driver is selected you can also try the alsaconf command, and use it to configure your sound card.
It can also be that the ALSA driver has not been loaded but an OSS driver has been loaded. Check the contents of /dev/sndstat and if it exists and you see your card listed there, and there is no line talking about ALSA emulation, it is being driven by an OSS driver. Unload it and load the ALSA driver.
If you have multiple sound cards, check this item to discover how to configure ALSA to renumber them if the cards are not in the order you would like them to be.

Check that you have the right sound devices

Run alsamixer as root. If you get

alsamixer: function snd_ctl_open failed for default: No such device

the right device special files in /dev/ might be missing. Run ls /dev/snd/ and make sure there are several entries there.
If the directory does not exist, or it is empty, use the ALSA snddevices script or similar to create it and the device special files in it.

Check that non-root users can access the sound device special files

Run alsamixer both as root and as a non-root ordinary user.
If the latter fails, the permissions on the device special files don't allow access by ordinary users.
There are several options to fix this, depending on security requirements, your distribution and how your PC is set up:

• Allow all users read and write access to all sound devices, for example with

  chmod -R a+rwX /dev/snd/.

  This might be slightly insecure.
• Make sure that the sound device files belong to a specific group, they have group read/write permissions, and add all the users that should have access to the sound cards to that group. In many distributions this is the audio or sound group.
• If only one user needs access to the sound card, change the ownership of the sound device files to that user.

Check that the sound card mixer channels are unmuted

If your card's driver is installed and its name appears in /proc/asound/cards, and you still hear no sound, the most likely cause is that you haven't unmuted the right mixer channels and set their volume to nonzero. Note that ALSA sort of misnomes the channels of the mixers of many cards.
Use alsamixer to play around with the settings of the most obvious sounding channels. There are often descriptions of what the channels are in the page about your specific sound cards.
Usually, make sure that the at least the Master and PCM (and Wave or Headphone if present) channels are unmuted and have non zero volume.
For laptop users, try toggling the External Amplifier switch.

The main channels are unmuted and non zero volume, but no sound

Many cards can do both analog and digital (labeled SPDIF/IEC958) output, but some cannot do both at the same time.
If you hear no sound, it may be because the card is in analog mode and you have digital speakers or viceversa.
To determine which mixer channels controls the switch between analog and digital for your card look at the page for your card.
Often this is called Analog/Digital Output Jack. If present, mute/unmute it to switch between digital and analog sound output.

Check whether your application uses OSS instead of ALSA

If you still hear no sound, your application may be set up to use OSS. Check with your applications preferences to see if this is the case. The best fix is to set you application up to use ALSA instead of OSS. If your application does not support ALSA, there are three possible solutions:

• Make it use a sound server that uses ALSA for output.
• Load the OSS compatibility modules for ALSA.
• Use the aoss wrapper to run the application.

There are some other pages on ALSA emulation of OSS (1, 2).

Still no sound with your favourite application

Make sure that it is not a problem with the way the sound application you are using is configured. Try

dd if=/dev/urandom bs=8000 count=1 | aplay -D DEVNAME

to see if you can hear something. If you dont know which DEVNAME you should specify, use plughw:0,0 to test sound card 0 in analog mode, and plughw:1,0 for sound card 1.

Check whether your sound card or application only work with or without mmap

Some sound cards and/or some applications will not work in mmap mode, so try disabling it. Viceversa if it is disabled try to enable it.

Sound can be heard but with an echo

This happens particularly with applications where there is both input ad output, for example voice chat or voice IP ones, and you are using some chipset like the Intel ICH ones.
If this happens it probably happens only with a few chipsets: the cause is that those chipsets allow more than one capture source channel to be specified, usually two, and the two are different.
This can only be checked looking at non simplified controls with amixer, for example with:

amixer cget name='Capture Source'

which might return:

  ; type=ENUMERATED,access=rw---,values=2,items=8
  ; Item #0 'Mic'
  ; Item #1 'CD'
  ; Item #2 'Video'
  ; Item #3 'Aux'
  ; Item #4 'Line'
  ; Item #5 'Mix'
  ; Item #6 'Mix Mono'
  ; Item #7 'Phone'
  : values=0,5

This indicates that there are 8 possible capture channels, and values=0,5 indicates that both Mic and Mix are enabled at the same time. This often is the result of a bug in alsamixer.
If this is not intentional, it is possible to ensure only one channel is enabled for capture by setting both values to the same number, for example for Mic in this case with:

amixer cset name='Capture Source' 0,0

Sound can be heard but it is distorted

• Some cards, notably SB Live! ones, suffer from distortion if the volume on some subchannels is higher than 66%. Some suffer distortion if the Master volume is higher than 66%, for some others the threashold is 50%. Reduce all volume setting. If the distortion goes away, experiment until you determine which are the highest volume settings that don't trigger distortion.
• Some cards, especially motherboard chipsets, have small limits on the fragment size (specified for example in the dmix plugin configuration. Many cards cannot handle fragment sizes greater than 4096 bytes, and if it is bigger the fragment seems to be truncated and the sound becomes choppy.
• Some cards, especially recent ones, can only handle a fixed set of frequencies. Some can only handle a single frequency, usually 48000Hz. try to use the plug: plugin prefix (as in, for example: plug:default when playing. If your card can only play a single fixed frequency you must ensure that the driver is told that (by the use of driver-specific option parameters), and the ALSA library is setup up to output sample only at that frequency. Usually this will involve using the plug plugin in /etc/asound.conf.
• Choppy sound can also be due to IRQ issues, in particular with recent systems that have an ACPI BIOS and a Linux kernel with ACPI support. Try adding acpi=off to the linux kernel boot arguments

Also see the potential sound quality issue list section in this document.

You can hear stereo sound from the front speakers, but not from the other speakers

The default ALSA output virtual device is 2 channel only. In order to hear sound on more than two speakers you need to use the name of a virtual device that supports more than two channels.
These virtual device names begin with surround; the most commonly used are surround40 and surround51. To get a full list of those defined for your card run:

aplay -L 2>&1 | egrep surround

For some cards, in particular USB based cards, ALSA does not (yet?) define any surround style virtual device names, in part because these cards usually only work in surround mode, accepting for example only 5.1 channel samples.
Note that if you play 2 channel sound to a surroundNN device, you will still hear only the front speakers. This is as it should be.
If you want to artificially spread the 2 channel sound onto more channels you need to create a special virtual device in the /etc/asound.conf file to do that using the route plugin. There are several examples of this in this sample asound.conf file (additional notes: 1, 2).

You can hear sound coming from the front and rear speakers, but not from the other speakers you have

This may be because your sound has fewer channels than you have speakers, for example because you are playing 4 channel sound onto a 5.1 channel speaker system. In this case there is no problem, things are working as they should.
But it can be because your card uses the same sockets for some input and output channels. Often the Line in socket is also used for the LFE output channel and the Mic socket for the Center output channel, or viceversa. If this is the case you must use the appropriate toggles in the mixer controls to ensure that those sockets are used for output and not input.
In order to test that all speakers work you can use multiple channel sound files or use the speaker-test utility, which has been included in the alsa-utils package for a while now.

Things work except when you use a device for sw sharing, one that relies on the dmix plugin

This can be due to the kernel lacking the SystemV compatible shared memory implementation. Make sure the kernel has it.

References (091115)

• ALSA project home page.
• ALSA unofficial Wiki.
• Some ALSA notes similar to these with a more tutorial attitude.
• nice diagram that illustrates the structure of ALSA.

Colophon

This document is the result of many hours spent:

• Trying to figure out ALSA for my own system, using my VT8233A, SB Live!, CMI8738, and CS4261 chipset and cards that I have used at various times. Thanks to Creative in particular for half-assedly designing my SB Live!, despite their immense corporate resources, and thus leading me to investigate the many pointless absurdities of this range of cards.
• Helping often hapless, lazy, and irritating people in the #ALSA channel on Freenode, thanks to them for showing me what are the most common issues and misunderstandings with ALSA.

Thanks to the ALSA authors for writing the software, which is after all a huge improvement on OSS, and thanks to them also for under-documenting and over-complicating it gleefully probably to protect their own jobs and their employer from competition (really?), and thus giving me the motivation to spend a lot of time, that maybe I could have spent more usefully, trying to collate obscure hints here and there, reverse engineering the sources, and experimenting, to gather the information condensed in these notes.

Thanks to <peer> for the pointer to the chipset docs of the SB Live!.

Thanks to <hermanro> for the pointer to the RoseGarden FAQ on soft sequencers.

Thanks to the fellow sufferers and inmates of the ALSA asylum, those who have scratched on the walls of their cells their horror stories, painful discoveries and hints for those that would come after them.