Android資料流詳解

Java端發起調用，MediaPlayer會轉至MediaPlayerService,然後會調用相應的解碼工具解碼後建立AudioTrack，所有待輸出的 AudioTrack在AudioFlinger：AudioMixer裡合成，然後通過AudioHAL（AudioHardwareInterface的實際實現者）傳到實際的硬體來實現播放。

 

http://www.arm9.org.ru/redirect.php?tid=698&goto=lastpost

linux_sound_alsa_Android+alsa音頻系統中的幾個問題

1.Android
＋alsa音頻體系大體結構：
    從alsa的角度由下往上看：linux中有alsa驅動層，其中，/sound/core/pcm_native.c檔案中的snd_pcm_f_ops是alsa驅動層對alsa_lib層的介面；Android
中有alsa_lib層（在donut/external/alsa_lib目錄下）和alsa應用程式層；
    從Android
的角度由下往上看：首先是cpp庫層，然後是架構層，最後是java應用程式層。庫層分3個部
分：首先是硬體介面層AudioHardwareInterface，其衍生類別負責調用alsa_lib介面，形成read、write等虛函數；其次是
音頻環層AudioFlinger,利用多態的性質調用硬體介面層AudioHardwareInterface衍生類別的read、write等虛函數並
最終管理read和write兩個線程。最後，是媒體錄音MediaRecorder和媒體播放層MediaPlayer。進入或啟用
read/write線程，實現錄音放音功能。
2.Android
中音頻設定檔問題：
    設定檔/system/etc/asound.conf
其實是alsa體系留的一手。alsa體系提供了這樣一種機制：應用程式層直接改變音頻codec的
寄存器，具體而言：linux驅動中建立snd_kcontrol_new控制結構，並關聯到codec寄存器，asound.conf
檔案通過控制結構名字，
就能關聯到寄存器，從而改變寄存器的值。asound.conf
檔案主要用來做Android
音訊路由控制：不同路由可以設定多個寄存器
的不同配置組合，形成不同的音頻通道，從而當路由改變時，底層codec通道隨之改變。
3.Android
中音頻採樣頻率、通道數問題：
    Android
向下強制設定：播放時，雙聲道(立體聲)，採樣頻率為44.1kHz,當SD卡中音頻檔案是單聲道或者頻率不是44.1kHz時，Android
會自動處理，使得送給驅動的資料流是雙聲道44.1kHz。錄音時，單聲道，採樣頻率固定為8kHz，因為手機上產生的一般是amr或者3gpp壓縮格式，檔案要盡量小，便於多媒體訊息等應用的傳輸。對做音頻驅動的同志來說就很好了，只需要悉心配置好兩種頻率。
4.音頻無聲：
    通用codec晶片wm9714、alc5620之類的都有迴環模式loopback，可以先用loopback模式把mic的錄音送到spk，有聲音說明
晶片大部分邏輯很正常；接著，應該調通控制介面，能讀寫codec寄存器；最後再調試I2S、ac97等數字介面。
在dma中斷中添加列印可以讓資料流一目瞭然。
5.音頻效果不好：
    通常是頻率問題，記住DAC、ADC的頻率必須設定好，他們一般由codec晶片中PLL分頻產生。有些晶片要求把ADC、DAC
等模組上電後，才能設定其頻率，否則無效，但是能寫入，這是極容易忽視的一個問題。削頂失真，調小音量可以解決。