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

 

Instruction

 

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.

audio_api.png

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

 

Architecture

 

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.

alsa_pipeline.png

 

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

pcm.xxx {

    @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,

pcm.dmix_44100{

    type dmix

    ipc_key 5678293

    ipc_key_add_uid yes

    slave{

        pcm "hw:0,0"

        period_time 10000

        format S16_LE

        rate 44100

    }

}

pcm.!default{

    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:

alsa_tee.png

 

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:

alsa_pulse.png

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.


Attachments

    Outcomes