IntroductiontoSoundProgrammingwithALSA.docx

1、IntroductiontoSoundProgrammingwithALSAIntroduction to Sound Programming with ALSAALSA stands for the Advanced Linux Sound Architecture. It consists of a set of kernel drivers, an application programming interface (API) library and utility programs for supporting sound under Linux. In this article, I

2、 present a brief overview of the ALSA Project and its software components. The focus is on programming the PCM interfaces of ALSA, including programming examples with which you can experiment.You may want to explore ALSA simply because it is new, but it is not the only sound API available. ALSA is a

3、 good choice if you are performing low-level audio functions for maximum control and performance or want to make use of special features not supported by other sound APIs. If you already have written an audio application, you may want to add native support for the ALSA sound drivers. If your primary

4、 interest isnt audio and you simply want to play sound files, using one of the higher-level sound toolkits, such as SDL, OpenAL or those provided in desktop environments, may be a better choice. By using ALSA you are restricted to using systems running a Linux kernel with ALSA support.History of ALS

5、AThe ALSA Project was started because the sound drivers in the Linux kernel (OSS/Free drivers) were not being maintained actively and were lagging behind the capabilities of new sound technology. Jaroslav Kysela, who previously had written a sound card driver, started the project. Over time, more de

6、velopers joined, support for many sound cards was added and the structure of the API was refined.During development of the 2.5 series of Linux kernel, ALSA was merged into the official kernel source. With the release of the 2.6 kernel, ALSA will be part of the stable Linux kernel and should be in wi

7、de use.Digital Audio BasicsSound, consisting of waves of varying air pressure, is converted to its electrical form by a transducer, such as a microphone. An analog-to-digital converter (ADC) converts the analog voltages into discrete values, called samples, at regular intervals in time, known as the

8、 sampling rate. By sending the samples to a digital-to-analog converter and an output transducer, such as a loudspeaker, the original sound can be reproduced.The size of the samples, expressed in bits, is one factor that determines how accurately the sound is represented in digital form. The other m

9、ajor factor affecting sound quality is the sampling rate. The Nyquist Theorem states that the highest frequency that can be represented accurately is at most one-half the sampling rate.ALSA BasicsALSA consists of a series of kernel device drivers for many different sound cards, and it also provides

10、an API library, libasound. Application developers are encouraged to program using the library API and not the kernel interface. The library provides a higher-level and more developer-friendly programming interface along with a logical naming of devices so that developers do not need to be aware of l

11、ow-level details such as device files.In contrast, OSS/Free drivers are programmed at the kernel system call level and require the developer to specify device filenames and perform many functions using ioctl calls. For backward compatibility, ALSA provides kernel modules that emulate the OSS/Free so

12、und drivers, so most existing sound applications continue to run unchanged. An emulation wrapper library, libaoss, is available to emulate the OSS/Free API without kernel modules.ALSA has a capability called plugins that allows extension to new devices, including virtual devices implemented entirely

13、 in software. ALSA provides a number of command-line utilities, including a mixer, sound file player and tools for controlling special features of specific sound cards.ALSA ArchitectureThe ALSA API can be broken down into the major interfaces it supports: Control interface: a general-purpose facilit

14、y for managing registers of sound cards and querying the available devices. PCM interface: the interface for managing digital audio capture and playback. The rest of this article focuses on this interface, as it is the one most commonly used for digital audio applications. Raw MIDI interface: suppor

15、ts MIDI (Musical Instrument Digital Interface), a standard for electronic musical instruments. This API provides access to a MIDI bus on a sound card. The raw interface works directly with the MIDI events, and the programmer is responsible for managing the protocol and timing. Timer interface: provi

16、des access to timing hardware on sound cards used for synchronizing sound events. Sequencer interface: a higher-level interface for MIDI programming and sound synthesis than the raw MIDI interface. It handles much of the MIDI protocol and timing. Mixer interface: controls the devices on sound cards

17、that route signals and control volume levels. It is built on top of the control interface.Device NamingThe library API works with logical device names rather than device files. The device names can be real hardware devices or plugins. Hardware devices use the format hw:i,j, where i is the card numbe

18、r and j is the device on that card. The first sound device is hw:0,0. The alias default refers to the first sound device and is used in all of the examples in this article. Plugins use other unique names; plughw:, for example, is a plugin that provides access to the hardware device but provides feat

19、ures, such as sampling rate conversion, in software for hardware that does not directly support it. The dmix and dshare plugins allow you to downmix several streams and split a single stream dynamically among different applications.Sound Buffers and Data TransferA sound card has a hardware buffer th

20、at stores recorded samples. When the buffer is sufficiently full, it generates an interrupt. The kernel sound driver then uses direct memory access (DMA) to transfer samples to an application buffer in memory. Similarly, for playback, another application buffer is transferred from memory to the soun

21、d cards hardware buffer using DMA.These hardware buffers are ring buffers, meaning the data wraps back to the start when the end of the buffer is reached. A pointer is maintained to keep track of the current positions in both the hardware buffer and the application buffer. Outside of the kernel, onl

22、y the application buffer is of interest, so from here on we discuss only the application buffer.The size of the buffer can be programmed by ALSA library calls. The buffer can be quite large, and transferring it in one operation could result in unacceptable delays, called latency. To solve this, ALSA

23、 splits the buffer up into a series of periods (called fragments in OSS/Free) and transfers the data in units of a period.A period stores frames, each of which contains the samples captured at one point in time. For a stereo device, the frame would contain samples for two channels. Figure 1 illustra

24、tes the breakdown of a buffer into periods, frames and samples with some hypothetical values. Here, left and right channel information is stored alternately within a frame; this is called interleaved mode. A non-interleaved mode, where all the sample data for one channel is stored followed by the da

25、ta for the next channel, also is supported.Figure 1. The Application BufferOver and Under RunWhen a sound device is active, data is transferred continuously between the hardware and application buffers. In the case of data capture (recording), if the application does not read the data in the buffer

26、rapidly enough, the circular buffer is overwritten with new data. The resulting data loss is known as overrun. During playback, if the application does not pass data into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. The ALSA documentation sometimes r

27、efers to both of these conditions using the term XRUN. Properly designed applications can minimize XRUN and recover if it occurs.A Typical Sound ApplicationPrograms that use the PCM interface generally follow this pseudo-code:open interface for capture or playbackset hardware parameters(access mode,

28、 data format, channels, rate, etc.)while there is data to be processed: read PCM data (capture) or write PCM data (playback)close interfaceWe look at some working code in the following sections. I recommend you compile and run these on your Linux system, look at the output and try some of the sugges

29、ted modifications. The full listings for the example programs that accompany this article are available for download from Listing 1. Display Some PCM Types and Formats#include int main() int val; printf(ALSA library version: %sn, SND_LIB_VERSION_STR); printf(nPCM stream types:n); for (val = 0; val =

30、 SND_PCM_STREAM_LAST; val+) printf( %sn, snd_pcm_stream_name(snd_pcm_stream_t)val); printf(nPCM access types:n); for (val = 0; val = SND_PCM_ACCESS_LAST; val+) printf( %sn, snd_pcm_access_name(snd_pcm_access_t)val); printf(nPCM formats:n); for (val = 0; val = SND_PCM_FORMAT_LAST; val+) if (snd_pcm_f

31、ormat_name(snd_pcm_format_t)val) != NULL) printf( %s (%s)n, snd_pcm_format_name(snd_pcm_format_t)val), snd_pcm_format_description( (snd_pcm_format_t)val); printf(nPCM subformats:n); for (val = 0; val = SND_PCM_SUBFORMAT_LAST; val+) printf( %s (%s)n, snd_pcm_subformat_name( snd_pcm_subformat_t)val),

32、snd_pcm_subformat_description( snd_pcm_subformat_t)val); printf(nPCM states:n); for (val = 0; val = SND_PCM_STATE_LAST; val+) printf( %sn, snd_pcm_state_name(snd_pcm_state_t)val); return 0;Listing 1 displays some of the PCM data types and parameters used by ALSA. The first requirement is to include the header file that brings in the definitions for all of the ALSA library functions. One of the definit