先從Java層AudioTrack類說起

一 AudioTrack Java類變化說明

• 聲 道數上，以前只有單聲道（MONO）和立體聲（STEREO），現在拓展到最NB八聲道（7.1 HiFi啊）。參數名為CHANNEL_OUT_7POINT1_SURROUND。看到這個參數，我下巴咣當就掉下來了。這玩意，一時半會我還弄不明白 是個什么道理。有知曉的屌絲碼農們不妨告訴大家。 當然，最終的輸出還是雙聲道。多聲道（大于2）的時候會使用downmixer處理（下變換處理，同學們可搜索之）
• 其他的變化也有，但不大了。我這里先挑一些吸引眼球的。BTW，放心，不會像那個瀧澤蘿拉首秀片子一樣只讓大家看見大鼻孔的。

二 AudioTrack JNI層變化說明

這一層包括JNI層和AudioTrack本身

• JNI層變化不大。
• Audio Native核心代碼移到了framework/av下。對，你沒看錯。真的是av。這就是JB Audio一個比較大的變化。Audio Native核心代碼全部移到了frameworks/AV目錄下。
• AudioTrack 增加了一個變量，用于控制使用它的進程的調度優先級（前文說錯了，這里確實設置的是nicer值）。如果處于播放狀態的話，將設置進程調度優先級為 ANDROID_PRIORITY_AUDIO。就像你們看到馬賽克時一定會嘟喃一樣。我這里也要特別啰嗦幾句。在單核CPU的情況下，設置優先級是比較 愚蠢的(ANDROID_PRIORITY_AUDIO的值為-16，優先級極高，單核設置個這么高的怪物，不知道其他app還怎么玩。如果你不知道我在 說什么，先看看這篇文章吧，http://blog.csdn.net/innost/article/details/6940136)。 但現在2核，4核已經比較常見了，這里就可以來玩玩調度方面的事情。對屌絲碼農的真正考驗是：多核并行編程，linux os的原理，需要各位屌絲同學努力掌握。Audio已經不那么能輕易被你們任意蹂躪了。另外，低端手機，求求你們別移植4.1了，這個真的不是低端能玩 的。
• AudioTrack升級為父親了。JB為它定義了一個莫名其妙的的TimedAudioTrack子類。這個類在編解碼的 aah_rtp（我現在還不知道aah是什么）里邊用到了。從注釋上看，該類是一個帶時間戳（有時間戳，就可以做同步了）的音頻輸出接口。詳細理解的話， 就需要結合具體應用場景去分析了（主要是rtp這一塊）。搞編解碼的同學們，抓緊了！
• 另外一個超級復雜的變化，是Audio定義了幾 個輸出flag（見audio.h的audio_output_flags_t枚舉定義）。根據注釋，該值有兩個作用，一個是AT的使用者可以指明自己想 使用怎樣的outputDevice。另外一個是設備廠商可以通過它聲明自己支持的輸出設備（看來，設備初始化的時候，又增添了參數讀取和配置這方面的工 作）。不過，從該枚舉的定義來看，我還看不出它和硬件有什么關系。它定義的值如下：

typedef enum {

AUDIO_OUTPUT_FLAG_NONE = 0x0, // no attributes

AUDIO_OUTPUT_FLAG_DIRECT = 0x1, // this output directly connects a track

// to one output stream: no software mixer

AUDIO_OUTPUT_FLAG_PRIMARY = 0x2, // this output is the primary output of

// the device. It is unique and must be

// present. It is opened by default and

// receives routing, audio mode and volume

// controls related to voice calls.

AUDIO_OUTPUT_FLAG_FAST = 0x4, // output supports "fast tracks", 《==什么叫fast track？太難理解了！目前，java層的audiotrack只會使用第一個標志。

// defined elsewhere

AUDIO_OUTPUT_FLAG_DEEP_BUFFER = 0x8 // use deep audio buffers 《==deep buffer是個什么玩意？這個馬賽克是不是太大了點？現在完全看不清楚啊？？！

} audio_output_flags_t;

• AudioTrack其他變化不大。AudioTrack.cpp總共才1600多行，so easy！

OK，上面有好幾個馬賽克，平常看看日本大片的時候也就擼過去了，但分析Audio可不行。把去馬賽克的希望寄托在下一步AudioFlinger的分析上吧！

三 AudioFlinger變化說明

我們將根據AF工作的主要流程來介紹下變化情況：

• AF創建，包括其onFirstRef函數
• openOutput函數及MixerThread對象的創建
• AudioTrack調用createTrack函數
• AudioTrack調用start函數
• AF混音，然后輸出

3.1 AF創建和onFirstRef

恩，沒什么太大變化。有三個點：

• 現在對Primary設備的音量有了更為細致的控制，例如有些設備能設音量，有些不能設置音量，所以定義了一個master_volume_support（AudioFlinger.h）枚舉，用來判斷Primary設備的音量控制能力。
• 以 前播放過程的standby時間（就是為了節電而用）是寫死的，現在可由ro.audio.flinger_standbytime_ms控制，如果沒有 這個屬性，則默認是3秒。AF還增加了其他變量控制，例如有一個gScreenState變量，用來表示屏幕是開還是關。可通過 AudioSystem::setParameters來控制。另外還定義了一個和藍牙SCO相關的mBtNrecIsOff變量，是用于控制藍牙 SCO（錄音時用，藍牙上的一個專業術語叫，NREC。不知道是什么，用懂的人告訴我一下）時禁止AEC和NS特效的。請參考 AudioParameter.cpp

3.2 openOutput函數

openOutput 函數比較關鍵，其中會見到以前的老朋友MixerThread，AudioStreamOutput等。整個流程包括加載Audio相關的硬件so。這部 分工作在4.0的時候就有了，談不上太多的變化。但物是人非，老朋友已經發生巨大變化了。先來看MixerThread家族。

圖1 PlaybackThread家族

圖1稍加解釋：

• ThreadBase 從Thread派生，所以它會運行在一個單獨的線程中（啰嗦一句，線程和對象其實沒有關系的，不懂多線程編程的碼農們請務必認真學習多線程）。它定義了一 個枚舉type_t，用來表示子類的類型，這幾個類型包括MIXER,DIRECT,RECORD,DUPLICATING等。這個應該比較好懂吧？

• ThreadBase的內部類TrackBase從ExtendedAudioBufferProvider派生，這個應該是新增加的。TrackBase嘛，大家把它理解成一個Buffer Container就好了。

• ThreadBase 的內部類PMDeathRecipient用來監聽PowerManagerService的死亡消息。這個設計有點搞，因為PMS運行在 SystemService中，只有SS掛了，PMS才會掛。而SS掛了，mediaserver也會被init.rc的規則給弄死，所以 AudioFlinger也會死。既然大家都一起死，速度很快。故，設置這個PMDeathRecipient有何大的意義呢？

再來看ThreadBase的一個重要子類PlaybackThread，這個類應該是做過大整容了。

• 其定義了一個枚舉mixer_state，用來反映當前混音工作的狀態，有MIXER_IDLE，MIXER_READY和MIXER_ENABLED

• 定義了幾個虛函數，需要子類實現，包括threadLoop_mix，prepareTracks_l等。這幾個函數的抽象工作做得還是可以。但變化之大讓人防不勝防啊。

• Track類增加了從VolumeProvider派生，這個VP是用來控制音量的。根據前面的介紹，在JB中，音量管理比以前來得細致

• 新增定義了TimedTrack。這個類的作用和前面提到的rtp aah有關。等同學們學完本篇，即可開展相應研究，打響殲滅戰！

接下來看圖2。

圖2 MixerThread和它的弟兄們

圖2，簡單介紹一下：

• MixerThread從PlaybackThread派生，這個關系至始至終不會變化，相信以后也不會。

• MT最大的變化是其中幾個重要的成員變量。大家肯定認識其中的AudioMixer，它是用來混音的。

• 新 增一個Soaker對象（由編譯宏控制），它是一個線程。這個單詞的前綴soak在webster詞典（相信經歷過，那些年，我們一起GRE的日子 的人知道什么是webster）中最貼切的一條解釋是to cause to pay an exorbitant amount。還是不很明白是干嘛的？再一看代碼。原來，soaker就是一個專職玩弄CPU的線程。它的工作就是不斷得做運算，拉高CPU使用率。它的 存在應該是為了測試新AF框架在多核CPU上的效率等等等的問題。所以，低端智能機們，你們不要玩JB了。

• 另外一條證明低端智能機不能隨便玩JB的鐵證就是：我們看到MT中新增了一個FastMixer，它也是一個線程。明白了？在JB中，多核智能機上，混音工作可以放到FastMixer所在的線程來做，當然速度，效率會高了。

• FastMixer 工作流程比較復雜，又牽扯到多線程同步。所以，這里定義了一個FastMixerStateQueue，它由typedef StateQueue<FastMixerState>得到。首先它是一個StateQueue（簡單把它當做數組吧）。其數組元素的類型為 FastMixerState。一個StateQueue通過mStats變量保存4個FasetMixerState成員。

• FasetMixerState類似狀態機，有一個enum Command，用來控制狀態的。FastMixerState中含有一個八元組的FastTracks數組。FastTrack是用來完成FastMixer的一個功能類。

• 每個FastTrack都有一個mBufferProvider，該成員類型為SourceAudioBufferProvider。

以上的內容已經比較復雜了，下面來介紹下MixerThread對象創建中碰到的其他內容：

#p#

3.3 MixerThread創建

通 過圖1和圖2，應該對AF的幾個主要成員有了認識。可惜啊，上面MixerThread中還有一個mOutputSink成員，沒看到吧？它就和我們前面 提到的NBAIO（Non-block Audio I/O ）有重大關系。NBAIO的存在，是為了想實現非阻塞的音頻輸入輸出操作。下面是這個類的注釋：

NBAIO注釋：

// This header file has the abstract interfaces only. Concrete implementation classes are declared

// elsewhere. Implementations _should_ be non-blocking for all methods, especially read() and

// write(), but this is not enforced. In general, implementations do not need to be multi-thread

// safe, and any exceptions are noted in the particular implementation.

NBAIO只是定義了一個接口，需要去實現具體的實現類。當然，它要求read/write函數是非阻塞的，真實實現到底是不是阻塞，由實現者去控制。

個人感覺這部分框架還沒有完全成熟，但NBIO的引入，需要同學們小心，相對而言，難度也比較大。下面我們通過圖3來看看NBAIO的一些內容。

圖3 NBAIO相關內容

圖3解釋如下：

• NBAIO 包括三個主要類，一個是NBAIO_Port，代表I/O端點，其中定義了一個negotiate函數，用于調用者和I/O端點進行參數協調。注意，并不 是為I/O端點設置參數。因為I/O端點往往和硬件相關，而硬件有些參數是不能像軟件一般隨意變化的。例如硬件只支持最多44.1KHZ的采樣率，而調用 者傳遞48KHz的采樣率，這直接就需要一個協商和匹配的過程。這個函數的比較難用，主要是規則較多。同學們可以參考其注釋說明。

• NBAIO_Sink對應output端點，其定義了write和writeVia函數，writeVia函數需要傳遞一個回調函數via，其內部將調用這個via函數獲取數據。類似數據的推/拉兩種模式。

• NBAIO_Source對應input端點，其定義了read和readVia函數。意義同NBAIO_Sink。

• 定 義一個MonoPipe和MonoPipeReader。Pipe即管道，MonoPipe和LINUX中的IPC通信Pipe沒毛關系，只不過借用了這 個管道概念和思路。MonoPipe即只支持單個讀者的Pipe（AF中，它是MonoPipeReader）。這兩個Pipe，代表了Audio的 Output和Input端點。

• MT中由mOutputSink指向 AudioStreamOutSink，此類用NBAIO_Sink派生，用于普通的mixer的輸出。mPipeSink指向MonoPipe，本意是 用于FastMixer的。另外，還有一個變量mNormalSink，它將根據FastMixer的情況，指向mPipeSink，或者是 mOutputSink。這段控制的邏輯如下：

switch (kUseFastMixer) { //kUseFastMixer用于控制FastMixer的使用情況，一共4種：

case FastMixer_Never: //永遠不使用FastMixer，這個選項用于調試，即關閉FastMixer的情況

case FastMixer_Dynamic: //根據情況，動態使用。根據注釋，這個功能似乎還沒有完全實現好

mNormalSink = mOutputSink;

break;

case FastMixer_Always: //永遠使用FastMixer，調試用

mNormalSink = mPipeSink;

break;

case FastMixer_Static://靜態。默認就是這個。但具體是否使用mPipeSink，將收到initFastMixer的控制

mNormalSink = initFastMixer ? mPipeSink : mOutputSink;

break;

}

由上所述，kUseFastMixer默認是FastMixer_Static，但mNormalSink是否指向mPipeSink，還由initFastMixer控制。這個變量本身又有mFrameCount和

mNormalFrameCount的大小決定，只有mFrameCount小于mNormalFrameCount時，initFastMixer才為真。暈了....這兩個frameCount由PlaybackThread的

readOutputParameters得到。請同學們自己研究這段代碼吧，就是一些簡單的計算。想要搞明白的話，最好帶著參數進去，把值都算出來。

好了，MixerThread的創建就分析到此，最好還是把這段代碼多研究研究。了解幾個兄弟對象是做什么的....

3.4 createTrack和start說明

createTrack 中最大的變化就是新增了對MediaSyncEvent同步機制的處理。MediaSyncEvent的目的很簡單，其Java API的解釋如下：startRecording(MediaSyncEvent) is used to start capture only when the playback on a particular audio session is complete. The audio session ID is retrieved from a player (e.g MediaPlayer, AudioTrack or ToneGenerator) by use of the getAudioSessionId() method. 簡單點講，就是必須等上一個player工作完畢了，才能開始下一個播放或者錄制。這個機制解決了Android長久以來的聲音經常混著出來的問題（目前 一個惡心但卻實效的方法就是加一個sleep，以錯開多個player不同步的問題。）。注意，iPhone上就沒有這個問題。

另外，這個機制的潛在好處就是解放了做AudioPolicy AudioRoute工作的同學們，似乎（個人感覺是可以解決這個問題的）可以不用再去琢磨到底sleep多少時間，在哪加sleep的問題了

在AF中，MediaSyncEvent機制的代表是SyncEvent。大家自己看看就好。

start函數的變化不大，其中加了對SyncEvent的處理。

另外，createTrack中還涉及到FastMixer和TimedTrack處理。核心在PlaybackThread的createTrack_l和Track構造函數中。尤其是和FastMixer的關系。

根據圖2，FM(FastMixer簡寫)內部用得數據結構是FastTrack，而MT用得是Track，所以這里存在一一對應的關系。FM的FastTrack是保存在數組中的，所以

使用FM的Track將通過mFastIndex來指向這個FastTrack。

現在搞清楚FastTrack和Track之間的關系即可，后續的數據流動還需要詳細討論

下面來看看MixerThread的工作流程。這部分是重頭戲！

3.5 MixerThread的工作流程

這部分難的還是在FastMixer的工作原理上。不過這里提前和大家說：目前這個功能還沒有做完，代碼里邊一堆的FIXME...。但屌絲們不要happy太早了，

估計馬上、很快、必須得下個版本就好了。現在看看這個不成熟的東西，可以緩解以后看到成熟的東西的心理壓力。

MT是一個線程，其工作內容主要在threadLoop中完成，而這個函數是由其基類PlaybackThread定義的，大體變化如下：

• PlaybackThread的threadLoop定義了整個音頻處理的大體流程，具體的細節通過幾個虛函數（如prepareTracks_l,threadLoop_mix,threadLoop_write）交給子類去實現了

• MT 變化大的首先是prepareTracks_l，首先處理的是FastMix類型的Track，判斷標準是該Track是否設置了TRACK_FAST標 志（爽了，目前JB中還沒有哪個地方使用了這個標志）。這部分判斷比較復雜。首先FastMixer維護了一個狀態機，另外，這個FastMixer運行 在自己的線程里，所以線程同步是必須的。這里采用的是狀態來控制FastMixer的工作流程。由于涉及到多線程，所以音頻的 underrun,overrun狀態（不知道是什么嗎？看前面提到的參考書！）也是一個需要處理的棘手問題。另外，一個MT是帶一個 AudioMixer對象，這個對象將完成數據的混音，下變換等等超難度，數字音頻處理等方面的工作。也就是說，對于混音來說，前期的prepare工作 還是由MT線程來完成，因為這樣可以做到統一管理（有些Track并不需要使用FastMixer。但仔細一想，誰都希望處理越快越好，在多核CPU上， 將混音工作交給多個線程處理是充分利用CPU資源的典范，這應該是未來Android演化的趨勢。所以，我估計這個JB還沒完全長大....）。對 FastMixer感興趣的屌絲們，請務必認真研究prepareTracks_l函數。

• MT 下一個重要函數就是threadLoop_mix了，由于存在一個TimedTrack類，那么AudioMixer的process函數就帶上了一個時 間戳，PTS，presentation timestamp。從編解碼角度來說，還有一個DTS，Decode timestamp。這里要閑扯下PTS和DTS的區別了。DTS是解碼時間，但編碼的時候由于有可能會根據未來幀來編碼當前幀。所以，解碼的時候會先解 未來幀，然后解出當前幀，但是。你播放的時候可不能先播未來幀。只能老老實實得按播放順序來先播當前幀，然后播未來幀（盡管先解出來的是未來幀）。關于 PTS/DTS，請屌絲們研究下IBP相關的知識吧。回到MT，這個PTS是從硬件hal對象取的，應該是HAL內部維護的時間戳。這個時間戳原則上會比 較準確。

• 混音完了，再做特效處理（和以前的版本差不多），然后調用 threadLoop_write。MT的threadLoop_write函數的輸出端點就是前面那個坑爹的mNormalSink，如果不為空，就調 用它的write函數。想著是調用NBAIO_Sink的非阻塞的write函數。根據圖2的分析，它有可能是那個MonoPipe，也有可能就是 AudioStreamOutputSink，這個sink節點用得就是以前的AudioStreamOutput。而MonoPipe的write其內 部就是一個buffer。并沒有和真實的AUDIO HAL Output掛上關系。這.....咋整？？（大膽假設，小心求證。只能是FastMixer把這個buffer取出來，然后再寫到真實的Audio HAL中了。因為在MixerThread構造函數中，曾經為FastTrack保存過mOutputSink，這個就是用來和 AudioStreamOutput聯系的）

另外，DulicatingThread,DirectOuptutThread沒有太大變化。

四 FastMixer工作原理簡單說明

我以前想得是：混音工作由FastMixer線程和MixerThread線程共同完成，但輸出工作依然在MixerThread做。從上面MonoPipe的分析來看，這個判斷可能不準。

既 有可能是輸出工作也交給FastMixer來做，而MixerThread僅做一部分混音工作，然后把數據通過MonoPipe傳給FastMixer線 程。FastMixer線程將自己的FastTrack的混音結果和MT的混音結果再做一次混音，然后再由FastMixer輸出。

FM定義在FastMixer.cpp中，核心就是一個ThreadLoop。由于AF所有Track的預備工作由MT線程來做，所以FM的threadLoop基本上就是根據狀態來做對應處理。

這 里的同步使用了LINUX中很底層的futex（Fast Userspace Mutex）。暈，futex是POSIX Mutex的實現基礎。不知道寫這段代碼的人為何不直接用Mutex（估計還是嫌效率的問題，但是 媽的，用了Mutex效率能差多少？代碼是寫給人看的，太B4我們了...）。玩多線程玩到這種地步，佩服啊！不懂多線程編程的屌絲們，請仔細研究 Posix MultiThread Programming吧

• FastMixer內部還使用了一個AudioMixer，用于它的混音

• 然后再write出去.....

這里是FM的簡單說明，詳細內容，沒有拿個真機給我，我也沒法整啊....歡迎樂善好施的兄弟們刷個4.1的機器，然后借給我研究下...

（這玩意，個人感覺也不是太難。東西嘛，耐不住琢磨，總能搞透的）。兄弟們今天知道FM和MT的大體工作流程就可以了。

五 其他變化

其他變化包括：

• 非常注重調試了，加了大量的XXXDump類。看來，Google自己開發的時候也碰到不少問題。簡單的功能，誰會想著去dump呢？
• 增加AudioWatchdog類，用來監控AF性能的，如CPU使用情況等。

六 總結

我記得在研究2.2 AF的時候，AudioFlinger才3k多行，而JB已經有9K多行了。還沒算其他的輔助類。從整體上看，JB變化趨勢為：

• 要充分利用多核資源，所以FastMixer的出現是必然。還包括NBAIO接口。感覺對HAL編寫會有大的挑戰。
• 增加TimedTrack和SyncEvent，對于RTP或者多個player間的同步會帶來比較好的用戶體驗。
• 增加native層往java層通知的接口。

還有其他的東西.....今天先到這了。