立你斯學習記錄

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原創，轉載請注明出處，謝謝！
原文出處
http://blog.csdn.net/droidphone/article/details/7165482
/*****************************************************************************************************/