ALSA

From Free Knowledge Base- The DUCK Project: information for everyone
Revision as of 19:44, 25 March 2021 by Admin (Talk | contribs)

Jump to: navigation, search

ALSA or the Advanced Linux Sound Architecture provides audio support for Linux. It is a replacement for the old OSS linux sound system. The Alsa-utils package contains both the Alsamixer and Amixer utilities. Various linux distributions once used the Open Sound System, or OSS until ALSA superseded it. ALSA provides kernel driven sound card drivers and bundles a user space driven library for application developers.

You can control the audio properties of your sound cards through:

  • Alsamixer-The graphical interface for ALSA
  • Amixer-The command based utility for ALSA

ALSA supports up to eight cards, numbered 0 through 7; each card is a physical or logical kernel device capable of input and output. Furthermore, each card may also be addressed by its id. A card has devices, numbered starting at 0; a device may be of playback type or a capture type. A device may have subdevices, numbered starting at 0. Card interface types include hw, plughw, default, and plug:dmix. Software will reference it like: interface:card,device,subdevice.


ALSA CLI Utilities

alsamixer

ncurses based utility with visual representation of various levels.

alsamixer

Enable the microphone: switch to the Capture tab with F4 and enable a channel with Space.

mixer

Command line, operation performed per command.

amixer -c [card-number] set [control] [value]

To see what controls you can manage

amixer scontrols

If you are sudo there are more controls available

sudo amixer scontrols

apulse

The apulse utility lets you use ALSA for applications that support only PulseAudio for sound.

aplay

Alsa play - play an audio file

An example:

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

An example which specifies a particular sound card

aplay -D hw:0,0 /usr/share/sounds/alsa/Noise.wav

to access the first device on the first soundcard/device, you would use

hw:0,0

to access the first device on the second soundcard/device, you would use

hw:1,0

to access the second device on the third soundcard/device, you would use

hw:2,1

arecord

We can test the default audio input device, or the only audio input device on a simplistic configuration

arecord -vvv -f dat /dev/null

Watch while the audio input levels are displayed as a percentage.

We can specify an audio input device

arecord -vvv --device="hw:1,0" -f dat /dev/null

You can display a list of CAPTURE Hardware Devices. To figure out what audio input device is at hw: card,device use the following command

arecord -l

The output look for "Card X" and on the same line "device X" to know the card,device combination to specify.

speaker-test

as the name implies

Example: Testing audio input / microphone input Excerpt from Troubleshooting Linux Sound by Steve Litt troubleshooting guide"

Steve says, "The speaker-test program provides a nice, easy way to provide input for your sound system. When used with no arguments, it simply supplies white noise to both speakers."

Testing an M-Audio external USB sound board it was unclear as to whether or not stereo separation was functional or if the audio was monaural (mono) since the balance slider on audio players seemed to have zero impact. Elimination of audio application software is advised to find if ALSA and your wiring are correct. Use this command:

speaker-test -c2 -t wav

As Steve advised in his article the command will alternate between left and right speaker audio dialog in a loop allowing you to listen and determine if the sound is coming from the speakers, the correct speakers and that you have functional stereo separation. You may find it useful to ensure you do not have intended left speaker audio coming out of your right speaker. If you have more than 2 channels, put the number of channels in the -c argument.

Be advised the article is very informative and we hope it remains online as well as The Steve Litt Diagnostic Tools he provides there. Thanks Steve!

Configuration

All files in /proc/asound are created and used by ALSA. these files describe the sound card or related devices.

  • /proc/asound/cardX/ (where X is the sound card number, from 0-7) : a cardX directory exists for each sound card
  • /proc/asound/cards is the list of registered cards
  • /proc/asound/dev/ is a directory listing the specific device files used by programs for sound operations if your system uses devfs
  • /proc/asound/devices is a read-only file showing the registered alsa devices such as digital audio capture and playback
  • /proc/asound/hwdep hardware dependent controls
  • /proc/asound/meminfo shows kernel level memory space
  • /proc/asound/modules lists registered ALSA soundcard drivers for specific things such as each soundcard
  • /proc/asound/oss/ old oss emulation
  • /proc/asound/pcm helpful for identification of hw:0,0 labels, technically they are streams/devices but think of it as how you find the hw:X,X values you are looking for.
  • /proc/asound/seq/ sequencer data
  • /proc/asound/timers a list of timers ALSA knows about, and also describe which ones are in active use. (could this be useful in resolving Device or resource busy issues?)
  • /proc/asound/version version and date the ALSA subsystem

As an example, this break down the output of

lsof /dev/snd/pcm*

we see (this is an example, yours will be different)

fungame 4854 nicolep   mem   CHR  116,10           632 /dev/snd/pcmC0D0c
fungame 4854 nicolep   68u   CHR  116,10      0t0  632 /dev/snd/pcmC0D0c

which is

  • fungame - the process name, in this case a game that is using ALSA to do sound (play or capture)
  • 4854 - PID
  • nicolep - the username owns the process
  • /dev/snd/pcmC0D0c - device files are what applications connect to in order to perform sound operations

The device file here is 'pcmC0D0c'

  • pcm is the service name or type, ours is clearly a pcm which is an alsa stream type
  • C0 is the card number, C for card and 0 as the first card (numbering starting with 0 and going up 1,2,3...)
  • D0 is the device number, D for device and 0 as the first device
  • c indicates it is a capture device. If it is a 'p' then it is a PCM playback device, if it is a 'c' then it is a PCM capture device.

The example we used is only showing capture devices. It is more common to see some devices ending in 'p' and 'c' both. The pcm devices (physical I/O channels) are represented in ALSA starting at pcm0c (capture), pcm0p (playback).

Sound Mixing with the ALSA Dmix Instead of Pulse Audio

Neither the user-side .asoundrc nor the asound.conf configuration files are required for ALSA to work properly. Most software will work with sound even if you are not using a sound server and have never created the configuration files. Sometimes you may find that to resolve issues such as resource busy problems and you discover the software is not capable of using your sound server you have to create the alsa configuration file.

You can uninstall PulseAudio or just disable it after boot. For Ubuntu/Mint you can stop the service:

systemctl --user stop pulseaudio.socket
systemctl --user stop pulseaudio.service

You are doing this because you dont want to get rid of PulseAudio at this time, but you do what do experiment with dmix or using alsa directly because you are a developer or are trying to work through some trouble with your system. Pulseaudio is a sound server, and it helps deal with the complexities of sharing sound device resources. You don't really need a sound server, you can do this with ALSA directly.

To take advantage of dmix in alsa you will create .asoundrc configuration file for your soundcard.

vi ~/.asoundrc

Then populate the file with the correct entries for your card.

You can alternatively make a /etc/asound.conf file which is the system wide version of .asoundrc

sudo vi /etc/asound.conf

You have to configure each sound application to use alsa:dmix. This is the catch. If the software you are using lets you choose the dmix device, then it is reasonable to assume it would just as easily have let you choose pulseaudio. This has to be tested. Some older games and software won't use a sound server or try to access it. They may try for ALSA directly, meaning it is possible they might also be able to see your dmix device that you created.

Sample asound.conf - the beginnings of the configuration file

pcm.!default {
        type hw
        card 0
} 

ctl.!default {
        type hw           
        card 0
}


Exercise

Lets try to make a dmix device for a sample sound card configuration when using alsa and pulseaudio is out of the way. We will make it for pcm

1. What cards to we have in our system?

cat /proc/asound/cards

2. Can we play sound directly to the card?

aplay -D hw:0,0 ~/Music/Noise.wav

INCOMPLETE...