Linux ALSA audio card driver 5: ALSA (ASOC) in mobile devices)

1. Origin of ASOC

ASOC-ALSA system on chip is a software system built on the standard ALSA driver layer to better support audio codec in embedded processors and mobile devices. Before the emergence of ASOC, the kernel had some support for the audio in the SOC, but there were some limitations:

• The underlying coupling between the codec driver and the soc cpu is too tight. This kind of imperfection will lead to code duplication. For example, it is only a wm8731 driver. At that time, there were driver code for four platforms in Linux.
• There is no standard way to notify users of Audio events, such as plug-in and detection of headphones and microphones. These events are very common on mobile devices, generally, you need to re-configure the audio path strength based on the machine-specific code.
• When playing a video or recording a video, the driver puts the entire codec on power, which is no problem for the PC, but for mobile devices, this means a lot of power is wasted. At the same time, it does not support power saving by changing the sampling frequency and offset current.

ASOC was proposed to solve the above problems and has been integrated into the kernel code tree: Sound/SOC. ASOC cannot exist independently. It is only built on the standard ALSA driver. It must be combined with the standard ALSA driver framework to work.

/*************************************** **************************************** *************/
Statement: the content of this blog is created at http://blog.csdn.net/droidphone. please refer to it for help. Thank you!
/*************************************** **************************************** *************/

2. hardware architecture

Generally, like abstraction and reuse in the software field, the audio systems of embedded devices can be divided into three parts: On-board hardware (MACHINE), SOC (Platform), and codec, as shown in:

Figure 2.1 Audio System Structure

• MachineA machine can be a device, a Development Board, or a smart phone. It can be seen that the machine is almost reusable, the hardware implementation on each machine may be different, the CPU is different, codec is different, and the audio input and output devices are different. The machine provides a carrier for the CPU, codec, and input and output devices.
• PlatformGenerally, it refers to a SOC platform, such as pxaxxx, s3cxxxx, and omapxxx. Audio-related information usually includes the clock, DMA, I2S, and PCM In the SOC. If SOC is specified, so we can think that it will have a corresponding platform, which is only related to SOC and has nothing to do with the machine. In this way, we can abstract the platform so that the same SOC does not need to be changed, it can be used in different machines. In fact, it is better to think of platform as a Soc.
• CodecCodec contains the I2S interface, D/A, A/D, mixer, and Pa ), it usually contains multiple inputs (MIC, line-in, I2S, PCM) and multiple outputs (headset, speaker, receiver, line-out). codec is the same as platform, it is a reusable component, and the same codec can be used by different machines. Embedded codec usually controls internal registers through I2C.

3. Software Architecture

At the software level, ASOC also divides the audio system of embedded devices into three parts: machine, platform, and codec.

• Codec driverAn important design principle in ASOC is that the codec driver is platform-independent. It includes some audio controls (controls), audio interfaces, and damp (Dynamic Audio Power Management) definition and some codec Io functions. To ensure hardware independence, any code specific to the platform and machine must be moved to the platform and machine drivers. All codec drivers must provide the following features:
  • Codec Dai and PCM configuration information;
  • Codec Io control mode (I2C, SPI, etc );
  • Mixer and other audio controls;
  • ALSA audio operation interface of codec;

If necessary, you can also provide the following functions:

• Dapm description;
• Dapm event handler;
• DAC digital mute Control

• Platform driverIt includes the configuration and control of the audio DMA and audio interfaces of the SoC Platform (I2S, PCM, ac97, etc.); it cannot contain any Code related to the Board or machine.
• Machine driverThe machine driver is responsible for processing the control and Audio events specific to the machine (for example, an amplifier must be enabled before playing the audio). The independent platform and CODEC drivers cannot work, it must be combined by the machine driver to complete the audio processing of the entire device.

4. Data Structure

The entire ASOC is composed of several column data structures. To understand the working mechanism of ASOC, we must understand the relationships and functions between these data structures, the following diagram shows the association between important data structures in ASOC:

Figure 4.1 static relationships between structures in a Kernel-2.6.35-ASoC

ASOC implements the sound card as a platform device, and then uses the dev field in the platform_device structure: Dev. drvdata, which actually points to a snd_soc_device structure. It can be considered that snd_soc_device is the root of the entire ASOC data structure. Starting from this, a series of data structures are introduced to express various audio features and functions. The snd_soc_device structure introduces the snd_soc_card and soc_codec_device structures. Then, snd_soc_card introduces the snd_soc_platform, snd_soc_dai_link, and snd_soc_codec structures. As mentioned above, ASOC is divided into three parts: machine, platform, and CODEC. From these data structures, snd_codec_device and snd_soc_card represent the machine driver, while snd_soc_platform represents the platform driver, snd_soc_codec and soc_codec_device represent the codec driver, while snd_soc_dai_link is responsible for connecting platform and codec.

5. Improvements to ASOC in kernel 3.0

When I wrote this article, I used to refer to the kernel version 2.6.35. However, some csdn friends suggested that ASOC has made major changes in kernel version 3.0. Therefore, I downloaded the code 3.0 and found that the Code has changed. Next I will post the static relationship diagram of the data structure:

Figure 5.1 ASOC Data Structure in kernel 3.0

We can see that the data structure in 3.0 is more reasonable and clear. The snd_soc_device structure is removed, snd_soc_card is replaced directly, and the role of snd_soc_pcm_runtime is enhanced, two other data structures, snd_soc_codec_driver and snd_soc_platform_driver, are added to explicitly represent the codec driver and platform driver.

 

The following sections will introduce the work details and associations of the machine, platform, and CODEC drivers one by one.