Linux ALSA sound card driver five: ALSA (ASoC) in mobile devices

Reprint address: https://blog.csdn.net/droidphone/article/details/7165482

1. The origin of ASoC

ASoC--ALSA System on Chip is a set of software system based on the standard ALSA driver layer to better support the audio Codec in embedded processors and mobile devices. Before the advent of ASoc, the kernel already had partial support for audio in the SoC, but there are some limitations:

  •    The Codec driver is too tightly coupled with the bottom layer of the SoC CPU, and this unsatisfactory will lead to code duplication. For example, it is only the driver of the wm8731. At that time, there were driver codes for 4 platforms in Linux.
  •    There is no standard way to notify the user of audio events, such as headphone, microphone plugging and unplugging, and detection, these events are very common in mobile devices and usually require machine-specific code to reconfigure the audio path.
  •   When playing or recording, the driver keeps the entire codec powered up, which is fine for PCs, but for mobile devices it means a lot of power wasted. At the same time, it does not support the purpose of saving power by changing the oversampling frequency and bias current.

ASoC is proposed to solve the above problems, and it has been integrated into the code tree of the kernel: sound/soc. ASoC cannot exist alone, it is just one built on the standard ALSA driver. It must be combined with the standard ALSA driver framework to work.

/**************************************************** ********************************************/
Statement: The contents of this blog are all Originally from http://blog.csdn.net/droidphone, please indicate the source for reprinting, thank you!
/**************************************************** ********************************************/

2. Hardware Architecture

Usually, just like abstraction and reuse in the software field, the audio system of embedded devices can be divided into three parts: onboard hardware (Machine), Soc (Platform), and Codec, as shown in the following figure:

                                        Figure 2.1 Audio system structure

  • Machine   refers to a certain machine, which can be a certain device, a certain development board, or a certain smartphone. It can be seen that the Machine is almost not reusable, and the hardware implementation on each Machine may be different. , The CPU is different, the Codec is different, and the audio input and output devices are also different. Machine provides a carrier for the CPU, Codec, and input and output devices.
  • Platform   generally refers to a certain SoC platform, such as pxaxxx, s3cxxxx, omapxxx, etc. Audio-related usually includes the clock, DMA, I2S, PCM, etc. in the SoC. As long as the SoC is specified, then we can think that it will have A corresponding Platform, which is only related to the SoC, has nothing to do with the Machine, so that we can abstract the Platform, so that the same SoC can be used in different Machines without any changes. In fact, it is better to think of Platform as a certain SoC.
  • Codec   literally means codec. Codec includes I2S interface, D/A, A/D, Mixer, PA (power amplifier), usually including multiple inputs (Mic, Line-in, I2S, PCM) and multiple For each output (headphone, speaker, earpiece, Line-out), Codec, like Platform, 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.

  • An important design principle in the Codec driver   ASoC is to require the Codec driver to be platform independent. It includes some audio controls (Controls), audio interfaces, DAMP (Dynamic Audio Power Management) definitions and some Codec IO functions. To maintain hardware independence, any platform- and machine-specific code is moved into Platform and Machine drivers. All Codec drivers provide the following features:
    • Codec DAI and PCM configuration information;
    • Codec's IO control method (I2C, SPI, etc.);
    • Mixer and other audio controls;
    • Codec's ALSA audio operation interface;

When necessary, the following functions can also be provided:

    • DAPM description information;
    • DAPM event handler;
    • DAC digital mute control
  • Platform driver   It contains the configuration and control of the audio DMA and audio interfaces of the SoC platform (I2S, PCM, AC97, etc.); it also cannot contain any board or machine related code.
  • Machine driver   Machine driver is responsible for handling some machine-specific controls and audio events (for example, when playing audio, you need to turn on an amplifier first); the Platform and Codec drivers alone will not work, it must be combined by the Machine driver. In order to complete the audio processing work of the entire device.

4. Data Structure

The entire ASoC is composed of a series of data structures. To understand the working mechanism of ASoC, it is necessary to understand the relationship and function between these series of data structures. The following diagram shows the relationship between important data structures in ASoC. :


                                                                                                      Figure 4.1 Static relationship of each structure in 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 him, a series of data structures are derived to express various features and functions of audio. The snd_soc_device structure leads to two structures, snd_soc_card and soc_codec_device, and then snd_soc_card leads to 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, snd_soc_platform represents the Platform driver, snd_soc_codec and soc_codec_device represent the Codec driver, and snd_soc_dai_link is responsible for connecting Platform and Codec.

5. Improvements to ASoC in version 3.0 kernel

When I wrote this article, the referenced kernel version was 2.6.35, but some friends from CSDN proposed that ASoC made major changes in the kernel version 3.0. I deliberately downloaded the 3.0 code and found that it has indeed changed. The static relationship diagram of the data structure is first posted below:


                                                                                             Figure 5.1 ASoC data structure in Kernel 3.0

As can be seen from the above figure, the data structure in 3.0 is more reasonable and clear, the snd_soc_device structure is cancelled, it is directly replaced with snd_soc_card, and the role of snd_soc_pcm_runtime is strengthened, and two other data structures, snd_soc_codec_driver and snd_soc_platform_driver, are also added. , used to explicitly represent the Codec driver and the Platform driver.

 

Subsequent chapters will introduce the details and associations of Machine and Platform and Codec-driven work one by one.

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324646641&siteId=291194637