alsa-lib Configuration Introduction

Document created by Wayne Feng Employee on Oct 9, 2012Last modified by Jodi Paul on May 21, 2013
Version 2Show Document
  • View in full screen mode




On Linux OS, we have two major audio system API to play/record audio pcm, alsa-lib and pulseaudio. Pulseaudio is in Freescale Ubuntu root fs release, while alsa-lib is used by default in LTIB release.


This article is to tell how to configure alsa-lib by configuration file.




Alsa-lib has a set of standard API which allows application to develop easily. At the same time, it provides a scalable mechanism to fulfill its features, including resample, channels remix, sound mixing from different applications, and so on.



As above figure describes, alsa plugin provide fundamental function, and the whole pipeline makes customization possible.

Alsa-lib API pretend to be an alsa device and provide a name for caller to open. What kind of plugin the name represents for is decided by configuration. For example,

pcm.card0 {

   type hw

   card 0


card0 is the fake alsa device name, with type hw, which represents for the first real alsa device.

pcm.plug {

    @args [ SLAVE ]

    @args.SLAVE {

        type string


    type plug

    slave.pcm $SLAVE



plug is the fake alsa device name, with type plug, which represents for audio conversion processor. In addition, it's also receive arguments from application that make it more flexible. When we call

snd_pcm_open(.., "plug:card0",..);

in the application, we create a pipeline which will first convert the source pcm to sound card 0 capable pcm if necessary in "plug" plugin, then play it to sound card 0 in "card0" plugin.  "slave.pcm" is the key to link different plugins.


The number of arguments could be more than one, with definition {

    @args [ arg1 arg2 arg3 ]

    @args.arg1 { type string }

    @args.arg2 { type string }

    @args.arg3 { type string }



The argument could also have default value, please refer to /usr/share/alsa/alsa.conf.

To pass the arguments, use


snd_pcm_open(.., "xxx:arg1,arg2,arg3",..);

From the name, we can always follow the pipeline to the last plugin, which type might be hw(to alsa driver), file(to file), or others (pulse, bluetooth...) to network, protocol stack and so on.


The Configuration Files


In configuration file, we mainly define the fake alsa device name.

The root configuration file is /usr/share/alsa/alsa.conf, which will load additional configuration files which might overwrite previous name definition in the previously loaded file. The load sequence is:

1. /usr/share/alsa/alsa.conf

2. /usr/share/alsa/alsa.conf.d/*

3. /etc/asound.conf for administrator

4. $(HOME)/.asoundrc for certain user

In practice, alsa applications (e.g. aplay or speaker-test) are always using "default" as the fake device name, so that the most important thing to customize your own pipeline is to overwirte "default". For example,


    type dmix

    ipc_key 5678293

    ipc_key_add_uid yes


        pcm "hw:0,0"

        period_time 10000

        format S16_LE

        rate 44100




    type plug

    route_policy "average"

    slave.pcm "tee:dmix_44100,/home/wayne/a.pcm"


The "!" in "pcm.!default" means forcing overwrite. The pipeline defined above is as following figure:



The next example is the "default" definition on ubuntu root fs.

pcm.!default {

    type pulse

    hint {

        show on

        description "Playback/recording through the PulseAudio sound server"



The only alsa plugin is "pulse", and the pipeline is as following:


Additional Resources


There are a lot of alsa plugins developed, with various configuration parameters, I won't list them in detail. Please refer to .asoundrc - ALSA wiki for more details.