Android Audio Tutorial [Part One] : Introduction

Sound Card.

A sound card (also known as an audio card) is an internal expansion card that provides input and output of audio signals to and from a computer under control of computer programs. The term sound card is also applied to external audio interfaces used for professional audio applications.

Sound functionality can also be integrated onto the motherboard, using components similar to those found on plug-in cards. The integrated sound system is often still referred to as a sound card. Sound processing hardware is also present on modern video cards with HDMI to output sound along with the video using that connector; previously they used a SPDIF connection to the motherboard or sound card.

Typical uses of sound cards or sound card functionality include providing the audio component for multimedia applications such as music composition, editing video or audio, presentation, education and entertainment (games) and video projection. Sound cards are also used for computer-based communication such as voice over IP and teleconferencing.

If the sound card itself does not have a main processing chip, but only the decoding chip, it needs to perform processing through the CPU operation, then it is a "soft sound card".

Computers that typically target the low-end market will include an integrated sound card device to reduce costs.

A typical sound card usually contains three parts:

Connectors

Used for connection between sound card and external equipment such as speakers and headphones, also known as “jacks”.

Audio Circuits

The main implementation of the sound card, which is responsible for signal amplification, mixing and analog digital conversion operations.

Interface

The unit that connects the sound card to the computer bus, such as the PCI bus

We can use the "cat/proc/asound/cards" command to see the sound card devices installed in a computer, as shown in the following figure below:

Android is a Linux based system and it depends on various device driver support provided by the kernel, including the audio drivers. 

Let us take some time to learn the two main audio driver architectures under the Linux platform.

Open Sound System

The Open Sound System (OSS) is an interface for making and capturing sound in Unix and Unix-like operating systems. It is based on standard Unix devices system calls (i.e. POSIX read, write, ioctl, etc.). The term also sometimes refers to the software in a Unix kernel that provides the OSS interface; it can be thought of as a device driver (or a collection of device drivers) for sound controller hardware. The goal of OSS is to allow the writing of sound-based applications that are agnostic of the underlying sound hardware.

OSS was created by Hannu Savolainen and is distributed under four license options, three of which are free software licences, thus making OSS free software.

API

The API is designed to use the traditional Unix framework of open(), read(), write(), and ioctl(), via special devices. 

For instance, the default device for sound input and output is /dev/dsp.

Examples using the shell:

cat /dev/random > /dev/dsp # plays white noise through the speaker

cat /dev/dsp > a.a # reads data from the microphone and copies it to file a.a

Some of the Nodes used by OSS are.

a.     /dev/dsp

1.     Write data to this file “output to loud speaker”

2.     Read data to this file “Record from Microphone”

b.     /dev/mixer

1.     Mixer for related settings of audio equipment, such as volume adjustment

c.     /dev/midi00

1.     The first MIDI port, midi01, midi02, and so on

d.     /dev/sequencer

1.     Used to access synthesizers, often used to create effects used in games etc

Some of the limitations of OSS which make it a little unfavorable when compared to its peers like ALSA are.

a.     Insufficient support for new audio features.

b.     Lack of support for the latest kernel features and more.

ALSA (Advanced Linux Sound Architecture).

AdvancedLinux Sound Architecture (ALSA) is a software framework and part of the Linux kernel that provides an application programming interface (API) for sound card device drivers.

Some of the goals of the ALSA project at its inception were automatic configuration of sound-card hardware and graceful handling of multiple sound devices in a system. ALSA is released under the GNU General Public License (GPL) and the GNU Lesser General Public License (LGPL).

The sound servers PulseAudio and JACK (low-latency professional-grade audio editing and mixing), the higher-level abstraction APIs OpenAL, SDL audio, etc. work on top of ALSA and implemented sound card device drivers. On Linux systems, ALSA succeeded the older Open Sound System (OSS).

Features

ALSA was designed with some features which were not, at the time of its conception, supported by OSS:

a.     Hardware-based MIDI synthesis.

b.     Hardware mixing of multiple channels.

c.     Full-duplex operation.

d.     Multiprocessor-friendly, thread-safe device drivers.

ALSA has a larger and more complex API than OSS, so it can be more difficult to develop an application that uses ALSA as its sound technology. While ALSA may be configured to provide an OSS emulation layer, such functionality is no longer available or is not installed by default in many Linux distributions.

Besides the sound device drivers, ALSA bundles a user-space library for application developers who want to use driver features through an interface that is higher-level than the interface provided for direct interaction with the kernel drivers. Unlike the kernel API, which tries to reflect the capabilities of the hardware directly, ALSA's user-space library presents an abstraction that remains as standardized as possible across disparate underlying hardware elements.

 Some of the components in the alsa-project are.

Component	Description
alsa-driver	Kernel driver package
alsa-lib	User space function library
alsa-utils	Contains many useful components, such as
	alsactl: used to save device settings
	amixer: is a command line program for volume and other sound controls
	alsamixer: the ncurses version of amixer
	aplay and arecord: two command line programs for playing and recording multiple formats of audio
alsa-tools	Contains misc tools
alsa-firmware	Audio Firmware Support Package
alsa-plugins	Plug-in packages such as jack, pulse etc
alsa-oss	OSS-compatible analog package
pyalsa	Alsa lib for compiling Python versions

Alsa's main file nodes are as follows:

a.     Information Interface (/proc/asound)

b.     Control Interface (/dev/snd/controlCx)

c.     Mixer Interface (/dev/snd/mixerCxDy)

d.     PCM Interface (/dev/snd/pcmCxDy)

e.     Raw MIDI Interface (/dev/snd/midiCxDy)

f.      Sequencer Interface (/dev/snd/seq)

g.     Timer Interface (/dev/snd/timer)

Where, 

Cx refers to CARD number x.

Dy refers to DEVICE number y.

For more details on the alsa-project please check.

http://git.alsa-project.org/

TinyALSA.

TinyALSA is a small library to interface with ALSA in the Linux kernel.

The aims are:

a.     Provide a basic pcm and mixer API.

b.     If it's not absolutely needed, don't add it to the API.

c.     Avoid supporting complex and unnecessary operations, that could be dealt with at a higher level.

d.     Provide comprehensive documentation.

  

We can see in the external/tinyalsa directory which contains a few of the few source files.

Android.mk	Android Makefile
mixer.c	Mixer Interface implementation
pcm.c	PCM Interface implementation
tinycap.c	Capture tool
tinymix.c	Mixer tool
tinyplay.c	Play Tool
Include/tinyalsa/asoundlib.h	header File

TinyAlsa is a stripped down version of alsa and does not support many interfaces like sequencer etc.

Audio Framework in Android.

The android audio subsystem decouples the userspace and kernel space implementation. 

The following diagram represents the architecture in a very simple way.

Let us briefly talk about some of the components we saw in the above figure.

Application.

This is the audio application like Mediaplayer/Youtube/A game which tries to play some sound etc.

 Framework.

Since we already have some fair idea of the Android system. We can think MediaPlayer and MediaRecorder. They are the most widely used classes for playing ore recording audio on Android system.

In fact, Android also provides two other similar classes AudioTrack and AudioRecorder.

In addition, the Android system also provides AudioManager, AudioService, and AudioSystem classes for our control of audio systems. 

Audio HAL

From a design point of view, the hardware abstraction layer is directly accessed by AudioFlinger to talk to the Linux kernel drivers. 

We will analyze all of these when we take a deep dive in Android audio architecture.