Translation(s): English - Français - Italiano - Русский


Put simply, ALSA can be divided into two components: The kernel API that provides access to your sound card for higher-level sound servers and applications, and a userspace library that provides more general functions (like effects, mixing, routing, etc.)

There is no way to "replace" ALSA, with regards to the kernel API. Previously, there was also OSS (Open Sound System), but that's been deprecated for nearly 20 years. The same is not true of ALSA's userspace library, which can be replaced.

A sound server will sit between ALSA and your applications. These will traditionally be PulseAudio (for easy and automatic audio), JACK (for professional-grade low-latency audio), or PipeWire (for any use-case, but is still experimental). A sound server is not necessary as applications can output sound to ALSA directly, but some applications will make use of a sound server's API and require it to be available in order to produce sound. Most infamously, Firefox does not support ALSA directly and instead uses the PulseAudio API, forcing usage of PulseAudio (or a compatibility layer) as well.

PulseAudio will, by default, take control of all ALSA devices and redirect all audio streams to itself. PipeWire, if configured to do so, will use a small subset of the core ALSA functionality in the kernel API to access your soundcard, and handle all other features itself (replacing the ALSA userspace library entirely).

The rest of this article will assume that you are not using an intermediary sound server and that you're using ALSA exclusively. This is very uncommon these days, though it still may be of interest to some. If you're a typical end-user, you're probably more interested in the page for the sound server you're using (likely PulseAudio)

Packages

Loading modules

ALSA should "just work", with udev identifying your hardware and loading the appropriate driver whenever you boot or whenever the audio device is connected, making sound immediately functionable and configurable through utilities such as alsamixer.

Users have sometimes needed to manually initialize ALSA before their sound would work. You would accomplish this by running:

$ sudo alsactl init

Testing

You can test sound output using any player and any audio file. Something traditional would be aplay which is helpfully available in the alsa-utils package, however it only supports uncompressed WAV files. You probably want to use something like mpv instead, which should handle anything, and can still run headless.

There is also a generic white noise file included with ALSA if you don't care about testing fidelity or accuracy using audio (such as music) that you're familiar with, and just want to ensure output works. You can play it with:

$ aplay /usr/share/sounds/alsa/Noise.wav

ALSA has a MIDI implementation in the case that you have any hardware MIDI ports. You can use aplaymidi to play input from one of those ports.

Configuration

You can find ALSA configuration files in the /etc/alsa/conf.d/ directory. A lot of files are already included here by default. Advanced features such as mixing should already be configured with sane defaults. If you want to make changes, add a new file in here.

Using MIDI with ALSA

Using of MIDI (Musical Instrument Digital Interface) virtual or hardware devices with ALSA is described in AlsaMidi article

Troubleshooting

No sound output

If you can't get any output at all, make sure your user is in the "audio" group, then relog. You can add your user to the group by running:

$ sudo adduser yourusername audio

Replacing "yourusername" with your actual username.

Microphone not working

Check in alsamixer:

Try

$ arecord -vv -f dat /dev/null

making sure that your terminal is wide enough to see the horizontal bar of # symbols showing the detected volume (e.g. reduce the font size with Ctrl +). Before the '#' bar, you should see many lines describing your current ALSA settings. Make some loud sounds near the microphone. In response to the sounds, the length of the # bar should oscillate and the number should change. An absence of response confirms that you have a microphone-related problem.

Distinguish microphone hardware failure from a software bug by testing with an alternate install, e.g. Debian on a LiveCD (desktop computer) or Mobian on an SD card (mainline-linux smartphone).

Wrong card used by default

To see what indexes have been assigned to cards, run:

$ cat /proc/asound/cards

The first card that ALSA finds is usually given index 0 and thus is usually the 'default' sound card. If you are unlucky then the first sound card found is one that is not suitable for playing system sounds.

There are two ways to fix this problem.

1. Force the cards to load in a different order, add the following to /etc/modprobe.d/sound:

  options snd-trident index=0
  options snd-usb-audio index=1

This forces the Trident card to be the default (card 0) and the USB microphone to be card 1.

In case both outputs are handled by the same module (e.g. HDMI output and on-board audio) use this instead:

  options snd_hda_intel index=1,0

2. Change the default card by editing /etc/asound.conf or ~/.asoundrc . More info on this Alsa Multiple Cards

No sound after reboot

Does rebooting bypass BIOS and GRUB menu? This could be caused by kexec-tools. It allows the bypass of BIOS during rebooting and prevent proper initialization of various devices. As root, edit file /etc/default/kexec and update LOAD_KEXEC to:

LOAD_KEXEC=false

This will allow your BIOS to properly initialize sound and other devices during every reboot.

Checklist

More information

For more information, check out https://www.alsa-project.org and https://alsa.opensrc.org.


CategoryHardware CategorySound