Linux ALSA聲卡驅動之五：移動設備中的ALSA（ASoC）

轉自http://blog.csdn.net/droidphone/article/details/7165482

1.  ASoC的由來

ASoC--ALSA System on Chip ，是創建在標準ALSA驅動層上，爲了更好地支持嵌入式處理器和移動設備中的音頻Codec的一套軟件體系。在ASoc出現以前，內核對於SoC中的音頻已經有部分的支持，不過會有一些侷限性：

•    Codec驅動與SoC CPU的底層耦合過於緊密，這種不理想會致使代碼的重複，例如，僅是wm8731的驅動，當時Linux中有分別針對4個平臺的驅動代碼。
•    音頻事件沒有標準的方法來通知用戶，例如耳機、麥克風的插拔和檢測，這些事件在移動設備中是很是普通的，並且一般都須要特定於機器的代碼進行從新對音頻路勁進行配置。
•   當進行播放或錄音時，驅動會讓整個codec處於上電狀態，這對於PC沒問題，但對於移動設備來講，這意味着浪費大量的電量。同時也不支持經過改變過取樣頻率和偏置電流來達到省電的目的。

ASoC正是爲了解決上述種種問題而提出的，目前已經被整合至內核的代碼樹中：sound/soc。ASoC不能單獨存在，他只是創建在標準ALSA驅動上的一個它必須和標準的ALSA驅動框架相結合才能工做。

/********************************************************************************************/
聲明：本博內容均由http://blog.csdn.net/droidphone原創，轉載請註明出處，謝謝！
/********************************************************************************************/

2.  硬件架構

一般，就像軟件領域裏的抽象和重用同樣，嵌入式設備的音頻系統能夠被劃分爲板載硬件（Machine）、Soc（Platform）、Codec三大部分，以下圖所示：

                                        圖2.1  音頻系統結構

• Machine  是指某一款機器，能夠是某款設備，某款開發板，又或者是某款智能手機，由此能夠看出Machine幾乎是不可重用的，每一個Machine上的硬件實現可能都不同，CPU不同，Codec不同，音頻的輸入、輸出設備也不同，Machine爲CPU、Codec、輸入輸出設備提供了一個載體。
• Platform  通常是指某一個SoC平臺，好比pxaxxx,s3cxxxx,omapxxx等等，與音頻相關的一般包含該SoC中的時鐘、DMA、I2S、PCM等等，只要指定了SoC，那麼咱們能夠認爲它會有一個對應的Platform，它只與SoC相關，與Machine無關，這樣咱們就能夠把Platform抽象出來，使得同一款SoC不用作任何的改動，就能夠用在不一樣的Machine中。實際上，把Platform認爲是某個SoC更好理解。
• Codec  字面上的意思就是編解碼器，Codec裏面包含了I2S接口、D/A、A/D、Mixer、PA（功放），一般包含多種輸入（Mic、Line-in、I2S、PCM）和多個輸出（耳機、喇叭、聽筒，Line-out），Codec和Platform同樣，是可重用的部件，同一個Codec能夠被不一樣的Machine使用。嵌入式Codec一般經過I2C對內部的寄存器進行控制。 

3.  軟件架構

在軟件層面，ASoC也把嵌入式設備的音頻系統一樣分爲3大部分，Machine，Platform和Codec。

• Codec驅動  ASoC中的一個重要設計原則就是要求Codec驅動是平臺無關的，它包含了一些音頻的控件（Controls），音頻接口，DAMP（動態音頻電源管理）的定義和某些Codec IO功能。爲了保證硬件無關性，任何特定於平臺和機器的代碼都要移到Platform和Machine驅動中。全部的Codec驅動都要提供如下特性：
  • Codec DAI 和 PCM的配置信息；
  • Codec的IO控制方式（I2C，SPI等）；
  • Mixer和其餘的音頻控件；
  • Codec的ALSA音頻操做接口；

必要時，也能夠提供如下功能：

• • DAPM描述信息；
  • DAPM事件處理程序；
  • DAC數字靜音控制

• Platform驅動  它包含了該SoC平臺的音頻DMA和音頻接口的配置和控制（I2S，PCM，AC97等等）；它也不能包含任何與板子或機器相關的代碼。
• Machine驅動  Machine驅動負責處理機器特有的一些控件和音頻事件（例如，當播放音頻時，須要先行打開一個放大器）；單獨的Platform和Codec驅動是不能工做的，它必須由Machine驅動把它們結合在一塊兒才能完成整個設備的音頻處理工做。

4.  數據結構

整個ASoC是由一些列數據結構組成，要搞清楚ASoC的工做機理，必需要理解這一系列數據結構之間的關係和做用，下面的關係圖展現了ASoC中重要的數據結構之間的關聯方式：

                                                                                                      圖4.1  Kernel-2.6.35-ASoC中各個結構的靜態關係

 ASoC把聲卡實現爲一個Platform Device，而後利用Platform_device結構中的dev字段：dev.drvdata，它實際上指向一個snd_soc_device結構。能夠認爲snd_soc_device是整個ASoC數據結構的根本，由他開始，引出一系列的數據結構用於表述音頻的各類特性和功能。snd_soc_device結構引出了snd_soc_card和soc_codec_device兩個結構，而後snd_soc_card又引出了snd_soc_platform、snd_soc_dai_link和snd_soc_codec結構。如上所述，ASoC被劃分爲Machine、Platform和Codec三大部分，若是從這些數據結構看來，snd_codec_device和snd_soc_card表明着Machine驅動，snd_soc_platform則表明着Platform驅動，snd_soc_codec和soc_codec_device則表明了Codec驅動，而snd_soc_dai_link則負責鏈接Platform和Codec。

5.  3.0版內核對ASoC的改進

原本寫這篇文章的時候參考的內核版本是2.6.35，不過有CSDN的朋友提出在內核版本3.0版本中，ASoC作了較大的變化。故特地下載了3.0的代碼，發現確實有所變化，下面先貼出數據結構的靜態關係圖：

                                                                                             圖5.1   Kernel 3.0中的ASoC數據結構

由上圖咱們能夠看出，3.0中的數據結構更爲合理和清晰，取消了snd_soc_device結構，直接用snd_soc_card取代了它，而且強化了snd_soc_pcm_runtime的做用，同時還增長了另外兩個數據結構snd_soc_codec_driver和snd_soc_platform_driver，用於明確表明Codec驅動和Platform驅動。

 

後續的章節中將會逐一介紹Machine和Platform以及Codec驅動的工做細節和關聯。