Advanced Linux Sound Architecture

From ArchWiki

The Advanced Linux Sound Architecture (ALSA) provides kernel driven sound card drivers. It replaces the original Open Sound System (OSS).

Besides the sound device drivers, ALSA also bundles a user space driven library for application developers. They can then use those ALSA drivers for high level API development. This enables direct (kernel) interaction with sound devices through ALSA libraries.

Installation

ALSA is a set of built-in Linux kernel modules. Therefore, manual installation is not necessary.

udev will automatically detect your hardware and select needed drivers at boot time, therefore, your sound should already be working. However, your sound may be initially muted. If it is, see #Unmuting the channels.

ALSA firmware

sof-firmware is required for some laptop models (mainly since 2019) because they implement their drivers with firmware provided by the Sound Open Firmware (SOF) project. Checking the journal will provide messages about the missing firmware (see BBS#275577). Also see the list of supported platforms.

The alsa-firmware package contains firmware that may be required for certain sound cards (e.g. Creative SB0400 Audigy2).

ALSA utilities

Install the alsa-utils package. This contains (among other utilities) the alsamixer(1) and amixer(1) utilities. amixer is a shell command to change audio settings, while alsamixer provides a more intuitive ncurses based interface for audio device configuration.

If you need high quality resampling, install the alsa-plugins package to enable upmixing/downmixing and other advanced features.

ALSA and systemd

The alsa-utils package comes with systemd unit configuration files alsa-restore.service and alsa-state.service by default.

These are automatically installed and activated during installation (via package provided symlink to sound.target). The options are as follows:

  • alsa-restore.service reads /var/lib/alsa/asound.state on boot and writes updated values on shutdown, provided /etc/alsa/state-daemon.conf does not exist. As /etc/alsa/state-daemon.conf is not created without a conscious action of the user, it is the default method.
  • alsa-state.service (Re-)Starts alsactl in daemon mode to continuously keep track of, and persist, volume changes, under the condition that the user has consciously created /etc/alsa/state-daemon.conf.

Evidently, both methods are mutually exclusive. You can decide for one of the two approaches depending on your requirements. To edit these units, see systemd#Editing provided units. You can check their status using systemctl.

For further information, see alsactl(1).

User privileges

Local users have permission to play audio and change mixer levels. To allow remote users to use ALSA, you need to add those users to the audio group.

Note: Adding users to the audio group allows direct access to devices. Keep in mind that this allows applications to exclusively reserve output devices. This may break software mixing or fast-user-switching on multi-seat systems. Therefore, adding a user to the audio group is not recommended by default unless you specifically need to.

PulseAudio compatibility

apulseAUR lets you use ALSA for applications that support only PulseAudio for sound. Usage is simply

$ apulse application

OSS compatibility

OSS emulation is the ability to intercept OSS calls and reroute them through ALSA instead. This emulation layer is useful e.g. for legacy applications which try to open /dev/dsp and write sound data to them directly. Without OSS or the emulation library, /dev/dsp will be missing, and the application will not produce any sound.

If you want OSS applications to work with dmix, install the alsa-oss package as well.

Load the snd_seq_oss, snd_pcm_oss and snd_mixer_oss kernel modules. Configure snd_pcm_oss to load at boot.

Unmuting the channels

By default, ALSA has all channels muted. Those have to be unmuted manually.

Unmute with amixer

Unmuting the sound card's master volume can be done by using amixer:

$ amixer sset Master unmute
$ amixer sset Speaker unmute
$ amixer sset Headphone unmute

Unmute with alsamixer

Unmuting the sound card can be done using alsamixer:

$ alsamixer

The MM label below a channel indicates that the channel is muted, and OO indicates that it is open.

Scroll to the Master and PCM channels with the Left and Right keys and unmute them by pressing the m key.

Use the Up key to increase the volume and obtain a value of 0 dB gain. The gain can be found in the upper left next to the Item: field.

Note: If gain is set above 0 dB, audible distortion can become present.

Unmute 5.1/7.1 sound

To get full 5.1 or 7.1 surround sound, you will likely need to unmute other channels such as Front, Surround, Center, LFE (subwoofer) and Side. (Those are channel names with Intel HD Audio; they may vary with different hardware)

Note: Please take note that this will not automatically upmix stereo sources (like most music). In order to accomplish that, see #Upmixing/downmixing.

Enable the microphone

To enable your microphone, switch to the Capture tab with F4 and enable a channel with Space. See /Troubleshooting#Microphone if microphone does not work.

Test your changes

Next, test to see if sound works:

$ speaker-test -c 2

Change -c to fit your speaker setup. Use -c 8 for 7.1, for instance:

$ speaker-test -c 8

If audio is being outputted to the wrong device, try manually specifying it with the argument -D.

$ speaker-test -D default:PCH -c 8

-D accepts PCM channel names as values, which can be retrieved by running the following:

$ aplay -L | grep :CARD
default:CARD=PCH  # 'default:PCH' is the PCM channel name for -D
sysdefault:CARD=PCH
front:CARD=PCH,DEV=0
surround21:CARD=PCH,DEV=0
surround40:CARD=PCH,DEV=0
surround41:CARD=PCH,DEV=0
surround50:CARD=PCH,DEV=0
surround51:CARD=PCH,DEV=0
surround71:CARD=PCH,DEV=0

If that does not work, consult the #Configuration section or the /Troubleshooting page.

Additional notes

  • If your system has more than one soundcard, then you can switch between them by pressing F6
  • Some cards need to have digital output muted or disabled in order to hear analog sound. For the Soundblaster Audigy LS, mute the channel labeled IEC958.
  • Some machines, like the Thinkpad T61, have a Speaker channel which must be unmuted and adjusted as well.
  • Some machines, like the Dell E6400, may also require the Front and Headphone channels to be unmuted and adjusted.
  • If your volume adjustments seem to be lost after you reboot, try running alsamixer as root.

Configuration

The system configuration file is /etc/asound.conf, and the per-user configuration file is ~/.asoundrc. For more information, see .asoundrc articles on the ALSA project wiki and the ALSA unofficial wiki.

Tip: An explanation of ALSA related terminology—interface, card, device (a card is not a device), subdevice, and more—can be found on Wikipedia:Advanced Linux Sound Architecture#Concepts.

Basic syntax

ALSA configuration files follow a simple syntax consisting of hierarchical value to parameter (key) assignments. The syntax is also shown in [1].

Assignments and Separators

Assignments define a value of a given key. There are different assignment types and styles available.

Simple assignment
# This is a comment. Everything after the '#' symbol to the end of the line will be ignored by ALSA.
key = value # Equal signs are usually left out, since space can also be used as a separator.

key value # Equivalent to the example above.

Separators are used to indicate the start and end of an assignment, but using commas or whitespace is also possible.

Separators
# The following three assignments are equivalent.
key value0; key valueN;
key value0, key valueN,
key value0 key valueN

key
value0
	key
valueN

Compound assignments use braces as separators.

Compound assignment
key {	subkey0 value0;
	subkeyN valueN;	}

key.subkey0 value0; # Equivalent to the example above.
key.subkeyN valueN;

For easier reading, it is recommended to use first style for definitions including more than three keys.

Array definition is an alternative syntax to define compound statements. It uses brackets as separators. The keys are automatically generated as numbers, starting with zero.

Single array
key [	"value0";
	"value1";	
	"valueN";	]

key.0 "value0"; # Equivalent to the example above.
key.1 "value1";
key.N "valueN";

Everything depends on user preferences when it comes to different styles of configuration; however, one should avoid mixing different styles. Further information on basic configuration can be found in [2].

Data types

ALSA uses different data types for parameter values, which must be set in the users respective configuration file. Some keys accept multiple data types, while most do not.

See the PCM (digital audio) plugins page for a list of PCM plugin configuration options and their respective type requirements.

Operation modes

There are different operation modes for parsing nodes, the default mode is merge and create. If operation mode is either merge/create or merge, type checking is done. Only same type assignments can be merged, so strings cannot be merged with integers. Trying to define a simple assignment in default operation mode to a compound (and vice versa) will also not work.

Prefixes of operation modes:

  • + — merge and create
  • - — merge
  • ? — do not override
  • ! — override
Operation modes
# Merge/create - If a node does not exist, it is created. If it does exist and types match,
# subkeyN is merged into key.
key.subkeyN valueN;

# Merge/create - Equivalent to above
key.+subkeyN valueN;

# Merge - Node key.subkeyN must already exist and must have same data type
key.-subkeyN valueN;

# No override - Ignore new assignment if key.subkeyN node already exists
key.?subkeyN valueN;

# Override - Removes subkeyN and all keys below it, then creates node key.subkeyN
key.!subkeyN valueN;

Using override operation mode, when done correctly, is usually safe; however, one should bear in mind that there might be other necessary keys in a node for proper functioning.

Warning: Overriding pcm node itself will most definitely make alsa unusable, since every plugin definition will be deleted. Therefore, do not use !pcm.key unless you are making a configuration from scratch.
An example of setting default device using "defaults" node

Assuming that "defaults" node is set in /usr/share/alsa/alsa.conf, where "defaults.pcm.card" and its "ctl" counterpart have assignment values "0" (type integer), user wants to set default pcm and control device to (third) sound card "2" or "SB" for an Azalia sound card.

Defaults node
defaults.ctl.card 2; # Sets default device and control to third card (counting begins with 0).
defaults.pcm.card 2; # This does not change the data type.

defaults.ctl.+card 2; # Equivalent to above.
defaults.pcm.+card 2;

defaults.ctl.-card 2; # Same effect on a default setup, however if defaults node was removed or
defaults.pcm.-card 2; # type has been changed, merge operation mode will result in error.

defaults.pcm.?card 2; # This does nothing, since this assignment already exists.
defaults.ctl.?card 2;

defaults.pcm.!card "SB"; # The override operation mode is necessary here, because of
defaults.ctl.!card "SB"; # different value types.

Using double quotes here automatically sets values data type to string, so in the above example, setting defaults.pcm.!card "2" would result in retaining last default device, in this case card 0. Using double quotes for strings is not mandatory as long as no special characters are used, which ideally should never be the case. This may be irrelevant in other assignments.

Note: From a configuration point of view, those are not equivalent to setting a compound "default" pcm device, since most users specify addressing type in there also, which actually may be the same, but the assignment itself still differs. Also, defaults.pcm.card is referred to multiple times in alsa configuration files, usually as a fallback assignment, where different environment variables take precedence.

Nesting

Sometimes, it may be useful and even easier to read using nesting in configuration.

Nesting PCM plugins
pcm.azalia {	type hw; card 0	}
pcm.!default {	type plug; slave.pcm "azalia"	}

# is equivalent to

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

# which is also equivalent to

pcm.!default.type plug;
pcm.default.slave.pcm.type hw;
pcm.default.slave.pcm.card 0;

Including configuration files

Include other configuration files
</path/to/configuration-file> # Include a configuration file
<confdir:/path/to/configuration-file> # Reference to a global configuration directory

Set the default sound card

Setting the default sound card via defaults node

Putting the previous example regarding defaults.pcm.card and defaults.pcm.device into practice, assuming we have 2 cards with index 0 and 1 respectively and wish to simply change the default card to index 1, would lead to the following configuration in /etc/asound.conf or the user-specific ~/.asoundrc to change both the playback and the mixer control card.

defaults.pcm.card 1
defaults.ctl.card 1

Configuring the index order via kernel module options

Use cat /proc/asound/cards to get the list of your sound cards with their corresponding indexes (card numbers).

For the format of /proc/asound/cards, see the General Overview section of the ALSA library API Control Interface. For general information about /proc/asound procfs tree, see Proc Files of ALSA Drivers.

Use cat /proc/asound/modules to get the card indexes with their corresponding module names. Use lsmod | grep snd to get a full list of loaded sound modules.

If you want to change your sound card order (or if your sound card order changes on boot, and you want to make it permanent), reserve the index for the given driver with the the slots option of the snd module (the name slot comes from the OSS and is equivalent to the ALSA term index). See also Kernel module#Setting module options.

The following sample assumes you want your USB sound card always be the first (i.e. with index 0), no matter when the module is loaded (e.g. the card could be unplugged on boot):

/etc/modprobe.d/alsa-base.conf
options snd slots=snd_usb_audio

When a module name is prepended with an exclamation mark (!), the corresponding index will be given for any modules but that name. For example, reserve the first index (0) for any modules but snd_usb_audio to avoid USB sound cards from getting it:

/etc/modprobe.d/alsa-base.conf
options snd slots=!snd_usb_audio

You can also provide an index of -2 to instruct ALSA to never use a card as the primary one: negative value is interpreted as a bitmask of permissible indexes. The alternative to the previous sample using the index option of the specific module:

/etc/modprobe.d/alsa-base.conf
options snd_usb_audio index=-2

If several sound cards use the same module, and their order is always the same, you can change the order with just index option. The following sample assumes there are two audio cards using the HD Audio module (e.g. an integrated audio card and HDMI output of non-integrated video card), and you want to swap their indexes:

/etc/modprobe.d/alsa-base.conf
options snd_hda_intel index=1,0

The sample above reads as "the first sound card which uses snd_hda_intel gives the index 1, and the second one gives the index 0". Which card is first and which one is second is determined by udev.

Select the default PCM via environment variable

Probably, it is enough to set ALSA_CARD to the name of the device. First, get the names with aplay -l, then set ALSA_CARD to the name which comes after the colon and before the bracket; e.g. if you have

card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]

then set ALSA_CARD=HDMI.

Other variables are also checked in the default global configuration /usr/share/alsa/alsa.conf. By looking there for constructs of the form vars [ ... ], the following table emerges:

Variable name Used by
1 ALSA_CARD pcm.default , pcm.hw , pcm.plughw , ctl.sysdefault , ctl.hw , rawmidi.default , rawmidi.hw , hwdep.hw
2 ALSA_CTL_CARD ctl.sysdefault , ctl.hw
3 ALSA_HWDEP_CARD hwdep.default , hwdep.hw
4 ALSA_HWDEP_DEVICE hwdep.default , hwdep.hw
5 ALSA_PCM_CARD pcm.default , pcm.hw , pcm.plughw
6 ALSA_PCM_DEVICE pcm.hw , pcm.plughw
7 ALSA_RAWMIDI_CARD rawmidi.default , rawmidi.hw
8 ALSA_RAWMIDI_DEVICE rawmidi.default , rawmidi.hw

Alternatively, you can override the behavior in your own configuration file, preferably the global one (/etc/asound.conf). Add:

pcm.!default {
   type plug
   slave.pcm {
       @func getenv
       vars [ ALSAPCM ]
       default "hw:Audigy2"
   }
}

In this case as well, replace Audigy2 with the name of your device. You can get the names with aplay -l or you can also use PCMs like surround51. But if you need to use the microphone, it is a good idea to select full-duplex PCM as default.

Now, you can select the sound card when starting programs by just changing the environment variable ALSAPCM. It works fine for all program that do not allow to select the card; for the others, ensure you keep the default card. For example, assuming you wrote a downmix PCM called mix51to20, you can use it with mplayer using the commandline ALSAPCM=mix51to20 mplayer example_6_channel.wav

Note: Pay attention to default addressing type.

Alternative method

Tip: This process can be partly automated using asoundconfAUR.

First, you will have to find out the card and device id that you want to set as the default:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: CONEXANT Analog [CONEXANT Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: Conexant Digital [Conexant Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: JamLab [JamLab], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Audio [Altec Lansing XT1 - USB Audio], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
Warning: Simply setting a type hw as default card is equivalent to addressing hardware directly, which leaves the device unavailable to other applications. This method is only recommended if it is a part of a more sophisticated setup ~/.asoundrc or if user deliberately wants to address sound card directly (digital output through eic958 or dedicated music server for example).

For example, the last entry in this list has the card index (card number) 2 and the device ID 0. To set this card as the default, you can either use the system-wide file /etc/asound.conf or the user-specific file ~/.asoundrc. You may have to create the file if it does not exist. Then insert the following options with the corresponding card.

pcm.!default {
   type hw
   card 2
}

ctl.!default {
   type hw
   card 2
}

In most cases, it is recommended to use sound card ID strings instead of number references. Card IDs are easier to grasp, and also overcomes the boot order problem. Therefore, the following would be correct for the above example:

pcm.!default {
   type hw
   card Audio
}

ctl.!default {
   type hw
   card Audio
}

To get valid ALSA card IDs, use aplay:

$ aplay -l | awk -F \: '/,/{print $2}' | awk '{print $1}' | uniq
PCH

Alternatively, use cat, which might return unused devices:

$ cat /proc/asound/card*/id
PCH
ThinkPadEC
Note: This method could be problematic if your system has several cards of the same ID string (with _1, _2, … suffixes appended). For more information, see Identify two identical audio devices.

The pcm options affect which card and device will be used for audio playback while the ctl option affects which card is used by control utilities like alsamixer.

The changes should take effect as soon as you (re-)start an application (e.g. MPlayer). You can also test with a command like aplay:

$ aplay -D default:PCH your_favourite_sound.wav

If you receive an error regarding your asound configuration, check the upstream documentation for possible changes to the configuration file format.

Verifying correct sound modules are loaded

You can assume that udev will autodetect your sound properly. You can check this with the command:

$ lsmod | grep '^snd' | column -t
snd_hda_codec_hdmi     22378   4
snd_hda_codec_realtek  294191  1
snd_hda_intel          21738   1
snd_hda_codec          73739   3  snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel
snd_hwdep              6134    1  snd_hda_codec
snd_pcm                71032   3  snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_timer              18992   1  snd_pcm
snd                    55132   9  snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_timer
snd_page_alloc         7017    2  snd_hda_intel,snd_pcm

If the output looks similar, your sound drivers have been successfully autodetected.

You might also want to check the directory /dev/snd/ for the right device files:

$ ls -l /dev/snd
total 0
crw-rw----  1 root audio 116,  0 Apr  8 14:17 controlC0
crw-rw----  1 root audio 116, 32 Apr  8 14:17 controlC1
crw-rw----  1 root audio 116, 24 Apr  8 14:17 pcmC0D0c
crw-rw----  1 root audio 116, 16 Apr  8 14:17 pcmC0D0p
crw-rw----  1 root audio 116, 25 Apr  8 14:17 pcmC0D1c
crw-rw----  1 root audio 116, 56 Apr  8 14:17 pcmC1D0c
crw-rw----  1 root audio 116, 48 Apr  8 14:17 pcmC1D0p
crw-rw----  1 root audio 116,  1 Apr  8 14:17 seq
crw-rw----  1 root audio 116, 33 Apr  8 14:17 timer

If you have at least the devices controlC0 and pcmC0D0p or similar, then your sound modules have been detected and loaded properly.

If this is not the case, your sound modules have not been detected properly. To solve this, you can try loading the modules manually:

  • Locate the module for your sound card: ALSA Soundcard Matrix The module will be prefixed with snd_ (for example: snd_via82xx).
  • Load the module.
  • Check for the device files in /dev/snd (see above) and/or try if alsamixer or amixer have reasonable output.

Getting S/PDIF output

S/PDIF is a digital audio interface often used to connect a computer to a digital amplifier (such as a home theatre with 5.1/7.1 surround sound).

Note: With some soundcards (e.g. Sound Blaster Audigy 2) this disables analog sound output.

Add the following line to your shell configuration file:

amixer -c 0 cset name='IEC958 Playback Switch' on

You can see the name of your card's digital output with:

$ amixer scontrols

Equalizer

ALSAEqual system-wide

Install the alsaequalAUR package.

After installing the package, add the following to your ALSA configuration file:

/etc/asound.conf
ctl.equal {
    type equal;
}

pcm.plugequal {
    type equal;
    # Normally, the equalizer feeds into dmix so that audio
    # from multiple applications can be played simultaneously:
    slave.pcm "plug:dmix";
    # If you want to feed directly into a device, specify it instead of dmix:
    #slave.pcm "plughw:0,0";
}

# Configuring pcm.!default will make the equalizer your default sink
pcm.!default {
# If you do not want the equalizer to be your default,
# give it a different name, like pcm.equal commented below
# Then you can choose it as the output device by addressing
# it in individual apps, for example mpg123 -a equal 06.Back_In_Black.mp3
# pcm.equal {
    type plug;
    slave.pcm plugequal;
}

To change your equalizer settings, run

$ alsamixer -D equal

Note that the equalizer configuration is different for each user (until not specified else). It is saved in ~/.alsaequal.bin. So if you want to use ALSAEqual with mpd or another software running under different user, you can configure it using

$ su mpd -c 'alsamixer -D equal'

or for example, you can make a symlink to your .alsaequal.bin in their home directory.

ALSAEqual for specific outputs only

If you wish to apply an equalizer to a specific output device only (for example your speakers connected to the S/PDIF output, but not your headphones connected to the headphone jack), but also want be able to output from multiple applications and to both output devices simultaneously, you need to create two dmix devices that feed into their respective devices (slave.pcm) directly. The following works for stereo output and maintains a regular stereo input, applying the equalizer to the S/PDIF output only.

/etc/asound.conf
#
#  (capture.pcm)  <-- dnsoop
#        |
# !default                               --> dmixa
#        |                               |
#  (playback.pcm) --> stereo2quad ==> quad
#                                        |
#                                        --> softvol --> plugequal --> dmixd 
#

# dmix for analog output
pcm.dmixa {
  type dmix
  ipc_key 1024
  ipc_perm 0666
  slave.pcm "hw:PCH,0"
  slave {
    period_time 0
    period_size 1024
    buffer_size 4096
    channels 2
  }
  bindings {
    0 0
    1 1
  }
}

# dmix for digital output
pcm.dmixd {
  type dmix
  ipc_key 2048
  ipc_perm 0666
  slave.pcm "hw:PCH,1"
  slave {
    period_time 0
    period_size 1024
    buffer_size 4096
    channels 2
  }
  bindings {
    0 0
    1 1
  }
}

# equalizer with controls
pcm.plugequal {
  type equal
  slave {
    pcm "plug:dmixd"
  }
}
ctl.equal {
 type equal
}

# Volume control for S/PDIF
pcm.softvol {
    type softvol
    slave.pcm "plug:plugequal"
    control {
        name "S/PDIF"
    }
}

# multi:
# "a" (analog)  -> dmix,
# "d" (digital) -> softvol -> plugequal -> dmix
pcm.quad {
    type multi
    slaves {
      a.pcm "dmixa"
      a.channels 2
      d.pcm "plug:softvol" # detour via softvol and equalizer
      d.channels 2
    }
    bindings {
      0 { slave a; channel 0; }
      1 { slave a; channel 1; }
      2 { slave d; channel 0; }
      3 { slave d; channel 1; }
    }
}

# stereo to quad
pcm.stereo2quad {
  type route
  slave.pcm "quad"
  ttable [
    [ 1 0 1 0 ]
    [ 0 1 0 1 ]
  ]
}

# playback to stereo to quad, capture as usual
pcm.!default {
  type asym
  playback.pcm "plug:stereo2quad"
  capture.pcm "plug:dnsoop"
}

Managing ALSAEqual states

Install the alsaequal-mgrAUR package.

Configure the equalizer as usual with

$ alsamixer -D equal

When you are satisfied with the state, you may give it a name (foo in this example) and save it:

$ alsaequal-mgr save foo

The state "foo" can then be restored at a later time with

$ alsaequal-mgr load foo

This, however, only restores ~/.alsaequal.bin. You then have to update the equalizer by alsamixer -D equal.

You can thus create different equalizer states for games, movies, music genres, VoIP apps, etc. and reload them as necessary.

See the project page and the help message for more options.

Using mbeq

Multiband EQ (mbeq)

is a fairly typical multiband graphical equalizer. It is implemented using a fast Fourier transform (FFT), so it takes quite a lot of CPU power, but should have less phase effects than an equivalent filter implementation. If the input signal is at too low sample rate, then the top bands will be ignored—the highest useful band will always be a high shelf.

mbeq is part of Steve Harris' LADSPA plugin suite.

Install the alsa-plugins, ladspa and swh-plugins packages if you do not already have them.

If you have not already created either an ~/.asoundrc or a /etc/asound.conf file, then create either one and insert the following:

/etc/asound.conf
pcm.eq {
    type ladspa

    # The output from the EQ can either go direct to a hardware device
    # (if you have a hardware mixer, e.g. SBLive/Audigy) or it can go
    # to the software mixer shown here.
    #slave.pcm "plughw:0,0"
    slave.pcm "plug:dmix"

    # Sometimes, you may need to specify the path to the plugins,
    # especially if you have just installed them.  Once you have logged
    # out/restarted, this should not be necessary, but if you get errors
    # about being unable to find plugins, try uncommenting this.
    #path "/usr/lib/ladspa"

    plugins [
    {
        label mbeq
        id 1197
        input {
            # The following setting is just an example, edit to your own taste:
            # bands: 
            #   50 Hz,  100 Hz,  156 Hz,  220 Hz,  311 Hz,   440 Hz,   622 Hz,  880 Hz,
            # 1250 Hz, 1750 Hz, 2500 Hz, 3500 Hz, 5000 Hz, 10000 Hz, 20000 Hz
            controls [ -5 -5 -5 -5 -5 -10 -20 -15 -10 -10 -10 -10 -10 -3 -2 ]
            }
        }
    ]
}

# Redirect the default device to go via the EQ - you may want to do
# this last, once you are sure everything is working.  Otherwise, all
# your audio programs will break/crash if something has gone wrong.
pcm.!default {
    type plug
    slave.pcm "eq"
}

# Redirect the OSS emulation through the EQ too (when programs are running through "aoss")
pcm.dsp0 {
    type plug
    slave.pcm "eq"
}

High quality resampling

When software mixing is enabled, ALSA is forced to resample everything to the same frequency (48 kHz by default when supported). By default, it will try to use the speexrate converter to do so, and fallback to low-quality linear interpolation if it is not available[3]. Thus, if you are getting poor sound quality due to bad resampling, the problem can be solved by simply installing the alsa-plugins package.

For even higher quality resampling, you can change the default rate converter to speexrate_medium or speexrate_best. Both perform well enough that in practice it does not matter which one you choose, so using the best converter is usually not worth the extra CPU cycles it requires.

To change the default converter, place the following contents in your ~/.asoundrc or /etc/asound.conf:

/etc/asound.conf
defaults.pcm.rate_converter "speexrate_medium"
Note:
  • It is also possible to use libsamplerate converters, which are only about half as fast as the speexrate converters but do not achieve much higher quality. See discussion.
  • It is also possible to use lavcrate[4] resamplers that use FFmpeg. With filter sizes of lavcrate_faster:4 lavcrate_fast:8 lavcrate:16 lavcrate_high:32 lavcrate_higher:64. With the last 2 options being equal to Kodi low and medium quality resamplers respectively.
  • Some applications (like MPlayer and its forks) do their own resampling by default because some ALSA drivers have incorrect delay reporting when resampling is enabled (hence leading to AV desynchronization), so changing this setting will not have any effect unless you configure them to use ALSA resampling.

Upmixing/downmixing

Upmixing

In order for stereo sources like music to be able to saturate a 5.1 or 7.1 sound system, you need to use upmixing. In darker days, this used to be tricky and error prone, but nowadays, plugins exist to easily take care of this task. We will use the upmix plugin, included in the alsa-plugins package.

Then add the following to your ALSA configuration file of choice (either /etc/asound.conf or ~/.asoundrc):

pcm.upmix71 {
   type upmix
   slave.pcm "surround71"
   delay 15
   channels 8
}

You can easily change this example for 7.1 upmixing to 5.1 or 4.0.

The following example adds a new PCM channel that you can use for upmixing. If you want all sound sources to go through this channel, add it as a default below the previous definition like so:

pcm.!default "plug:upmix71"

The plugin automatically allows multiple sources to play through it without problems so setting is as a default is actually a safe choice. If this is not working, you have to setup your own dmixer for the upmixing PCM like this:

pcm.dmix6 {
   type asym
   playback.pcm {
       type dmix
       ipc_key 567829
       slave {
           pcm "hw:0,0"
           channels 6
       }
   }
}

and use "dmix6" instead of "surround71". If you experience skipping or distorted sound, consider increasing the buffer_size (to 32768, for example) or use a high quality resampler.

Downmixing

If you want to downmix sources to stereo because you, for instance, want to watch a movie with 5.1 sound on a stereo system, use the vdownmix plugin, included in the alsa-plugins package.

Again, in your configuration file, add this:

pcm.!surround51 {
   type vdownmix
   slave.pcm "default"
}
pcm.!surround40 {
   type vdownmix
   slave.pcm "default"
}
Note: This might not be enough to make downmixing working; see [5]. So, you might also need to add pcm.!default "plug:surround51" or pcm.!default "plug:surround40". Only one vdownmix plug can be used; if you have 7.1 channels, you will need to use surround71 instead the configuration above. A good example, which includes a configuration that makes both vdownmix and dmix working, can be found in [6].

Dmix

Mixing enables multiple applications to output sound at the same time. Most discrete sound cards support hardware mixing, which is enabled by default if available. Integrated motherboard sound cards (such as Intel HD Audio), usually do not support hardware mixing. On such cards, software mixing is done by an ALSA plugin called dmix. This feature is enabled automatically if hardware mixing is unavailable.

Note: Dmix is enabled by default for soundcards which do not support hardware mixing. Dmix is not enabled by default for digital output (S/PDIF) and will require the configuration snippet below.

To manually enable dmix, add the following to your ALSA configuration file:

/etc/asound.conf
pcm.dsp {
    type plug
    slave.pcm "dmix"
}

Tips and tricks

Disabling auto mute on startup

Auto-Mute Mode can be configured on startup with amixer. For example, to disable it:

# amixer -c 0 sset "Auto-Mute Mode" Disabled

Alternatively, the ncurses based interface can be utilized through alsamixer. In order to save any modifications, use:

# alsactl store

or

# alsactl daemon

See also #ALSA and systemd.

Hot-plugging a USB sound card

See Writing Udev rules for ALSA.

Simultaneous output

You might want to play music via external speakers connected via mini jack and internal speakers simultaneously. This can be done by unmuting Auto-Mute item using alsamixer or amixer:

$ amixer sset "Auto-Mute" unmute

and then unmuting other required items, such as Headphones, Speaker, Bass Speaker...

Note: If you have a crackling sound through headphones connector (mini-jack) after, see /Troubleshooting#Crackling sound through mini-jack (headphones connector).

Keyboard volume control

Map the following commands to your volume keys: XF86AudioRaiseVolume, XF86AudioLowerVolume, XF86AudioMute.

To raise the volume:

amixer set Master 5%+

To lower the volume:

amixer set Master 5%-

To toggle mute/unmute of the volume:

amixer set Master toggle

Virtual sound device using snd_aloop

You might want a jack alternative to create a virtual recording or play device in order to mix different sources, using the snd_aloop module:

modprobe snd_aloop

List your new virtual devices using:

aplay -l

now you can for example using ffmpeg:

ffmpeg -f alsa -i hw:1,1,0 -f alsa -i hw:1,1,1 -filter_complex amerge output.mp3

In the hw:R,W,N phrase, R is your virtual card device number. W should be set to 1 for recording devices, or 0 for playing. N is your sub device. You can use all the virtual devices available and play/stop using applications like mplayer:

mplayer -ao alsa:device=hw=1,0,0 fileA
mplayer -ao alsa:device=hw=1,0,1 fileB

Another thing you could do with this approach is using festival to generate a voice into a recording stream using a script like this:

#!/bin/sh
echo "$1" | iconv -f utf-8 -t iso-8859-1 | text2wave  > "_tmp_.wav"
mplayer -ao alsa:device=hw=2,0,0 "_tmp.wav"
rm "_tmp.wav"

Resetting codecs

The ALSA driver can fully reconfigure attached codecs (the parts of the sound system that actually process audio streams), by doing:

# echo 1 > /sys/class/sound/card/reconfig

Before doing this, all processes using the ALSA driver (such as Pulseaudio or JACK) must be stopped.

Reconfiguring input/output ports

The alsa-tools package contains the hdajackretask tool, which can be used (on Intel HDA cards) to reconfigure the sound card input/output ports; for instance, to turn a microphone jack into a headphone jack.

Correctly detect microphone plugged in a 4-pin 3.5mm (TRRS) jack

On some modern laptops, you may have a combined 3.5mm headset jack, instead of two separated ones, which may not be correctly detected by default. To make ALSA correctly detect plug-in status on your 3.5mm jack, you can put the following line into your /etc/modprobe.d/alsa-base.conf:

options snd_hda_intel index=0 model=your_model_setting

For a complete list of options to put in your_model_setting, see HD-Audio Codec-Specific Models or its source located at /usr/lib/modules/$(uname -r)/build/Documentation/sound/hd-audio/models.rst (provided by the linux-docs package). A common model is dell-headset-multi, even if the hardware is not from Dell.

See also