Android系統(tǒng)Audio框架

1、Android系統(tǒng)Audio框架Android系統(tǒng)Audio框架介紹音頻基礎(chǔ)知識聲音有哪些重要屬性呢？1.響度(Loudness)響度就是人類可以感知到的各種聲音的大小，也就是音量。響度與聲波的振幅有直接關(guān)系。2.音調(diào)(Pitch)音調(diào)與聲音的頻率有關(guān)系，當(dāng)聲音的頻率越大時，人耳所感知到的音調(diào)就越高，否則就越低。3.音色(Quality)同一種樂器，使用不同的材質(zhì)來制作，所表現(xiàn)出來的音色效果是不一樣的，這是由物體本身的結(jié)構(gòu)特性所決定的。如何將各種媒體源數(shù)字化呢？音頻采樣將聲波波形信號通過ADC轉(zhuǎn)換成計算機支持的二進制的過程叫做音頻采樣(Audio Sampling)。采樣(Sampling)的

2、核心是把連續(xù)的模擬信號轉(zhuǎn)換成離散的數(shù)字信號。1.樣本(Sample)這是我們進行采樣的初始資料，比如一段連續(xù)的聲音波形。2.采樣器(Sampler)采樣器是將樣本轉(zhuǎn)換成終態(tài)信號的關(guān)鍵。它可以是一個子系統(tǒng)，也可以指一個操作過程，甚至是一個算法，取決于不同的信號處理場景。理想的采樣器要求盡可能不產(chǎn)生信號失真。3.量化(Quantization)采樣后的值還需要通過量化，也就是將連續(xù)值近似為某個范圍內(nèi)有限多個離散值的處理過程。因為原始數(shù)據(jù)是模擬的連續(xù)信號，而數(shù)字信號則是離散的，它的表達(dá)范圍是有限的，所以量化是必不可少的一個步驟。4.編碼(Coding)計算機的世界里，所有數(shù)值都是用二進制表示的，因而

3、我們還需要把量化值進行二進制編碼。這一步通常與量化同時進行。奈奎斯特采樣理論“當(dāng)對被采樣的模擬信號進行還原時，其最高頻率只有采樣頻率的一半”。換句話說，如果我們要完整重構(gòu)原始的模擬信號，則采樣頻率就必須是它的兩倍以上。比如人的聲音范圍是2 20kHZ,那么選擇的采樣頻率就應(yīng)該在40kHZ左右，數(shù)值太小則聲音將產(chǎn)生失真現(xiàn)象，而數(shù)值太大也無法明顯提升人耳所能感知的音質(zhì)。錄制過程1.音頻采集設(shè)備(比如Microphone)捕獲聲音信息。2.模擬信號通過模數(shù)轉(zhuǎn)換器(ADC)處理成計算機能接受的二進制數(shù)據(jù)。3.根據(jù)需求進行必要的渲染處理，比如音效調(diào)整、過濾等等。4.處理后的音頻數(shù)據(jù)理論上已經(jīng)可以存儲到計

4、算機設(shè)備中了，比如硬盤、USB設(shè)備等等。不過由于這時的音頻數(shù)據(jù)體積相對龐大，不利于保存和傳輸，通常還會對其進行壓縮處理。比如我們常見的mp3音樂，實際上就是對原始數(shù)據(jù)采用相應(yīng)的壓縮算法后得到的。壓縮過程根據(jù)采樣率、位深等因素的不同，最終得到的音頻文件可能會有一定程度的失真，另外，音視頻的編解碼既可以由純軟件完成，也同樣可以借助于專門的硬件芯片來完成。回放過程1.從存儲設(shè)備中取出相關(guān)文件，并根據(jù)錄制過程采用的編碼方式進行相應(yīng)的解碼。2.音頻系統(tǒng)為這一播放實例選定最終匹配的音頻回放設(shè)備。3.解碼后的數(shù)據(jù)經(jīng)過音頻系統(tǒng)設(shè)計的路徑傳輸。4.音頻數(shù)據(jù)信號通過數(shù)模轉(zhuǎn)換器(DAC)變換成模擬信號。5.模擬信號

5、經(jīng)過回放設(shè)備，還原出原始聲音。Audio框架1.APP廠商根據(jù)特定需求自己寫的一個音樂播放器軟件等等。2.FrameworkAndroid也提供了另兩個相似功能的類，即AudioTrack和AudioRecorder，MediaPlayerService內(nèi)部的實現(xiàn)就是通過它們來完成的,只不過MediaPlayer/MediaRecorder提供了更強大的控制功能，相比前者也更易于使用。除此以外，Android系統(tǒng)還為我們控制音頻系統(tǒng)提供了AudioManager、AudioService及AudioSystem類。這些都是framework為便利上層應(yīng)用開發(fā)所設(shè)計的。3.Librariesfr

6、amework只是向應(yīng)用程序提供訪問Android庫的橋梁，具體功能實現(xiàn)放在庫中完成。比如上面的AudioTrack、AudioRecorder、MediaPlayer和MediaRecorder等等在庫中都能找到相對應(yīng)的類。1、frameworks/av/media/libmedia【libmedia.so】2、frameworks/av/services/audioflinger【libaudioflinger.so】3、frameworks/av/media/libmediaplayerservice【libmediaplayerservice.so】4. HAL從設(shè)計上來看，硬件抽象層

7、是AudioFlinger直接訪問的對象。這說明了兩個問題，一方面AudioFlinger并不直接調(diào)用底層的驅(qū)動程序;另一方面，AudioFlinger上層模塊只需要與它進行交互就可以實現(xiàn)音頻相關(guān)的功能了。因而我們可以認(rèn)為AudioFlinger是Android音頻系統(tǒng)中真正的“隔離板”，無論下面如何變化，上層的實現(xiàn)都可以保持兼容。音頻方面的硬件抽象層主要分為兩部分，即AudioFlinger和AudioPolicyService。實際上后者并不是一個真實的設(shè)備，只是采用虛擬設(shè)備的方式來讓廠商可以方便地定制出自己的策略。抽象層的任務(wù)是將AudioFlinger/AudioPolicyServi

8、ce真正地與硬件設(shè)備關(guān)聯(lián)起來，但又必須提供靈活的結(jié)構(gòu)來應(yīng)對變化特別是對于Android這個更新相當(dāng)頻繁的系統(tǒng)。比如以前Android系統(tǒng)中的Audio系統(tǒng)依賴于ALSA-lib，但后期就變?yōu)榱藅inyalsa，這樣的轉(zhuǎn)變不應(yīng)該對上層造成破壞。因而Audio HAL提供了統(tǒng)一的接口來定義它與AudioFlinger/AudioPolicyService之間的通信方式，這就是audio_hw_device、audio_stream_in 及audio_stream_out等等存在的目的，這些Struct數(shù)據(jù)類型內(nèi)部大多只是函數(shù)指針的定義，是一些“殼”。當(dāng)AudioFlinger/AudioPoli

9、cyService初始化時，它們會去尋找系統(tǒng)中最匹配的實現(xiàn)(這些實現(xiàn)駐留在以audio.primary.*,audio.a2dp.*為名的各種庫中)來填充這些“殼”。根據(jù)產(chǎn)品的不同，音頻設(shè)備存在很大差異，在Android的音頻架構(gòu)中，這些問題都是由HAL層的audio.primary等等庫來解決的，而不需要大規(guī)模地修改上層實現(xiàn)。換句話說，廠商在定制時的重點就是如何提供這部分庫的高效實現(xiàn)了。AudioRcorder和AudioTrack是Audio系統(tǒng)對外提供API類，AudioRcorder主要用于完成音頻數(shù)據(jù)的采集，而AudioTrack則是負(fù)責(zé)音頻數(shù)據(jù)的輸出。AudioFlinger管理著

10、系統(tǒng)中的輸入輸出音頻流，并承擔(dān)著音頻數(shù)據(jù)的混合，通過讀寫Audio硬件實現(xiàn)音頻數(shù)據(jù)的輸入輸出功能；AudioPolicyService是Audio系統(tǒng)的策略控制中心，掌管系統(tǒng)中聲音設(shè)備的選擇和切換、音量控制等。Audio 系統(tǒng)代碼：（1）Audio 的Java 部分frameworks/base/media/java/android/media與Audio 相關(guān)的Java包是android.media，主要包含AudioManager和Audio 系統(tǒng)的幾個類。（2）Audio 的JNI 部分frameworks/base/core/jni生成庫libandroid_runtime.so，Au

11、dio 的JNI是其中的一個部分。（3）Audio 的框架部分frameworks/base/include/media/frameworks/base/media/libmedia/這部分內(nèi)容被編譯成庫libmedia.so，實現(xiàn)Audio系統(tǒng)的核心框架，同時提供了IAudioFlinger 類接口。在這個類中，可以獲得IAudioTrack 和IAudioRecorder 兩個接口，分別用于聲音的播放和錄制。AudioTrack 和AudioRecorder 分別調(diào)用IAudioTrack 和IAudioRecorder 來實現(xiàn)。IAudioFlinger.h、IAudioTrack.h

12、和IAudioRecorder.h 這三個接口通過下層來實現(xiàn)。AudioSystem.h、AudioTrack.h 和AudioRecorder.h 是對上層提供的接口，它們既供本地程序調(diào)用，也可以通過JNI 向Java 層提供接口。從功能上看，AudioSystem 負(fù)責(zé)的是Audio 系統(tǒng)的綜合管理功能，而AudioTrack 和AudioRecorder 分別負(fù)責(zé)音頻數(shù)據(jù)的輸出和輸入，即播放和錄制。另外一個接口是IAudioFlingerClient，它作為向IAudioFlinger中注冊的監(jiān)聽器，相當(dāng)于使用回調(diào)函數(shù)獲取IAudioFlinger運行時信息。（4）Audio Fling

13、erframeworks/base/libs/audioflinger這部分內(nèi)容被編譯成庫libaudioflinger.so，它是Audio系統(tǒng)的本地服務(wù)部分。（5）Audio 的硬件抽象層接口hardware/libhardware_legacy/include/hardware/1、Audio使用JNI和Java對上層提供接口，JNI部分通過調(diào)用libmedia庫提供的接口來實現(xiàn)。2、 Audio 本地框架類是libmedia.so的一個部分，這些Audio框架類對上層提供接口，由下層的本地代碼去實現(xiàn)。3、AudioFlinger繼承l(wèi)ibmeida中的接口，提供實現(xiàn)庫libaudiof

14、ilnger.so。這部分內(nèi)容沒有自己的對外頭文件，上層調(diào)用的只是libmedia本部分的接口，但實際調(diào)用的內(nèi)容是libaudioflinger.so。4、Audio的硬件抽象層提供到硬件的接口，供AudioFlinger調(diào)用。Audio的硬件抽象層實際上是各個平臺開發(fā)過程中需要主要關(guān)注和獨立完成的部分。在Android的Audio系統(tǒng)中，無論上層還是下層，都使用一個管理類和輸出輸入兩個類來表示整個Audio系統(tǒng)，輸出輸入兩個類負(fù)責(zé)數(shù)據(jù)通道。在各個層次之間具有對應(yīng)關(guān)系：在libhardware_legacy中定義的音頻相關(guān)的硬件抽象層數(shù)據(jù)結(jié)構(gòu)legacy_audio_device、legacy

15、_stream_out、legacy_stream_in如下：音頻設(shè)備描述符：cppview plain copy1.struct legacy_audio_device 2. struct audio_hw_device device;3. struct AudioHardwareInterface *hwif;4.;音頻輸出描述符：cppview plain copy1.struct legacy_stream_out 2. struct audio_stream_out stream;3. AudioStreamOut *legacy_out;4.;音頻輸入描述符：cppview pla

16、in copy1.struct legacy_stream_in 2. struct audio_stream_in stream;3. AudioStreamIn *legacy_in;4.;通過上表比較可以看出，audio_hw_device和AudioHardwareInterface、audio_stream_out和AudioStreamOut、audio_stream_in和AudioStreamIn定義的接口基本一致，這是為了兼容Android先前版本。AudioHardwareInterface.cpp負(fù)責(zé)實現(xiàn)基礎(chǔ)類和管理，而AudioHardwareGeneric.cpp、AudioHardwareStub.cpp、AudioDumpInterface.cpp和A2dpAudioInterface.cpp各自代表一種Auido硬件抽象層的實現(xiàn)。1.AudioHardwareGe