Android 4.1，英文代號簡稱JB。在國人眼裡，JB這個詞還和動物有點關係。Google如此頻繁修改Android，終於推出了一個可以被大家整天JB JB掛在嘴上的版本。以後我的文章也可以一面用JB表示版本號碼，一面用JB表示毛主席常說的”戰略上的鄙視了“。請大家根據上下文揣摩我寫下JB一詞的心情。今天將稍深入得介紹一下JB 4.1在Audio系統做的翻天覆地的改動。這裡先囉嗦幾句：就像80後經常抱怨自己晚生了幾年一樣，馬上就會有很多碼農抱怨接觸Android太晚了。為何？JB Audio系統的難度相對4.0, 2.3, 2.2已經非常非常大了。99%的情況下，在你沒有看到這個NB（這不是髒話，4.1 Audio系統中就有一個類叫NBAIO，籃球控不要搞錯成NBA了，原意是Non-block Audio I/O。看到了吧，
非阻塞I/O，各位自問下，有多少人對這個東西有深刻理解？）東西演化的基礎上，不太可能能看懂JB Audio系統。所以，建議這99%中的沒有見識過Audio演化曆史的屌絲同學們，先仔細研究（以前我僅僅建議大家看看，現在提高要求為仔細研究）《深入理解Android 卷I》Audio系統。
BTW，此書在某個章節裡特意提醒過大家要去研究下各種I/O模型，不知道有幾個人屌過我了。本文將分幾個部分，事前沒有打草稿，所以會有點亂。先從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 attributesAUDIO_OUTPUT_FLAG_DIRECT = 0x1, // this output directly connects a track// to one output stream: no software mixerAUDIO_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 elsewhereAUDIO_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對象建立中碰到的其他內容：
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層通知的介面。
還有其他的東西.....今天先到這了。對屌絲的考驗：
- LINUX OS編程和POSIX編程必須熟練掌握。
- 複雜程式碼分析能力必須儘快提高。否則，後面根本看不懂。
