Android Audio系統(tǒng)變化都有哪些

今天就跟大家聊聊有關(guān)Android  Audio系統(tǒng)變化都有哪些，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

先從Java層AudioTrack類說起

一 AudioTrack Java類變化說明

• 聲 道數(shù)上，以前只有單聲道（MONO）和立體聲（STEREO），現(xiàn)在拓展到最NB八聲道（7.1   HiFi啊）。參數(shù)名為CHANNEL_OUT_7POINT1_SURROUND?？吹竭@個(gè)參數(shù)，我下巴咣當(dāng)就掉下來了。這玩意，一時(shí)半會(huì)我還弄不明白  是個(gè)什么道理。有知曉的屌絲碼農(nóng)們不妨告訴大家。   當(dāng)然，最終的輸出還是雙聲道。多聲道（大于2）的時(shí)候會(huì)使用downmixer處理（下變換處理，同學(xué)們可搜索之）

• 其他的變化也有，但不大了。我這里先挑一些吸引眼球的。BTW，放心，不會(huì)像那個(gè)瀧澤蘿拉首秀片子一樣只讓大家看見大鼻孔的。

二 AudioTrack JNI層變化說明

這一層包括JNI層和AudioTrack本身

• JNI層變化不大。

• Audio Native核心代碼移到了framework/av下。對，你沒看錯(cuò)。真的是av。這就是JB Audio一個(gè)比較大的變化。Audio Native核心代碼全部移到了frameworks/AV目錄下。

• AudioTrack  增加了一個(gè)變量，用于控制使用它的進(jìn)程的調(diào)度優(yōu)先級（前文說錯(cuò)了，這里確實(shí)設(shè)置的是nicer值）。如果處于播放狀態(tài)的話，將設(shè)置進(jìn)程調(diào)度優(yōu)先級為  ANDROID_PRIORITY_AUDIO。就像你們看到馬賽克時(shí)一定會(huì)嘟喃一樣。我這里也要特別啰嗦幾句。在單核CPU的情況下，設(shè)置優(yōu)先級是比較   愚蠢的(ANDROID_PRIORITY_AUDIO的值為-16，優(yōu)先級極高，單核設(shè)置個(gè)這么高的怪物，不知道其他app還怎么玩。如果你不知道我在  說什么，先看看這篇文章吧，http://blog.csdn.net/innost/article/details/6940136)。  但現(xiàn)在2核，4核已經(jīng)比較常見了，這里就可以來玩玩調(diào)度方面的事情。對屌絲碼農(nóng)的真正考驗(yàn)是：多核并行編程，linux   os的原理，需要各位屌絲同學(xué)努力掌握。Audio已經(jīng)不那么能輕易被你們?nèi)我怩遘k了。另外，低端手機(jī)，求求你們別移植4.1了，這個(gè)真的不是低端能玩  的。

• AudioTrack升級為父親了。JB為它定義了一個(gè)莫名其妙的的TimedAudioTrack子類。這個(gè)類在編解碼的  aah_rtp（我現(xiàn)在還不知道aah是什么）里邊用到了。從注釋上看，該類是一個(gè)帶時(shí)間戳（有時(shí)間戳，就可以做同步了）的音頻輸出接口。詳細(xì)理解的話，  就需要結(jié)合具體應(yīng)用場景去分析了（主要是rtp這一塊）。搞編解碼的同學(xué)們，抓緊了！

• 另外一個(gè)超級復(fù)雜的變化，是Audio定義了幾  個(gè)輸出flag（見audio.h的audio_output_flags_t枚舉定義）。根據(jù)注釋，該值有兩個(gè)作用，一個(gè)是AT的使用者可以指明自己想   使用怎樣的outputDevice。另外一個(gè)是設(shè)備廠商可以通過它聲明自己支持的輸出設(shè)備（看來，設(shè)備初始化的時(shí)候，又增添了參數(shù)讀取和配置這方面的工  作）。不過，從該枚舉的定義來看，我還看不出它和硬件有什么關(guān)系。它定義的值如下：

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只會(huì)使用第一個(gè)標(biāo)志。

// defined elsewhere

AUDIO_OUTPUT_FLAG_DEEP_BUFFER = 0x8 // use deep audio buffers 《==deep buffer是個(gè)什么玩意？這個(gè)馬賽克是不是太大了點(diǎn)？現(xiàn)在完全看不清楚??？？！

} audio_output_flags_t;

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

OK，上面有好幾個(gè)馬賽克，平?？纯慈毡敬笃臅r(shí)候也就擼過去了，但分析Audio可不行。把去馬賽克的希望寄托在下一步AudioFlinger的分析上吧！

三 AudioFlinger變化說明

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

• AF創(chuàng)建，包括其onFirstRef函數(shù)

• openOutput函數(shù)及MixerThread對象的創(chuàng)建

• AudioTrack調(diào)用createTrack函數(shù)

• AudioTrack調(diào)用start函數(shù)

• AF混音，然后輸出

3.1 AF創(chuàng)建和onFirstRef

恩，沒什么太大變化。有三個(gè)點(diǎn)：

• 現(xiàn)在對Primary設(shè)備的音量有了更為細(xì)致的控制，例如有些設(shè)備能設(shè)音量，有些不能設(shè)置音量，所以定義了一個(gè)master_volume_support（AudioFlinger.h）枚舉，用來判斷Primary設(shè)備的音量控制能力。

• 以  前播放過程的standby時(shí)間（就是為了節(jié)電而用）是寫死的，現(xiàn)在可由ro.audio.flinger_standbytime_ms控制，如果沒有  這個(gè)屬性，則默認(rèn)是3秒。AF還增加了其他變量控制，例如有一個(gè)gScreenState變量，用來表示屏幕是開還是關(guān)?？赏ㄟ^  AudioSystem::setParameters來控制。另外還定義了一個(gè)和藍(lán)牙SCO相關(guān)的mBtNrecIsOff變量，是用于控制藍(lán)牙  SCO（錄音時(shí)用，藍(lán)牙上的一個(gè)專業(yè)術(shù)語叫，NREC。不知道是什么，用懂的人告訴我一下）時(shí)禁止AEC和NS特效的。請參考  AudioParameter.cpp

3.2 openOutput函數(shù)

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

圖1 PlaybackThread家族

圖1稍加解釋：

• ThreadBase  從Thread派生，所以它會(huì)運(yùn)行在一個(gè)單獨(dú)的線程中（啰嗦一句，線程和對象其實(shí)沒有關(guān)系的，不懂多線程編程的碼農(nóng)們請務(wù)必認(rèn)真學(xué)習(xí)多線程）。它定義了一  個(gè)枚舉type_t，用來表示子類的類型，這幾個(gè)類型包括MIXER,DIRECT,RECORD,DUPLICATING等。這個(gè)應(yīng)該比較好懂吧？

• ThreadBase的內(nèi)部類TrackBase從ExtendedAudioBufferProvider派生，這個(gè)應(yīng)該是新增加的。TrackBase嘛，大家把它理解成一個(gè)Buffer Container就好了。

• ThreadBase  的內(nèi)部類PMDeathRecipient用來監(jiān)聽PowerManagerService的死亡消息。這個(gè)設(shè)計(jì)有點(diǎn)搞，因?yàn)镻MS運(yùn)行在  SystemService中，只有SS掛了，PMS才會(huì)掛。而SS掛了，mediaserver也會(huì)被init.rc的規(guī)則給弄死，所以  AudioFlinger也會(huì)死。既然大家都一起死，速度很快。故，設(shè)置這個(gè)PMDeathRecipient有何大的意義呢？

再來看ThreadBase的一個(gè)重要子類PlaybackThread，這個(gè)類應(yīng)該是做過大整容了。

• 其定義了一個(gè)枚舉mixer_state，用來反映當(dāng)前混音工作的狀態(tài)，有MIXER_IDLE，MIXER_READY和MIXER_ENABLED

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

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

• 新增定義了TimedTrack。這個(gè)類的作用和前面提到的rtp aah有關(guān)。等同學(xué)們學(xué)完本篇，即可開展相應(yīng)研究，打響殲滅戰(zhàn)！

接下來看圖2。

圖2 MixerThread和它的弟兄們

圖2，簡單介紹一下：

• MixerThread從PlaybackThread派生，這個(gè)關(guān)系至始至終不會(huì)變化，相信以后也不會(huì)。

• MT最大的變化是其中幾個(gè)重要的成員變量。大家肯定認(rèn)識(shí)其中的AudioMixer，它是用來混音的。

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

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

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

• FasetMixerState類似狀態(tài)機(jī)，有一個(gè)enum Command，用來控制狀態(tài)的。FastMixerState中含有一個(gè)八元組的FastTracks數(shù)組。FastTrack是用來完成FastMixer的一個(gè)功能類。

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

以上的內(nèi)容已經(jīng)比較復(fù)雜了，下面來介紹下MixerThread對象創(chuàng)建中碰到的其他內(nèi)容：

3.3 MixerThread創(chuàng)建

通  過圖1和圖2，應(yīng)該對AF的幾個(gè)主要成員有了認(rèn)識(shí)?？上О?，上面MixerThread中還有一個(gè)mOutputSink成員，沒看到吧？它就和我們前面  提到的NBAIO（Non-block Audio I/O   ）有重大關(guān)系。NBAIO的存在，是為了想實(shí)現(xiàn)非阻塞的音頻輸入輸出操作。下面是這個(gè)類的注釋：

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只是定義了一個(gè)接口，需要去實(shí)現(xiàn)具體的實(shí)現(xiàn)類。當(dāng)然，它要求read/write函數(shù)是非阻塞的，真實(shí)實(shí)現(xiàn)到底是不是阻塞，由實(shí)現(xiàn)者去控制。

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

圖3 NBAIO相關(guān)內(nèi)容

圖3解釋如下：

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

• NBAIO_Sink對應(yīng)output端點(diǎn)，其定義了write和writeVia函數(shù)，writeVia函數(shù)需要傳遞一個(gè)回調(diào)函數(shù)via，其內(nèi)部將調(diào)用這個(gè)via函數(shù)獲取數(shù)據(jù)。類似數(shù)據(jù)的推/拉兩種模式。

• NBAIO_Source對應(yīng)input端點(diǎn)，其定義了read和readVia函數(shù)。意義同NBAIO_Sink。

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

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

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

case FastMixer_Never: //永遠(yuǎn)不使用FastMixer，這個(gè)選項(xiàng)用于調(diào)試，即關(guān)閉FastMixer的情況

case FastMixer_Dynamic: //根據(jù)情況，動(dòng)態(tài)使用。根據(jù)注釋，這個(gè)功能似乎還沒有完全實(shí)現(xiàn)好

mNormalSink = mOutputSink;

break;

case FastMixer_Always: //永遠(yuǎn)使用FastMixer，調(diào)試用

mNormalSink = mPipeSink;

break;

case FastMixer_Static://靜態(tài)。默認(rèn)就是這個(gè)。但具體是否使用mPipeSink，將收到initFastMixer的控制

mNormalSink = initFastMixer ? mPipeSink : mOutputSink;

break;

}

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

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

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

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

3.4 createTrack和start說明

createTrack  中最大的變化就是新增了對MediaSyncEvent同步機(jī)制的處理。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.   簡單點(diǎn)講，就是必須等上一個(gè)player工作完畢了，才能開始下一個(gè)播放或者錄制。這個(gè)機(jī)制解決了Android長久以來的聲音經(jīng)常混著出來的問題（目前  一個(gè)惡心但卻實(shí)效的方法就是加一個(gè)sleep，以錯(cuò)開多個(gè)player不同步的問題。）。注意，iPhone上就沒有這個(gè)問題。

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

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

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

另外，createTrack中還涉及到FastMixer和TimedTrack處理。核心在PlaybackThread的createTrack_l和Track構(gòu)造函數(shù)中。尤其是和FastMixer的關(guān)系。

根據(jù)圖2，F(xiàn)M(FastMixer簡寫)內(nèi)部用得數(shù)據(jù)結(jié)構(gòu)是FastTrack，而MT用得是Track，所以這里存在一一對應(yīng)的關(guān)系。FM的FastTrack是保存在數(shù)組中的，所以

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

現(xiàn)在搞清楚FastTrack和Track之間的關(guān)系即可，后續(xù)的數(shù)據(jù)流動(dòng)還需要詳細(xì)討論

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

3.5 MixerThread的工作流程

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

估計(jì)馬上、很快、必須得下個(gè)版本就好了?，F(xiàn)在看看這個(gè)不成熟的東西，可以緩解以后看到成熟的東西的心理壓力。

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

• PlaybackThread的threadLoop定義了整個(gè)音頻處理的大體流程，具體的細(xì)節(jié)通過幾個(gè)虛函數(shù)（如prepareTracks_l,threadLoop_mix,threadLoop_write）交給子類去實(shí)現(xiàn)了

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

• MT  下一個(gè)重要函數(shù)就是threadLoop_mix了，由于存在一個(gè)TimedTrack類，那么AudioMixer的process函數(shù)就帶上了一個(gè)時(shí)  間戳，PTS，presentation timestamp。從編解碼角度來說，還有一個(gè)DTS，Decode   timestamp。這里要閑扯下PTS和DTS的區(qū)別了。DTS是解碼時(shí)間，但編碼的時(shí)候由于有可能會(huì)根據(jù)未來幀來編碼當(dāng)前幀。所以，解碼的時(shí)候會(huì)先解  未來幀，然后解出當(dāng)前幀，但是。你播放的時(shí)候可不能先播未來幀。只能老老實(shí)實(shí)得按播放順序來先播當(dāng)前幀，然后播未來幀（盡管先解出來的是未來幀）。關(guān)于   PTS/DTS，請屌絲們研究下IBP相關(guān)的知識(shí)吧?；氐組T，這個(gè)PTS是從硬件hal對象取的，應(yīng)該是HAL內(nèi)部維護(hù)的時(shí)間戳。這個(gè)時(shí)間戳原則上會(huì)比  較準(zhǔn)確。

• 混音完了，再做特效處理（和以前的版本差不多），然后調(diào)用  threadLoop_write。MT的threadLoop_write函數(shù)的輸出端點(diǎn)就是前面那個(gè)坑爹的mNormalSink，如果不為空，就調(diào)  用它的write函數(shù)。想著是調(diào)用NBAIO_Sink的非阻塞的write函數(shù)。根據(jù)圖2的分析，它有可能是那個(gè)MonoPipe，也有可能就是  AudioStreamOutputSink，這個(gè)sink節(jié)點(diǎn)用得就是以前的AudioStreamOutput。而MonoPipe的write其內(nèi)  部就是一個(gè)buffer。并沒有和真實(shí)的AUDIO HAL   Output掛上關(guān)系。這.....咋整？？（大膽假設(shè)，小心求證。只能是FastMixer把這個(gè)buffer取出來，然后再寫到真實(shí)的Audio   HAL中了。因?yàn)樵贛ixerThread構(gòu)造函數(shù)中，曾經(jīng)為FastTrack保存過mOutputSink，這個(gè)就是用來和  AudioStreamOutput聯(lián)系的）

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

四 FastMixer工作原理簡單說明

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

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

FM定義在FastMixer.cpp中，核心就是一個(gè)ThreadLoop。由于AF所有Track的預(yù)備工作由MT線程來做，所以FM的threadLoop基本上就是根據(jù)狀態(tài)來做對應(yīng)處理。

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

• FastMixer內(nèi)部還使用了一個(gè)AudioMixer，用于它的混音

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

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

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

五 其他變化

其他變化包括：

• 非常注重調(diào)試了，加了大量的XXXDump類?？磥恚珿oogle自己開發(fā)的時(shí)候也碰到不少問題。簡單的功能，誰會(huì)想著去dump呢？

• 增加AudioWatchdog類，用來監(jiān)控AF性能的，如CPU使用情況等。

六 總結(jié)

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

• 要充分利用多核資源，所以FastMixer的出現(xiàn)是必然。還包括NBAIO接口。感覺對HAL編寫會(huì)有大的挑戰(zhàn)。

• 增加TimedTrack和SyncEvent，對于RTP或者多個(gè)player間的同步會(huì)帶來比較好的用戶體驗(yàn)。

• 增加native層往java層通知的接口。

看完上述內(nèi)容，你們對Android  Audio系統(tǒng)變化都有哪些有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。