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驅動框架相結合才能工作.
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驅動的工作細節和關聯.
本文轉自:http://blog.csdn.net/droidphone/article/details/7165482