NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

UserGuideAudioDriver PSP 04.02.00.07

From Texas Instruments Wiki
Jump to: navigation, search
Audio Driver  

Introduction

Audio module is available inside PMIC IC TPS65950 (in OMAP35xEVM, AM37xEVM, BEAGLE, BEAGLEXM) and AIC23 (in AM3517EVM), contains audio analog inputs and outputs. It is connected to the main processor through the TDM / I2S interface and used to transmit and receive audio data. The TPS65950 / AIC23 audio codec is connected via Multi-Channel Buffered Serial Port (McBSP) interface, a communication peripheral, to the main processor.


McBSP provides a full-duplex direct serial interface between the main processor (AM/DM37x, OMAP35x and AM3517) and other devices in the system such as the TPS65950 / AIC23 codec. It provides a direct interface to industry standard codecs, analog interface chips (AICs) and other serially connected A/D and D/A devices:

  • Inter-IC Sound (I2S) compliant devices
  • Pulse Code Modulation (PCM) devices
  • Time Division Multiplexed (TDM) bus devices.


The TPS65950 / AIC23 audio module is controlled by internal registers that can be accessed by the high speed I2C control interface.

This user manual defines and describes the usage of user level and platform level interfaces of the ALSA SoC Audio driver.


References

  1. ALSA SoC Project Homepage [http://www.alsa-project.org/main/index.php/ASoC]
  2. ALSA Project Homepage [http://www.alsa-project.org/main/index.php/Main_Page]
  3. ALSA User Space Library [http://www.alsa-project.org/alsa-doc/alsa-lib/]
  4. Using ALSA Audio API [http://www.equalarea.com/paul/alsa-audio.html] Author: Paul Davis
  5. Using alsamixer interface [http://linux.die.net/man/1/alsamixer]
  6. TPS65950: Integrated Power Management IC with 3 DC/DC's, 11 LDO's, Audio Codec, USB HS Transceiver, Charger. [http://focus.ti.com/docs/prod/folders/print/tps65950.html
  7. TLV320AIC23B - Low-Power Stereo CODEC with HP Amplifier. Literature Number: SLWS106H. [[tlv320aic23b.pdf|focus.ti.com/lit/ds/symlink/ tlv320aic23b.pdf]


Acronyms & Definitions

Audio Driver: Acronyms
Acronym Definition
ALSA Advanced Linux Sound Architecture
ALSA SoC ALSA System on Chip
DMA Direct Memory Access
I2C Inter-Integrated Circuit
McBSP Multi-channel Buffered Serial Port
PCM Pulse Code Modulation
TDM Time Division Multiplexing
OSS Open Sound System
I2S Inter-IC Sound


Features

This section describes the features supported by ALSA SoC Audio driver.


  • Supports AIC23 audio codec (on AM3517 only) and TPS65950 audio codec (on AM/DM37x,OMAP35x only) in ALSA SoC framework.
  • Multiple sample rates support (8KHz, 16KHz, 22.05KHz, 32KHz, 44.1KHz, 48KHz, 64KHz, 88.2KHz and 96KHz - AM3517; 8 KHz, 11.025 KHz, 12 KHz, 16 KHz, 22.05 KHz, 24 KHz, 32 KHz, 44.1 KHz and 48 KHz - AM/DM37x,OMAP35x) for both capture and playback.
  • Supports audio in stereo mode.
  • Supports simultaneous playback and record (full-duplex mode).
  • Start, stop, pause and resume feature.
  • Supports mixer interface for audio codecs.
  • Supports MMAP mode for both playback and capture.
  • McBSP is configured as slave and TPS65950 / AIC23 Codec is configured as master.


Important (for AM/DM37x,OMAP35x ONLY)

  • Audio capture channels AUXL and AUXR are by default disabled for AM/DM37x,OMAP35x ASoC driver. To enable,hit the <space> key on channels "Analog Left AUXL" & "Analog Right AUXR" in the alsamixer interface under Capture tab. Or use the following 'amixer' commands:

amixer cset name='Analog Left AUXL Capture Switch' 1
amixer cset name='Analog Right AUXR Capture Switch' 1

  • Audio playback (on Headset channel) is muted by default. On alsamixer interface use the key "m" to unmute "HeadsetL Mixer AudioL1" & "HeadsetR Mixer AudioR1" channels under the Playback tab.

Or use the following amixer commands:
amixer cset name='HeadsetL Mixer AudioL1' on
amixer cset name='HeadsetR Mixer AudioR1' on


Important (for AM3517 ONLY)
By default Line is enabled under [Capture] tab in alsamixer instead of Mic.To use microphone input instead, enable Mic setting under [Capture] tab and unmute (using the "m" key) the Mic Boost setting under [Playback]

  • When Line is enabled (default) under [Capture] tab in alsamixer, connect an audio player source to Line In Codec 1 jack on the application board.
  • When Mic is enabled under [Capture] tab in alsamixer ( and Mic boost is un-muted), connect a headset microphone to the Mic In Codec 1 jack on the application board.


Important

  • Please note that enabling any line-in inputs necessitates connecting an audio playback source's output ; connecting a (non-preamplified) microphone input (like the one from a head-set jack) might not work.
  • The audio output might be muted or be at a barely audible volume - use the following command (repeatedly) to increase the volume (after un-muting if required):

amixer -c 0 set Headset 1+ unmute


ALSA SoC Architecture

Introduction


The overall project goal of the ALSA System on Chip (ASoC) layer is to provide better ALSA support for embedded system on chip processors and portable audio codecs. Currently there is some support in the kernel for SoC audio, however it has some limitations:

  • Currently, codec drivers are often tightly coupled to the underlying SoC cpu. This is not really ideal and leads to code duplication.
  • There is no standard method to signal user initiated audio events e.g. Headphone/Mic insertion, Headphone/Mic detection after an insertion event.
  • Current drivers tend to power up the entire codec when playing (or recording) audio. This is fine for a PC, but tends to waste a lot of power on portable devices. There is also no support for saving power via changing codec oversampling rates, bias currents, etc.


Design

The ASoC layer is designed to address these issues and provide the following features:

  • Codec independence: Allows reuse of codec drivers on other platforms and machines.
  • Easy I2S/PCM audio interface setup between codec and SoC. Each SoC interface and codec registers it's audio interface capabilities with the core and are subsequently matched and configured when the application hw params are known.
  • Dynamic Audio Power Management (DAPM): DAPM automatically sets the codec to it's minimum power state at all times. This includes powering up/down internal power blocks depending on the internal codec audio routing and any active streams.
  • Pop and click reduction: Pops and clicks can be reduced by powering the codec up/down in the correct sequence (including using digital mute). ASoC signals the codec when to change power states.


To achieve all this, ASoC basically splits an embedded audio system into three components:

  • Codec driver: The codec driver is platform independent and contains audio controls, audio interface capabilities, codec dapm definition and codec IO functions.
  • Platform driver: The platform driver contains the audio dma engine and audio interface drivers (e.g. I2S, AC97, PCM) for that platform.
  • Machine driver: The machine driver handles any machine specific controls and audio events i.e. turning on an amp at start of playback.


Following architecture diagram shows all the components and the interactions among them:

AM/DM37x, OMAP35x:

ALSA SoC Architecture (AM/DM37x, OMAP35x)


AM3517:

ALSA SoC Architecture (AM3517)


Configuration

To enable/disable audio support, start the Linux Kernel Configuration tool:


$ make menuconfig ARCH=arm


Select Device Drivers from the main menu.


    ...
    ...
    Power management options --->
    [*] Networking support --->
    '''Device Drivers --->'''
    File systems --->
    Kernel hacking --->
    ...
    ...


Select Sound card support as shown here:


    ...
    ...
    Multimedia devices --->
    Graphics support --->
'''<*> Sound card support --->'''
[*] HID Devices --->
[*] USB support --->
    ...
    ...


Select Advanced Linux Sound Architecture as shown here:


--- Sound card support
'''<*> Advanced Linux Sound Architecture --->'''
< > Open Sound System (DEPRECATED) --->



Select ALSA for SoC audio support as shown here:


    ...
    ...
[*] ARM sound devices  --->
[*] SPI sound devices  --->
[*] USB sound devices  --->
'''<*> ALSA for SoC audio support --->'''



For AM/DM37x,OMAP35x, select SoC Audio support for OMAP3EVM board as shown here:


--- ALSA for SoC audio support
<*> SoC Audio for the Texas Instruments OMAP chips
'''<*> SoC Audio support for OMAP3EVM board'''
< > Build all ASoC CODEC drivers



For AM3517, select SoC Audio support for OMAP3517 / AM3517 EVM as shown here:


--- ALSA for SoC audio support
<*> SoC Audio for the Texas Instruments OMAP chips
'''<*> SoC Audio support for OMAP3517 / AM3517 EVM'''
< > Build all ASoC CODEC drivers



Make sure that McBSP support is enabled. To check the same, select System Type from the main menu.


    ...
    ...
[*] Enable loadable module support --->
[*] Enable the block layer --->
    '''System Type --->'''
    Bus support --->
    Kernel Features --->
    ...
    ...



Select TI OMAP Common Features as shown here:


    [*] MMU-based Paged Memory Management Support
    ARM system type (TI OMAP) --->
    '''TI OMAP Common Features --->'''
    TI OMAP2/3/4 Specific Features  --->
    *** Processor Type ***
-*- Support ARM V6K processor extensions 
    ...
    ...



McBSP support should be selected:


    ...
    ...
[ ] Multiplexing debug output
[*] Warn about pins the bootloader didn't set up
-*- McBSP support
< > Mailbox framework support
< > Export OMAP IOMMU internals in DebugFS
    System timer (Use 32KHz timer) --->
    ...
    ...


Application Interface

This section provides the details of the Application Interface for the ALSA Audio driver.

Application developer uses ALSA-lib, a user space library, rather than the kernel API. The library offers 100% of the functionality of the kernel API, but adds major improvements in usability, making the application code simpler and better looking.

The online-documentation for the same is available at:

http://www.alsa-project.org/alsa-doc/alsa-lib/


Device Interface

The operational interface in /dev/ contains three main types of devices: 

  • PCM devices for recording or playing digitized sound samples,
  • CTL devices that allow manipulating the internal mixer and routing of the card, and,
  • MIDI devices to control the MIDI port of the card, if any.


Device Interface
Name Description
/dev/snd/controlC0 Control devices (i.e. mixer, etc)
/dev/snd/pcmC0D0c PCM Card 0 Device 0 Capture device
/dev/snd/pcmC0D0p PCM Card 0 Device 0 Playback device


Proc FS Interface

The /proc/asound kernel interface is used as a status and configuration interface. A lot of useful information about the sound system can be found in the /proc/asound subdirectory.


Please refer to the below table for different proc entries in /proc/asound for Audio driver:


Proc Interface
Name Description
cards List of registered cards
version Version and date the driver was built on
devices List of registered ALSA devices
pcm The list of allocated PCM streams
cardX/ (X = 0-7) The card specific directory
cardX/pcm0p The directory of the given PCM playback stream
cardX/pcm0c The directory of the given PCM capture stream


Sys FS Interface

The /sys FS interface is used to configure settings for the audio interface and to extract information.


Please refer to the below table for list of various /sys entries for the audio driver:


Proc Interface
Name Description

sys/devices/platform/soc-audio/TWL4030

sys/devices/platform/soc-audio/TLV320AIC23

Information on the codec device.

e,g. codec_reg attribute provides the register dump

/sys/devices/platform/omap-pcm-audio
Interface for the platform pcm(ALSA) device
/sys/devices/platform/omap-mcbsp-dai.x
Interface for the McBSP device; x is 0 for AM3517 and 1 for AM/DM37x & OMAP35x



Commonly Used APIs


Some of the commonly used APIs to write an ALSA based application are:

Commonly Used APIs
Name Description
snd_pcm_open Opens a PCM stream
snd_pcm_close Closes a previously opened PCM stream
snd_pcm_hw_params_any Fill params with a full configuration space for a PCM
snd_pcm_hw_params_test_ <<parameter>> Test the availability of important parameters like number of channels, sample rate etc. For e.g. snd_pcm_hw_params_test_format, snd_pcm_hw_params_test_rate etc.
snd_pcm_hw_params_set_ <<parameter>> Set the different configuration parameters. For e.g. snd_pcm_hw_params_set_format, snd_pcm_hw_params_set_rate etc.
snd_pcm_hw_params Install one PCM hardware configuration chosen from a configuration space
snd_pcm_writei Write interleaved frames to a PCM
snd_pcm_readi Read interleaved frames from a PCM
snd_pcm_prepare Prepare PCM for use
snd_pcm_drop Stop a PCM dropping pending frames
snd_pcm_drain Stop a PCM preserving pending frames


User Space Interactions


This section depicts the sequence of operations for a simple playback and capture application.

ASoC Driver: Half Duplex Playback
ASoC Driver: Half Duplex Record


Sample Applications

This chapter describes the audio sample applications provided along with the package. The source for these sample applications are available in the Examples directory of the Release Package folder.

The applications arecord, aplay and amixer are also available in the alsa-utils package available at ftp://ftp.alsa-project.org/pub/utils/alsa-utils-1.0.24.2.tar.bz2
The source needs to be cross-compiled using the Code-Sourcery tool-chain (i,e. arm-none-linux-gnueabi- prefixed) and needs libasound (currently tested with /usr/lib/libasound.so.2) to run on these platforms.

Writing a simple audio application

Writing an audio application involves the following steps:

  • Opening the audio device
  • Set the parameters of the device
  • Receive audio data from the device or deliver audio data to the device
  • Close the device

These steps are explained in detail in this section.

Note
User space ALSA libraries can be downloaded from this link http://www.alsa-project.org/main/index.php/Download. User needs to build and install them before he starts using the ALSA based applications.

A minimal playback application

This program opens an audio interface for playback, configures it for stereo, 16 bit, 44.1kHz, interleaved conventional read/write access. Then its delivers a chunk of random data to it, and exits. It represents about the simplest possible use of the ALSA Audio API, and isn't meant to be a real program.

Opening the audio device

To write a simple PCM application for ALSA, we first need a handle for the PCM device. Then we have to specify the direction of the PCM stream, which can be either playback or capture. We also have to provide some information about the configuration we would like to use, like buffer size, sample rate, pcm data format. So, first we declare:


#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>

#define BUFF_SIZE 4096

int main (int argc, char *argv[])
{
  int err;
  short buf[BUFF_SIZE];
  int rate = 44100; /* Sample rate */
  unsigned int exact_rate; /* Sample rate returned by */
  /* Handle for the PCM device */
  snd_pcm_t *playback_handle;
  /* Playback stream */
  snd_pcm_stream_t stream = SND_PCM_STREAM_PLAYBACK;
  /* This structure contains information about the hardware and can be used to specify the configuration to be used for */
  /* the PCM stream. */
  snd_pcm_hw_params_t *hw_params;


The most important ALSA interfaces to the PCM devices are the "plughw" and the "hw" interface. If you use the "plughw" interface, you need not care much about the sound hardware. If your sound card does not support the sample rate or sample format you specify, your data will be automatically converted. This also applies to the access type and the number of channels. With the "hw" interface, you have to check whether your hardware supports the configuration you would like to use. Otherwise, user can use the default interface for playback by:


  /* Name of the PCM device, like plughw:0,0 */
  /* The first number is the number of the soundcard, the second number is the number of the device. */

  static char *device = "default"; /* playback device */



Now we can open the PCM device:


  /* Open PCM. The last parameter of this function is the mode. */
  if ((err = snd_pcm_open (&playback_handle, device, stream, 0)) < 0) {
    fprintf (stderr, "cannot open audio device (%s)\n", snd_strerror (err));
    exit (1);
  }


Setting the parameters of the device

Now we initialize the variables and allocate the hwparams structure:


  /* Allocate the snd_pcm_hw_params_t structure on the stack. */
  if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0) {
    fprintf (stderr, "cannot allocate hardware parameters (%s)\n", snd_strerror (err));
    exit (1);
  }



Before we can write PCM data to the soundcard, we have to specify access type, sample format, sample rate, number of channels, number of periods and period size. First, we initialize the hwparams structure with the full configuration space of the soundcard:


  /* Init hwparams with full configuration space */
  if ((err = snd_pcm_hw_params_any (playback_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot initialize hardware parameter structure (%s)\n", snd_strerror (err));
    exit (1);
  }


Now configure the desired parameters. For this example, we assume that the soundcard can be configured for stereo playback of 16 Bit Little Endian data, sampled at 44100 Hz. Therefore, we restrict the configuration space to match this configuration only. The access type specifies the way in which multi-channel data is stored in the buffer. For INTERLEAVED access, each frame in the buffer contains the consecutive sample data for the channels. For 16 Bit stereo data, this means that the buffer contains alternating words of sample data for the left and right channel.


  /* Set access type. */
  if ((err = snd_pcm_hw_params_set_access (playback_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0) {
    fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set sample format */
  if ((err = snd_pcm_hw_params_set_format (playback_handle, hw_params, SND_PCM_FORMAT_S16_LE)) < 0) {
    fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set sample rate. If the exact rate is not supported by the hardware, use nearest possible rate. */
  exact_rate = rate;
  if ((err = snd_pcm_hw_params_set_rate_near (playback_handle, hw_params, &exact_rate, 0)) < 0) {
    fprintf (stderr, "cannot set sample rate (%s)\n", snd_strerror (err));
    exit (1);
  }

  if (rate != exact_rate) {
    fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n ==> Using %d Hz instead.\n", rate, exact_rate);
  }

  /* Set number of channels */
  if ((err = snd_pcm_hw_params_set_channels (playback_handle, hw_params, 2)) < 0) {
    fprintf (stderr, "cannot set channel count (%s)\n", snd_strerror (err));
    exit (1);
  }



Now we apply the configuration to the PCM device pointed to by pcm_handle and prepare the PCM device.

  /* Apply HW parameter settings to PCM device and prepare device. */
  if ((err = snd_pcm_hw_params (playback_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot set parameters (%s)\n", snd_strerror (err));
    exit (1);
  }

  snd_pcm_hw_params_free (hw_params);

  if ((err = snd_pcm_prepare (playback_handle)) < 0) {
    fprintf (stderr, "cannot prepare audio interface for use (%s)\n", snd_strerror (err));
    exit (1);
  }


Writing data to the device

After the PCM device is configured, we can start writing PCM data to it. The first write access will start the PCM playback. For interleaved write access, we use the function:


  /* Write some junk data to produce sound. */
  if ((err = snd_pcm_writei (playback_handle, buf, BUFF_SIZE/2)) != BUFF_SIZE/2) {
    fprintf (stderr, "write to audio interface failed (%s)\n", snd_strerror (err));
    exit (1); 
  } else {
    printf ("snd_pcm_writei successful\n");
  }



After the PCM playback is started, we have to make sure that our application sends enough data to the soundcard buffer. Otherwise, a buffer under-run will occur. After such an under-run has occurred, snd_pcm_prepare should be called.

Closing the device

After the data has been transferred, the device needs to be closed by calling:

  snd_pcm_close (playback_handle);

  exit (0);
}

A minimal record application

This program opens an audio interface for capture, configures it for stereo, 16 bit, 44.1kHz, interleaved conventional read/write access. Then its reads a chunk of random data from it, and exits. It isn't meant to be a real program. 

Note that it is not possible to use one pcm handle for both playback and capture. So you have to configure two handles if you want to access the PCM device in both directions.


#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>

#define BUFF_SIZE 4096

int main (int argc, char *argv[])
{
  int err;
  short buf[BUFF_SIZE];
  int rate = 44100; /* Sample rate */
  int exact_rate; /* Sample rate returned by */
  snd_pcm_t *capture_handle;

  /* This structure contains information about the hardware and can be used to specify the configuration to be used for */
  /* the PCM stream. */
  snd_pcm_hw_params_t *hw_params;

  /* Name of the PCM device, like hw:0,0 */
  /* The first number is the number of the soundcard, the second number is the number of the device. */
  static char *device = "default"; /* capture device */

  /* Open PCM. The last parameter of this function is the mode. */
  if ((err = snd_pcm_open (&capture_handle, device, SND_PCM_STREAM_CAPTURE, 0)) < 0) {
    fprintf (stderr, "cannot open audio device (%s)\n", snd_strerror (err));
    exit (1);
  }

  memset(buf,0,BUFF_SIZE);

  /* Allocate the snd_pcm_hw_params_t structure on the stack. */
  if ((err = snd_pcm_hw_params_malloc (&hw_params)) < 0) {
    fprintf (stderr, "cannot allocate hardware parameter structure (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Init hwparams with full configuration space */
  if ((err = snd_pcm_hw_params_any (capture_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot initialize hardware parameter structure (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set access type. */
  if ((err = snd_pcm_hw_params_set_access (capture_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED)) < 0) {
    fprintf (stderr, "cannot set access type (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Set sample format */
  if ((err = snd_pcm_hw_params_set_format (capture_handle, hw_params, SND_PCM_FORMAT_S16_LE)) < 0) {
    fprintf (stderr, "cannot set sample format (%s)\n", snd_strerror (err)); 
    exit (1);
  }

  /* Set sample rate. If the exact rate is not supported by the hardware, use nearest possible rate. */
  exact_rate = rate;
  if ((err = snd_pcm_hw_params_set_rate_near (capture_handle, hw_params, &exact_rate, 0)) < 0) {
    fprintf (stderr, "cannot set sample rate (%s)\n", snd_strerror (err));
    exit (1);
  }

  if (rate != exact_rate) {
    fprintf(stderr, "The rate %d Hz is not supported by your hardware.\n ==> Using %d Hz instead.\n", rate, exact_rate);
  }

  /* Set number of channels */
  if ((err = snd_pcm_hw_params_set_channels(capture_handle, hw_params, 2)) < 0) {
    fprintf (stderr, "cannot set channel count (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Apply HW parameter settings to PCM device and prepare device. */
  if ((err = snd_pcm_hw_params (capture_handle, hw_params)) < 0) {
    fprintf (stderr, "cannot set parameters (%s)\n", snd_strerror (err));
    exit (1);
  }

  snd_pcm_hw_params_free (hw_params);

  if ((err = snd_pcm_prepare (capture_handle)) < 0) {
    fprintf (stderr, "cannot prepare audio interface for use (%s)\n", snd_strerror (err));
    exit (1);
  }

  /* Read data into the buffer. */
  if ((err = snd_pcm_readi (capture_handle, buf, 128)) != 128) {
    fprintf (stderr, "read from audio interface failed (%s)\n", snd_strerror (err));
    exit (1);
  } else {
    printf ("snd_pcm_readi successful\n");
  }

  snd_pcm_close (capture_handle);

  exit (0);
}

ALSA UserSpace Library (Useful Commands)

For each utility the --help option provides a comprehensive list of command-line options for arecord, aplay and amixer. Some of the more useful ones are listed below :

aplay

  • aplay <<file_name>> & : plays a wave file with the sample-rate/pcm-word size info available in the wav header.
  • aplay -l : prints information on all the audio cards available
  • aplay <<file_name>> -N &: playback in non-blocking mode
  • aplay <<file_name>> -M &: playback in memory-mapped (m-mapped) mode
  • aplay --buffer_size=<<buffer_size>> <<file_name>> &: playback using different buffer-sizes
  • aplay -r <<sample_rate>> -c <<no_of_channels>> <<file_name>> -f <<sample_format>>& : play using different sample rates and no. of channels or sample formats

Recognized sample-formats are: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE IEC958_SUBFRAME_LE IEC958_SUBFRAME_BE MU_LAW A_LAW IMA_ADPCM MPEG GSM SPECIAL S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE


arecord

  • arecord -f cd <<file_name>> &: record in the "CD" (i,e. 16 bit LE, 44100 hz, stereo) format
  • arecord -l:prints information on all the audio cards available
  • arecord -r <<sample_rate>> -c <<no_of_channels>> -f <<sample_format>> <<file_name>> &: record in the specified sample-rate and no. of channels or in the sample format indicated.


The sample-formats are as indicated for aplay.

Some recognized shortcuts are:

  • -f cd (16 bit little endian, 44100, stereo)
  • -f cdr (16 bit big endian, 44100, stereo)
  • -f dat (16 bit little endian, 48000, stereo)
  • arecord <<file_name>> -N &: record in non-blocking mode
  • arecord <<file_name>> -M &:record in memory-mapped (m-mapped) mode
  • arecord --buffer_size=<<buffer_size>> <<file_name>> &: record using different buffer-sizes

Loopback command -

arecord -f cd | aplay &: record in "CD" format (see below for details) and play the recorded data i,e. software loopback

amixer

  • amixer controls:show all controls for given card
  • amixer contents:show contents of all controls for given card