Linux ALSA音效卡驅動之五:行動裝置中的ALSA(ASoC)

來源:互聯網
上載者:User

標籤:軟體架構   等等   block   做了   配置資訊   描述   朋友   頻率   作用   

轉自http://blog.csdn.net/droidphone/article/details/71654821.  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驅動的工作細節和關聯。

Linux ALSA音效卡驅動之五:行動裝置中的ALSA(ASoC)

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.