Bowen from Http://blog.csdn.net/droidphone Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
1. Origin of Asoc
Asoc--alsa system on Chip is built on a standard ALSA drive layer to better support a software system for embedded processors and audio codec in mobile devices. Before ASOC, the kernel had some support for audio in the SOC, but there were some limitations: the codec drive was too tightly coupled to the bottom of the SOC CPU, which would cause duplication of code, for example, only the wm8731 driver, There were 4 platform-specific driver codes in Linux at that time. There is no standard way to notify users of audio events, such as headphones, microphone insertion and detection, which are very common in mobile devices and typically require machine-specific code to reconfigure the audio path. When playing or recording, the driver will put the entire codec on the power state, which is no problem for the PC, but for mobile devices, this means wasting a lot of electricity. It also does not support the purpose of saving electricity by changing the sampling frequency and bias current.
ASOC, which is proposed to solve these problems, has now been integrated into the kernel's code tree: Sound/soc. ASOC cannot exist alone, he is only built on a standard ALSA drive it must be combined with a standard ALSA drive framework to work. 2. Hardware architecture
Often, like abstraction and reuse in the software domain, the audio system of an embedded device can be divided into on-board hardware (Machine), Soc (Platform), codec, as shown in the following illustration:
&N Bsp 2.1 audio system structure machine refers to a certain type of machine , can be a certain equipment, a development board, or a smart phone, which can be seen machine is almost not reusable, each machine hardware implementation may be different, the CPU is not the same, codec different, audio input, output devices are not the same, Machine provides a carrier for CPU, CODEC and input. platform generally refers to a certain SOC platform, such as pxaxxx,s3cxxxx,omapxxx and so on, and audio-related usually contains the clock in the SOC, DMA, I2S, PCM and so on, as long as the designation of the SOC, Then we can think that it will have a corresponding platform, it is only related to the SOC, and machine, so we can abstract platform, so that the same SOC do not make any changes, can be used in different machine. In fact, it's better to think of platform as a certain soc. codec literal meaning is codec, Codec contains I2S interface, D/A, A/D, Mixer, PA (AMP), usually contains a variety of input (Mic, Line-in, I2S, PCM) and multiple output (headphones, speakers, handsets, Line-out), codec and platform, are reusable parts, and the same codec can be used by different machine. The embedded codec usually control the internal registers through the I2C. 3. software Architecture
At the software level, ASOC also divides the audio systems of embedded devices into 3 parts, Machine,platform and codec. An important design principle in codec driver ASOC is that the codec driver is platform independent, it contains some audio control (Controls), audio interface, damp (dynamic audio power management) definition and some codec IO features. To ensure hardware independence, any platform-and machine-specific code is moved to the platform and machine drivers. All CODEC drivers are provided with the following characteristics: Codec DAI and PCM configuration information, Codec IO control (I2C,SPI, etc.), mixer and other audio controls; Codec ALSA audio Operation interface;
When necessary, you can also provide the following functions: DAPM description information; DAPM event handler; DAC digital mute control platform Drive it contains the configuration and control of audio DMA and audio interfaces for the SOC platform (I2S,PCM,AC97, etc.) ; It also cannot contain any code associated with the board or machine. The machine driver Machine driver is responsible for handling some of the machine-specific controls and audio events (for example, when audio is played, an amplifier needs to be opened first); The individual platform and codec drivers are not working, 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 a number of column data structures, to understand the working mechanism of the ASOC, you must be aware of the relationship between this series of data structure and role, the following diagram shows the important data structure in ASOC the association between the way:
Graph 4.1 Static relation of each structure in KERNEL-2.6.35-ASOC
ASOC the sound card as a platform Device, and then utilizes 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 fundamental of the entire ASOC data structure, and begins with a series of data structures to describe various features and functions of audio. The Snd_soc_device structure leads to two structures of Snd_soc_card and Soc_codec_device, and then Snd_soc_card leads to Snd_soc_platform, Snd_soc_dai_link and Snd_. SOC_CODEC structure. As mentioned above, ASOC is divided into three parts, machine, platform and codec, and if viewed from these data structures, Snd_codec_device and snd_soc_card represent machine-driven, SND_SOC_ The platform represents the platform drive, while the Snd_soc_codec and Soc_codec_device represent the codec drive, while Snd_soc_dai_link is responsible for connecting platform and codec. 5.3.0 version of the kernel to ASOC improvement
Originally wrote this article when the reference to the kernel version is 2.6.35, but csdn friend proposed in the kernel version 3.0, ASOC made a big change. So deliberately downloaded 3.0 of the code, found that there is indeed a change, the following first paste the data structure of the static diagram:
Figure 5.1 The ASOC data structure in Kernel 3.0
As we can see from the above figure, the data structure in 3.0 is more reasonable and clear, cancels the snd_soc_device structure, replaces it directly with Snd_soc_card, and strengthens the function of Snd_soc_pcm_runtime, Two additional data structures, Snd_soc_codec_driver and snd_soc_platform_driver, are also added to explicitly represent codec drives and platform drivers.