溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
Android中AudioFlinger的作用是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。
AudioFlinger的誕生
AF是一個服務，這個就不用我多說了吧？代碼在
framework/base/media/mediaserver/Main_mediaServer.cpp中。 int main(int argc, char** argv) { sp<ProcessState> proc(ProcessState::self()); sp<IServiceManager> sm = defaultServiceManager(); .... AudioFlinger::instantiate();--->AF的實例化 AudioPolicyService::instantiate();--->APS的實例化 .... ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); }哇塞，看來這個程序的負擔很重啊。沒想到。為何AF，APS要和MediaService和CameraService都放到一個籃子里？
看看AF的實例化靜態函數，在framework/base/libs/audioFlinger/audioFlinger.cpp中
void AudioFlinger::instantiate() { defaultServiceManager()->addService( //把AF實例加入系統服務 String16("media.audio_flinger"), new AudioFlinger()); }再來看看它的構造函數是什么做的。
AudioFlinger::AudioFlinger() : BnAudioFlinger(),//初始化基類 mAudioHardware(0), //audio硬件的HAL對象 mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0) { mHardwareStatus = AUDIO_HW_IDLE; //創建代表Audio硬件的HAL對象 mAudioHardware = AudioHardwareInterface::create(); mHardwareStatus = AUDIO_HW_INIT; if (mAudioHardware->initCheck() == NO_ERROR) { setMode(AudioSystem::MODE_NORMAL); //設置系統的聲音模式等，其實就是設置硬件的模式 setMasterVolume(1.0f); setMasterMute(false); } }AF中經常有setXXX的函數，到底是干什么的呢？我們看看setMode函數。
status_t AudioFlinger::setMode(int mode) { mHardwareStatus = AUDIO_HW_SET_MODE; status_t ret = mAudioHardware->setMode(mode);//設置硬件的模式 mHardwareStatus = AUDIO_HW_IDLE; return ret; }當然，setXXX還有些別的東西，但基本上都會涉及到硬件對象。我們暫且不管它。等分析到Audio策略再說。
好了，Android系統啟動的時候，看來AF也準備好硬件了。不過，創建硬件對象就代表我們可以播放了嗎？
我這里簡單的把AT調用AF的流程列一下，待會按這個順序分析AF的工作方式。
--參加AudioTrack分析的4.1節
1. 創建
AudioTrack* lpTrack = new AudioTrack(); lpTrack->set(...);
這個就進入到C++的AT了。下面是AT的set函數
audio_io_handle_t output = AudioSystem::getOutput((AudioSystem::stream_type)streamType, sampleRate, format, channels, (AudioSystem::output_flags)flags); status_t status = createTrack(streamType, sampleRate, format, channelCount, frameCount, flags, sharedBuffer, output); ----->creatTrack會和AF打交道。我們看看createTrack重要語句 const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger(); //下面很重要，調用AF的createTrack獲得一個IAudioTrack對象 sp<IAudioTrack> track = audioFlinger->createTrack(); sp<IMemory> cblk = track->getCblk();//獲取共享內存的管理結構
總結一下創建的流程，AT調用AF的createTrack獲得一個IAudioTrack對象，然后從這個對象中獲得共享內存的對象。
2. start和write
看看AT的start，估計就是調用IAudioTrack的start吧？
void AudioTrack::start() { //果然啊... status_t status = mAudioTrack->start(); }那write呢?我們之前講了，AT就是從共享buffer中:
l Lock緩存
l 寫緩存
l Unlock緩存
注意，這里的Lock和Unlock是有問題的，什么問題呢?待會我們再說
按這種方式的話，那么AF一定是有一個線程在那也是：
l Lock，
l 讀緩存，寫硬件
l Unlock
總之，我們知道了AT的調用AF的流程了。下面一個一個看。
1 createTrack
sp<IAudioTrack> AudioFlinger::createTrack( pid_t pid,//AT的pid號 int streamType,//MUSIC，流類型 uint32_t sampleRate,//8000 采樣率 int format,//PCM_16類型 int channelCount,//2，雙聲道 int frameCount,//需要創建的buffer可包含的幀數 uint32_t flags, const sp<IMemory>& sharedBuffer,//AT傳入的共享buffer，這里為空 int output,//這個是從AuidoSystem獲得的對應MUSIC流類型的索引 status_t *status) { sp<PlaybackThread::Track> track; sp<TrackHandle> trackHandle; sp<Client> client; wp<Client> wclient; status_t lStatus; { Mutex::Autolock _l(mLock); //根據output句柄，獲得線程？ PlaybackThread *thread = checkPlaybackThread_l(output); //看看這個進程是不是已經是AF的客戶了 //這里說明一下，由于是C/S架構，那么作為服務端的AF肯定有地方保存作為C的AT的信息 //那么，AF是根據pid作為客戶端的唯一標示的 //mClients是一個類似map的數據組織結構 wclient = mClients.valueFor(pid); if (wclient != NULL) { } else { //如果還沒有這個客戶信息，就創建一個，并加入到map中去 client = new Client(this, pid); mClients.add(pid, client); } //從剛才找到的那個線程對象中創建一個track track = thread->createTrack_l(client, streamType, sampleRate, format, channelCount, frameCount, sharedBuffer, &lStatus); } //喔，還有一個trackHandle，而且返回到AF端的是這個trackHandle對象 trackHandle = new TrackHandle(track); return trackHandle; }這個AF函數中，突然冒出來了很多新類型的數據結構。說實話，我剛開始接觸的時候，大腦因為常接觸到這些眼生的東西而死機！大家先不要拘泥于這些東西，我會一一分析到的。
先進入到checkPlaybackThread_l看看。
AudioFlinger::PlaybackThread *AudioFlinger::checkPlaybackThread_l(int output) const { PlaybackThread *thread = NULL; //看到這種indexOfKey的東西，應該立即能想到： //喔，這可能是一個map之類的東西，根據key能找到實際的value if (mPlaybackThreads.indexOfKey(output) >= 0) { thread = (PlaybackThread *)mPlaybackThreads.valueFor(output).get(); } //這個函數的意思是根據output值，從一堆線程中找到對應的那個線程 return thread; }看到這里很疑惑啊：
l AF的構造函數中沒有創建線程，只創建了一個audio的HAL對象
l 如果AT是AF的第一個客戶的話，我們剛才的調用流程里邊，也沒看到哪有創建線程的地方呀。
l output是個什么玩意兒？為什么會根據它作為key來找線程呢？
看來，我們得去Output的來源那看看了。
我們知道，output的來源是由AT的set函數得到的：如下：
audio_io_handle_t output = AudioSystem::getOutput( (AudioSystem::stream_type)streamType, //MUSIC類型 sampleRate, //8000 format, //PCM_16 channels, //2兩個聲道 (AudioSystem::output_flags)flags//0 );
上面這幾個參數后續不再提示了，大家知道這些值都是由AT做為切入點傳進去的
然后它在調用AT自己的createTrack，最終把這個output值傳遞到AF了。其中audio_io_handle_t類型就是一個int類型。
//叫handle啊？好像linux下這種叫法的很少，難道又是受MS的影響嗎？
我們進到AudioSystem::getOutput看看。注意，大家想想這是系統的第一次調用,而且發生在AudioTrack那個進程里邊。AudioSystem的位置在framework/base/media/libmedia/AudioSystem.cpp中
audio_io_handle_t AudioSystem::getOutput(stream_type stream, uint32_t samplingRate, uint32_t format, uint32_t channels, output_flags flags) { audio_io_handle_t output = 0; if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) == 0 && ((stream != AudioSystem::VOICE_CALL && stream != AudioSystem::BLUETOOTH_SCO) || channels != AudioSystem::CHANNEL_OUT_MONO || (samplingRate != 8000 && samplingRate != 16000))) { Mutex::Autolock _l(gLock); //根據我們的參數，我們會走到這個里邊來 //喔，又是從map中找到stream=music的output。可惜啊，我們是第一次進來 //output一定是0 output = AudioSystem::gStreamOutputMap.valueFor(stream); } if (output == 0) { //我暈，又到AudioPolicyService(APS) //由它去getOutput const sp<IAudioPolicyService>& aps = AudioSystem::get_audio_policy_service(); output = aps->getOutput(stream, samplingRate, format, channels, flags); if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) == 0) { Mutex::Autolock _l(gLock); //如果取到output了，再把output加入到AudioSystem維護的這個map中去 //說白了，就是保存一些信息嗎。免得下次又這么麻煩去騷擾APS！ AudioSystem::gStreamOutputMap.add(stream, output); } } return output; }怎么辦？需要到APS中才能找到output的信息？
沒辦法，硬著頭皮進去吧。那先得看看APS是如何創建的。不過這個剛才已經說了，是和AF一塊在那個Main_mediaService.cpp中實例化的。
位置在framework/base/lib/libaudioflinger/ AudioPolicyService.cpp中
AudioPolicyService::AudioPolicyService() : BnAudioPolicyService() , mpPolicyManager(NULL) { // 下面兩個線程以后再說 mTonePlaybackThread = new AudioCommandThread(String8("")); mAudioCommandThread = new AudioCommandThread(String8("ApmCommandThread")); #if (defined GENERIC_AUDIO) || (defined AUDIO_POLICY_TEST) //喔，使用普適的AudioPolicyManager，把自己this做為參數 //我們這里先使用普適的看看吧 mpPolicyManager = new AudioPolicyManagerBase(this); //使用硬件廠商提供的特殊的AudioPolicyManager //mpPolicyManager = createAudioPolicyManager(this); } }我們看看AudioManagerBase的構造函數吧，在framework/base/lib/audioFlinger/
AudioPolicyManagerBase.cpp中。
AudioPolicyManagerBase::AudioPolicyManagerBase(AudioPolicyClientInterface *clientInterface) : mPhoneState(AudioSystem::MODE_NORMAL), mRingerMode(0), mMusicStopTime(0), mLimitRingtoneVolume(false) { mpClientInterface = clientInterface;這個client就是APS，剛才通過this傳進來了 AudioOutputDescriptor *outputDesc = new AudioOutputDescriptor(); outputDesc->mDevice = (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER; mHardwareOutput = mpClientInterface->openOutput(&outputDesc->mDevice, &outputDesc->mSamplingRate, &outputDesc->mFormat, &outputDesc->mChannels, &outputDesc->mLatency, outputDesc->mFlags); openOutput又交給APS的openOutput來完成了，真繞.... }唉，看來我們還是得回到APS，
audio_io_handle_t AudioPolicyService::openOutput(uint32_t *pDevices, uint32_t *pSamplingRate, uint32_t *pFormat, uint32_t *pChannels, uint32_t *pLatencyMs, AudioSystem::output_flags flags) { sp<IAudioFlinger> af = AudioSystem::get_audio_flinger(); //FT,FT,FT,FT,FT,FT,FT //繞了這么一個大圈子，竟然回到AudioFlinger中了啊？？ return af->openOutput(pDevices, pSamplingRate, (uint32_t *)pFormat, pChannels, pLatencyMs, flags); }在我們再次被繞暈之后，我們回眸看看足跡吧：
l 在AudioTrack中，調用set函數
l 這個函數會通過AudioSystem::getOutput來得到一個output的句柄
l AS的getOutput會調用AudioPolicyService的getOutput
l 然后我們就沒繼續講APS的getOutPut了，而是去看看APS創建的東西
l 發現APS創建的時候會創建一個AudioManagerBase，這個AMB的創建又會調用APS的openOutput。
l APS的openOutput又會調用AudioFlinger的openOutput
有一個疑問，AT中set參數會和APS構造時候最終傳入到AF的openOutput一樣嗎？如果不一樣，那么構造時候openOutput的又是什么參數呢？
先放下這個懸念，我們繼續從APS的getOutPut看看。
audio_io_handle_t AudioPolicyService::getOutput(AudioSystem::stream_type stream, uint32_t samplingRate, uint32_t format, uint32_t channels, AudioSystem::output_flags flags) { Mutex::Autolock _l(mLock); //自己又不干活，由AudioManagerBase干活 return mpPolicyManager->getOutput(stream, samplingRate, format, channels, flags); }進去看看吧
audio_io_handle_t AudioPolicyManagerBase::getOutput(AudioSystem::stream_type stream, uint32_t samplingRate, uint32_t format, uint32_t channels, AudioSystem::output_flags flags) { audio_io_handle_t output = 0; uint32_t latency = 0; // open a non direct output output = mHardwareOutput; //這個是在哪里創建的？在AMB構造的時候.. return output; }具體AMB的分析待以后Audio系統策略的時候我們再說吧。反正，到這里，我們知道了，在APS構造的時候會open一個Output，而這個Output又會調用AF的openOutput。
int AudioFlinger::openOutput(uint32_t *pDevices, uint32_t *pSamplingRate, uint32_t *pFormat, uint32_t *pChannels, uint32_t *pLatencyMs, uint32_t flags) { status_t status; PlaybackThread *thread = NULL; mHardwareStatus = AUDIO_HW_OUTPUT_OPEN; uint32_t samplingRate = pSamplingRate ? *pSamplingRate : 0; uint32_t format = pFormat ? *pFormat : 0; uint32_t channels = pChannels ? *pChannels : 0; uint32_t latency = pLatencyMs ? *pLatencyMs : 0; Mutex::Autolock _l(mLock); //由Audio硬件HAL對象創建一個AudioStreamOut對象 AudioStreamOut *output = mAudioHardware->openOutputStream(*pDevices, (int *)&format, &channels, &samplingRate, &status); mHardwareStatus = AUDIO_HW_IDLE; if (output != 0) { //創建一個Mixer線程 thread = new MixerThread(this, output, ++mNextThreadId); } //終于找到了，把這個線程加入線程管理組織中 mPlaybackThreads.add(mNextThreadId, thread); return mNextThreadId; } }明白了，看來AT在調用AF的createTrack的之前，AF已經在某個時候把線程創建好了，而且是一個Mixer類型的線程，看來和混音有關系呀。這個似乎和我們開始設想的AF工作有點聯系喔。Lock，讀緩存，寫Audio硬件，Unlock。可能都是在這個線程里邊做的。
2 繼續createTrack
AudioFlinger::createTrack( pid_t pid, int streamType, uint32_t sampleRate, int format, int channelCount, int frameCount, uint32_t flags, const sp<IMemory>& sharedBuffer, int output, status_t *status) { sp<PlaybackThread::Track> track; sp<TrackHandle> trackHandle; sp<Client> client; wp<Client> wclient; status_t lStatus; { //假設我們找到了對應的線程 Mutex::Autolock _l(mLock); PlaybackThread *thread = checkPlaybackThread_l(output); //暈，調用這個線程對象的createTrack_l track = thread->createTrack_l(client, streamType, sampleRate, format, channelCount, frameCount, sharedBuffer, &lStatus); } trackHandle = new TrackHandle(track);return trackHandle；----》注意，這個對象是最終返回到AT進程中的。
實在是....太繞了。再進去看看thread->createTrack_l吧。_l的意思是這個函數進入之前已經獲得同步鎖了。
跟著sourceinsight ctrl+鼠標左鍵就進入到下面這個函數。
下面這個函數的簽名好長啊。這是為何？
原來Android的C++類中大量定義了內部類。說實話，我之前幾年的C++的經驗中基本沒接觸過這么頻繁使用內部類的東東。--->當然，你可以說STL也大量使用了呀。
我們就把C++的內部類當做普通的類一樣看待吧，其實我感覺也沒什么特殊的含義，和外部類是一樣的，包括函數調用，public/private之類的東西。這個和JAVA的內部類是大不一樣的。
sp<AudioFlinger::PlaybackThread::Track> AudioFlinger::PlaybackThread::createTrack_l( const sp<AudioFlinger::Client>& client, int streamType, uint32_t sampleRate, int format, int channelCount, int frameCount, const sp<IMemory>& sharedBuffer, status_t *status) { sp<Track> track; status_t lStatus; { // scope for mLock Mutex::Autolock _l(mLock); //new 一個track對象 //我有點憤怒了，Android真是層層封裝啊，名字取得也非常相似。 //看看這個參數吧，注意sharedBuffer這個，此時的值應是0 track = new Track(this, client, streamType, sampleRate, format, channelCount, frameCount, sharedBuffer); mTracks.add(track); //把這個track加入到數組中，是為了管理用的。 } lStatus = NO_ERROR; return track; }看到這個數組的存在，我們應該能想到什么嗎？這時已經有：
l 一個MixerThread，內部有一個數組保存track的
看來，不管有多少個AudioTrack，最終在AF端都有一個track對象對應，而且這些所有的track對象都會由一個線程對象來處理。----難怪是Mixer啊
再去看看new Track，我們一直還沒找到共享內存在哪里創建的！！！
AudioFlinger::PlaybackThread::Track::Track( const wp<ThreadBase>& thread, const sp<Client>& client, int streamType, uint32_t sampleRate, int format, int channelCount, int frameCount, const sp<IMemory>& sharedBuffer) : TrackBase(thread, client, sampleRate, format, channelCount, frameCount, 0, sharedBuffer), mMute(false), mSharedBuffer(sharedBuffer), mName(-1) { // mCblk !=NULL?什么時候創建的？？ //只能看基類TrackBase，還是很憤怒，太多繼承了。 if (mCblk != NULL) { mVolume[0] = 1.0f; mVolume[1] = 1.0f; mStreamType = streamType; mCblk->frameSize = AudioSystem::isLinearPCM(format) ? channelCount * sizeof(int16_t) : sizeof(int8_t); } }看看基類TrackBase干嘛了
AudioFlinger::ThreadBase::TrackBase::TrackBase( const wp<ThreadBase>& thread, const sp<Client>& client, uint32_t sampleRate, int format, int channelCount, int frameCount, uint32_t flags, const sp<IMemory>& sharedBuffer) : RefBase(), mThread(thread), mClient(client), mCblk(0), mFrameCount(0), mState(IDLE), mClientTid(-1), mFormat(format), mFlags(flags & ~SYSTEM_FLAGS_MASK) { size_t size = sizeof(audio_track_cblk_t); size_t bufferSize = frameCount*channelCount*sizeof(int16_t); if (sharedBuffer == 0) { size += bufferSize; }//調用client的allocate函數。這個client是什么？就是我們在CreateTrack中創建的
那個Client，我不想再說了。反正這里會創建一塊共享內存
mCblkMemory = client->heap()->allocate(size);
有了共享內存，但是還沒有里邊有同步鎖的那個對象audio_track_cblk_t
mCblk = static_cast<audio_track_cblk_t *>(mCblkMemory->pointer());
下面這個語法好怪啊。什么意思？？？
new(mCblk) audio_track_cblk_t();
//各位，這就是C++語法中的placement new。干啥用的啊?new后面的括號中是一塊buffer，再
后面是一個類的構造函數。對了，這個placement new的意思就是在這塊buffer中構造一個對象。
我們之前的普通new是沒法讓一個對象在某塊指定的內存中創建的。而placement new卻可以。
這樣不就達到我們的目的了嗎？搞一塊共享內存，再在這塊內存上創建一個對象。這樣，這個對象不也就能在兩個內存中共享了嗎？太牛牛牛牛牛了。怎么想到的？
// clear all buffers mCblk->frameCount = frameCount; mCblk->sampleRate = sampleRate; mCblk->channels = (uint8_t)channelCount; }
好了，解決一個重大疑惑，跨進程數據共享的重要數據結構audio_track_cblk_t是通過placement new在一塊共享內存上來創建的。
回到AF的CreateTrack，有這么一句話：
trackHandle = new TrackHandle(track);
return trackHandle；----》注意，這個對象是最終返回到AT進程中的。
trackHandle的構造使用了thread->createTrack_l的返回值。
讀到這里的人，一定會被異常多的class類型，內部類，繼承關系搞瘋掉。說實話，這里廢點心血整個或者paste一個大的UML圖未嘗不可。但是我是不太習慣用圖說話，因為圖我實在是記不住。那好吧。我們就用最簡單的話語爭取把目前出現的對象說清楚。
1 AudioFlinger
class AudioFlinger : public BnAudioFlinger, public IBinder::DeathRecipient
AudioFlinger類是代表整個AudioFlinger服務的類，其余所有的工作類都是通過內部類的方式在其中定義的。你把它當做一個殼子也行吧。
2 Client
Client是描述C/S結構的C端的代表，也就算是一個AT在AF端的對等物吧。不過可不是Binder機制中的BpXXX喔。因為AF是用不到AT的功能的。
class Client : public RefBase { public: sp<AudioFlinger> mAudioFlinger;//代表S端的AudioFlinger sp<MemoryDealer> mMemoryDealer;//每個C端使用的共享內存，通過它分配 pid_t mPid;//C端的進程id };3 TrackHandle
Trackhandle是AT端調用AF的CreateTrack得到的一個基于Binder機制的Track。
這個TrackHandle實際上是對真正干活的PlaybackThread::Track的一個跨進程支持的封裝。
什么意思？本來PlaybackThread::Track是真正在AF中干活的東西，不過為了支持跨進程的話，我們用TrackHandle對其進行了一下包轉。這樣在AudioTrack調用TrackHandle的功能，實際都由TrackHandle調用PlaybackThread::Track來完成了。可以認為是一種Proxy模式吧。
這個就是AudioFlinger異常復雜的一個原因！！！
class TrackHandle : public android::BnAudioTrack { public: TrackHandle(const sp<PlaybackThread::Track>& track); virtual ~TrackHandle(); virtual status_t start(); virtual void stop(); virtual void flush(); virtual void mute(bool); virtual void pause(); virtual void setVolume(float left, float right); virtual sp<IMemory> getCblk() const; sp<PlaybackThread::Track> mTrack; };4 線程類
AF中有好幾種不同類型的線程，分別有對應的線程類型：
l RecordThread：
RecordThread : public ThreadBase, public AudioBufferProvider
用于錄音的線程。
l PlaybackThread:
class PlaybackThread : public ThreadBase
用于播放的線程
l MixerThread
MixerThread : public PlaybackThread
用于混音的線程，注意他是從PlaybackThread派生下來的。
l DirectoutputThread
DirectOutputThread : public PlaybackThread
直接輸出線程，我們之前在代碼里老看到DIRECT_OUTPUT之類的判斷，看來最終和這個線程有關。
l DuplicatingThread：
DuplicatingThread : public MixerThread
復制線程？而且從混音線程中派生？暫時不知道有什么用
這么多線程，都有一個共同的父類ThreadBase，這個是AF對Audio系統單獨定義的一個以Thread為基類的類。------》FT，真的很麻煩。
ThreadBase我們不說了，反正里邊封裝了一些有用的函數。
我們看看PlayingThread吧，里邊由定義了內部類：
5 PlayingThread的內部類Track
我們知道，TrackHandle構造用的那個Track是PlayingThread的createTrack_l得到的。
class Track : public TrackBase
暈喔，又來一個TrackBase。
TrackBase是ThreadBase定義的內部類
class TrackBase : public AudioBufferProvider, public RefBase
基類AudioBufferProvider是一個對Buffer的封裝，以后在AF讀共享緩沖，寫數據到硬件HAL中用得到。
個人感覺：上面這些東西，其實完完全全可以獨立到不同的文件中，然后加一些注釋說明。
寫這樣的代碼，要是我是BOSS的話，一定會很不爽。有什么意義嗎？有什么好處嗎？
好了，這里終于在AF中的createTrack返回了TrackHandle。這個時候系統處于什么狀態？
l AF中的幾個Thread我們之前說了，在AF啟動的某個時間就已經起來了。我們就假設AT調用AF服務前，這個線程就已經啟動了。
這個可以看代碼就知道了：
void AudioFlinger::PlaybackThread::onFirstRef() { const size_t SIZE = 256; char buffer[SIZE]; snprintf(buffer, SIZE, "Playback Thread %p", this); //onFirstRef，實際是RefBase的一個方法，在構造sp的時候就會被調用 //下面的run就真正創建了線程并開始執行threadLoop了 run(buffer, ANDROID_PRIORITY_URGENT_AUDIO); }到底執行哪個線程的threadLoop？我記得我們是根據output句柄來查找線程的。
看看openOutput的實行，真正的線程對象創建是在那兒。
nt AudioFlinger::openOutput(uint32_t *pDevices, uint32_t *pSamplingRate, uint32_t *pFormat, uint32_t *pChannels, uint32_t *pLatencyMs, uint32_t flags) { if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) || (format != AudioSystem::PCM_16_BIT) || (channels != AudioSystem::CHANNEL_OUT_STEREO)) { thread = new DirectOutputThread(this, output, ++mNextThreadId); //如果flags沒有設置直接輸出標準，或者format不是16bit，或者聲道數不是2立體聲 //則創建DirectOutputThread。 } else { //可惜啊，我們創建的是最復雜的MixerThread thread = new MixerThread(this, output, ++mNextThreadId); 1. MixerThread 非常重要的工作線程，我們看看它的構造函數。 AudioFlinger::MixerThread::MixerThread(const sp<AudioFlinger>& audioFlinger, AudioStreamOut* output, int id) : PlaybackThread(audioFlinger, output, id), mAudioMixer(0) { mType = PlaybackThread::MIXER; //混音器對象，傳進去的兩個參數時基類ThreadBase的，都為0 //這個對象巨復雜，最終混音的數據都由它生成，以后再說... mAudioMixer = new AudioMixer(mFrameCount, mSampleRate); }2. AT調用start
此時，AT得到IAudioTrack對象后，調用start函數。
status_t AudioFlinger::TrackHandle::start() { return mTrack->start(); } //果然，自己又不干活，交給mTrack了，這個是PlayintThread createTrack_l得到的Track對象 status_t AudioFlinger::PlaybackThread::Track::start() { status_t status = NO_ERROR; sp<ThreadBase> thread = mThread.promote(); //這個Thread就是調用createTrack_l的那個thread對象，這里是MixerThread if (thread != 0) { Mutex::Autolock _l(thread->mLock); int state = mState; if (mState == PAUSED) { mState = TrackBase::RESUMING; } else { mState = TrackBase::ACTIVE; } //把自己由加到addTrack_l了 //奇怪，我們之前在看createTrack_l的時候，不是已經有個map保存創建的track了 //這里怎么又出現了一個類似的操作？ PlaybackThread *playbackThread = (PlaybackThread *)thread.get(); playbackThread->addTrack_l(this); return status; }看看這個addTrack_l函數
status_t AudioFlinger::PlaybackThread::addTrack_l(const sp<Track>& track) { status_t status = ALREADY_EXISTS; // set retry count for buffer fill track->mRetryCount = kMaxTrackStartupRetries; if (mActiveTracks.indexOf(track) < 0) { mActiveTracks.add(track);//啊，原來是加入到活躍Track的數組啊 status = NO_ERROR; }//我靠，有戲啊！看到這個broadcast，一定要想到：恩，在不遠處有那么一個線程正
//等著這個CV呢。
mWaitWorkCV.broadcast(); return status; }
讓我們想想吧。start是把某個track加入到PlayingThread的活躍Track隊列，然后觸發一個信號事件。由于這個事件是PlayingThread的內部成員變量，而PlayingThread又創建了一個線程，那么難道是那個線程在等待這個事件嗎？這時候有一個活躍track，那個線程應該可以干活了吧？
這個線程是MixerThread。我們去看看它的線程函數threadLoop吧。
bool AudioFlinger::MixerThread::threadLoop() { int16_t* curBuf = mMixBuffer; Vector< sp<Track> > tracksToRemove; while (!exitPending()) { processConfigEvents(); //Mixer進到這個循環中來 mixerStatus = MIXER_IDLE; { // scope for mLock Mutex::Autolock _l(mLock); const SortedVector< wp<Track> >& activeTracks = mActiveTracks; //每次都取當前最新的活躍Track數組 //下面是預備操作，返回狀態看看是否有數據需要獲取 mixerStatus = prepareTracks_l(activeTracks, &tracksToRemove); } //LIKELY，是GCC的一個東西，可以優化編譯后的代碼 //就當做是TRUE吧 if (LIKELY(mixerStatus == MIXER_TRACKS_READY)) { // mix buffers... //調用混音器，把buf傳進去，估計得到了混音后的數據了 //curBuf是mMixBuffer，PlayingThread的內部buffer，在某個地方已經創建好了， //緩存足夠大 mAudioMixer->process(curBuf); sleepTime = 0; standbyTime = systemTime() + kStandbyTimeInNsecs; } 有數據要寫到硬件中，肯定不能sleep了呀 if (sleepTime == 0) { //把緩存的數據寫到outPut中。這個mOutput是AudioStreamOut //由Audio HAL的那個對象創建得到。等我們以后分析再說 int bytesWritten = (int)mOutput->write(curBuf, mixBufferSize); mStandby = false; } else { usleep(sleepTime);//如果沒有數據，那就休息吧.. }3. MixerThread核心
到這里，大家是不是有種煥然一新的感覺？恩，對了，AF的工作就是如此的精密，每個部分都配合得絲絲入扣。不過對于我們看代碼的人來說，實在搞不懂這么做的好處----哈哈 有點扯遠了。
MixerThread的線程循環中，最重要的兩個函數：
prepare_l和mAudioMixer->process，我們一一來看看。 uint32_t AudioFlinger::MixerThread::prepareTracks_l(const SortedVector< wp<Track> >& activeTracks, Vector< sp<Track> > *tracksToRemove) { uint32_t mixerStatus = MIXER_IDLE; //得到活躍track個數，這里假設就是我們創建的那個AT吧，那么count=1 size_t count = activeTracks.size(); float masterVolume = mMasterVolume; bool masterMute = mMasterMute; for (size_t i=0 ; i<count ; i++) { sp<Track> t = activeTracks[i].promote(); Track* const track = t.get()； //得到placement new分配的那個跨進程共享的對象 audio_track_cblk_t* cblk = track->cblk(); //設置混音器，當前活躍的track。 mAudioMixer->setActiveTrack(track->name()); if (cblk->framesReady() && (track->isReady() || track->isStopped()) && !track->isPaused() && !track->isTerminated()) { // compute volume for this track //AT已經write數據了。所以肯定會進到這來。 int16_t left, right; if (track->isMuted() || masterMute || track->isPausing() || mStreamTypes[track->type()].mute) { left = right = 0; if (track->isPausing()) { track->setPaused(); } //AT設置的音量假設不為零，我們需要聆聽聲音！ //所以走else流程 } else { // read original volumes with volume control float typeVolume = mStreamTypes[track->type()].volume; float v = masterVolume * typeVolume; float v_clamped = v * cblk->volume[0]; if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN; left = int16_t(v_clamped); v_clamped = v * cblk->volume[1]; if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN; right = int16_t(v_clamped); //計算音量 } //注意，這里對混音器設置了數據提供來源，是一個track，還記得我們前面說的嗎？Track從 AudioBufferProvider派生 mAudioMixer->setBufferProvider(track); mAudioMixer->enable(AudioMixer::MIXING); int param = AudioMixer::VOLUME; //為這個track設置左右音量等 mAudioMixer->setParameter(param, AudioMixer::VOLUME0, left); mAudioMixer->setParameter(param, AudioMixer::VOLUME1, right); mAudioMixer->setParameter( AudioMixer::TRACK, AudioMixer::FORMAT, track->format()); mAudioMixer->setParameter( AudioMixer::TRACK, AudioMixer::CHANNEL_COUNT, track->channelCount()); mAudioMixer->setParameter( AudioMixer::RESAMPLE, AudioMixer::SAMPLE_RATE, int(cblk->sampleRate)); } else { if (track->isStopped()) { track->reset(); } //如果這個track已經停止了，那么把它加到需要移除的track隊列tracksToRemove中去 //同時停止它在AudioMixer中的混音 if (track->isTerminated() || track->isStopped() || track->isPaused()) { tracksToRemove->add(track); mAudioMixer->disable(AudioMixer::MIXING); } else { mAudioMixer->disable(AudioMixer::MIXING); } } } // remove all the tracks that need to be... count = tracksToRemove->size(); return mixerStatus; } 看明白了嗎？prepare_l的功能是什么？根據當前活躍的track隊列，來為混音器設置信息。可想而知，一個track必然在混音器中有一個對應的東西。我們待會分析AudioMixer的時候再詳述。 為混音器準備好后，下面調用它的process函數 void AudioMixer::process(void* output) { mState.hook(&mState, output);//hook？難道是鉤子函數？ }暈乎，就這么簡單的函數？？？
CTRL+左鍵，hook是一個函數指針啊，在哪里賦值的？具體實現函數又是哪個？
沒辦法了，只能分析AudioMixer類了。
4. AudioMixer
AudioMixer實現在framework/base/libs/audioflinger/AudioMixer.cpp中
AudioMixer::AudioMixer(size_t frameCount, uint32_t sampleRate) : mActiveTrack(0), mTrackNames(0), mSampleRate(sampleRate) { mState.enabledTracks= 0; mState.needsChanged = 0; mState.frameCount = frameCount; mState.outputTemp = 0; mState.resampleTemp = 0; mState.hook = process__nop;//process__nop，是該類的靜態函數 track_t* t = mState.tracks; //支持32路混音。牛死了 for (int i=0 ; i<32 ; i++) { t->needs = 0; t->volume[0] = UNITY_GAIN; t->volume[1] = UNITY_GAIN; t->volumeInc[0] = 0; t->volumeInc[1] = 0; t->channelCount = 2; t->enabled = 0; t->format = 16; t->buffer.raw = 0; t->bufferProvider = 0; t->hook = 0; t->resampler = 0; t->sampleRate = mSampleRate; t->in = 0; t++; } }//其中，mState是在AudioMixer.h中定義的一個數據結構
//注意，source insight沒辦法解析這個mState，因為....見下面的注釋。
struct state_t { uint32_t enabledTracks; uint32_t needsChanged; size_t frameCount; mix_t hook; int32_t *outputTemp; int32_t *resampleTemp; int32_t reserved[2]; track_t tracks[32];// __attribute__((aligned(32)));《--把這里注釋掉 //否則source insight會解析不了這個state_t類型 };int mActiveTrack;
uint32_t mTrackNames;//names？搞得像字符串，實際是一個int
const uint32_t mSampleRate;
state_t mState
好了，沒什么嗎。hook對應的可選函數實現有：
process__validate
process__nop
process__genericNoResampling
process__genericResampling
process__OneTrack16BitsStereoNoResampling
process__TwoTracks16BitsStereoNoResampling
AudioMixer構造的時候，hook是process__nop，有幾個地方會改變這個函數指針的指向。
這部分涉及到數字音頻技術，我就無力講解了。我們看看最接近的函數
process__OneTrack16BitsStereoNoResampling
void AudioMixer::process__OneTrack16BitsStereoNoResampling(state_t* state, void* output)
{
單track，16bit雙聲道，不需要重采樣,大部分是這種情況了
const int i = 31 - __builtin_clz(state->enabledTracks); const track_t& t = state->tracks[i]; AudioBufferProvider::Buffer& b(t.buffer); int32_t* out = static_cast<int32_t*>(output); size_t numFrames = state->frameCount; const int16_t vl = t.volume[0]; const int16_t vr = t.volume[1]; const uint32_t vrl = t.volumeRL; while (numFrames) { b.frameCount = numFrames; //獲得buffer t.bufferProvider->getNextBuffer(&b); int16_t const *in = b.i16; size_t outFrames = b.frameCount; if UNLIKELY--->不走這. else { do { //計算音量等數據，和數字音頻技術有關。這里不說了 uint32_t rl = *reinterpret_cast<uint32_t const *>(in); in += 2; int32_t l = mulRL(1, rl, vrl) >> 12; int32_t r = mulRL(0, rl, vrl) >> 12; *out++ = (r<<16) | (l & 0xFFFF); } while (--outFrames); } numFrames -= b.frameCount; //釋放buffer。 t.bufferProvider->releaseBuffer(&b); } }好像挺簡單的啊，不就是把數據處理下嘛。這里注意下buffer。到現在，我們還沒看到取共享內存里AT端write的數據吶。
那只能到bufferProvider去看了。
注意，這里用的是AudioBufferProvider基類，實際的對象是Track。它從AudioBufferProvider派生。
我們用得是PlaybackThread的這個Track
status_t AudioFlinger::PlaybackThread::Track::getNextBuffer(AudioBufferProvider::Buffer* buffer) { //一陣暗喜吧。千呼萬喚始出來，終于見到cblk了 audio_track_cblk_t* cblk = this->cblk(); uint32_t framesReady; uint32_t framesReq = buffer->frameCount; //哈哈，看看數據準備好了沒， framesReady = cblk->framesReady(); if (LIKELY(framesReady)) { uint32_t s = cblk->server; uint32_t bufferEnd = cblk->serverBase + cblk->frameCount; bufferEnd = (cblk->loopEnd < bufferEnd) ? cblk->loopEnd : bufferEnd; if (framesReq > framesReady) { framesReq = framesReady; } if (s + framesReq > bufferEnd) { framesReq = bufferEnd - s; } 獲得真實的數據地址 buffer->raw = getBuffer(s, framesReq); if (buffer->raw == 0) goto getNextBuffer_exit; buffer->frameCount = framesReq; return NO_ERROR; } getNextBuffer_exit: buffer->raw = 0; buffer->frameCount = 0; return NOT_ENOUGH_DATA; } 再看看釋放緩沖的地方：releaseBuffer，這個直接在ThreadBase中實現了 void AudioFlinger::ThreadBase::TrackBase::releaseBuffer(AudioBufferProvider::Buffer* buffer) { buffer->raw = 0; mFrameCount = buffer->frameCount; step(); buffer->frameCount = 0; }看看step吧。mFrameCount表示我已經用完了這么多幀。
bool AudioFlinger::ThreadBase::TrackBase::step() { bool result; audio_track_cblk_t* cblk = this->cblk(); result = cblk->stepServer(mFrameCount);//哼哼，調用cblk的stepServer，更新 服務端的使用位置 return result; }到這里，大伙應該都明白了吧。原來AudioTrack中write的數據，最終是這么被使用的呀！！！
恩，看一個process__OneTrack16BitsStereoNoResampling不過癮，再看看
process__TwoTracks16BitsStereoNoResampling。
void AudioMixer::process__TwoTracks16BitsStereoNoResampling(state_t* state, void* output) int i; uint32_t en = state->enabledTracks; i = 31 - __builtin_clz(en); const track_t& t0 = state->tracks[i]; AudioBufferProvider::Buffer& b0(t0.buffer); en &= ~(1<<i); i = 31 - __builtin_clz(en); const track_t& t1 = state->tracks[i]; AudioBufferProvider::Buffer& b1(t1.buffer); int16_t const *in0; const int16_t vl0 = t0.volume[0]; const int16_t vr0 = t0.volume[1]; size_t frameCount0 = 0; int16_t const *in1; const int16_t vl1 = t1.volume[0]; const int16_t vr1 = t1.volume[1]; size_t frameCount1 = 0; int32_t* out = static_cast<int32_t*>(output); size_t numFrames = state->frameCount; int16_t const *buff = NULL; while (numFrames) { if (frameCount0 == 0) { b0.frameCount = numFrames; t0.bufferProvider->getNextBuffer(&b0); if (b0.i16 == NULL) { if (buff == NULL) { buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount]; } in0 = buff; b0.frameCount = numFrames; } else { in0 = b0.i16; } frameCount0 = b0.frameCount; } if (frameCount1 == 0) { b1.frameCount = numFrames; t1.bufferProvider->getNextBuffer(&b1); if (b1.i16 == NULL) { if (buff == NULL) { buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount]; } in1 = buff; b1.frameCount = numFrames; } else { in1 = b1.i16; } frameCount1 = b1.frameCount; } size_t outFrames = frameCount0 < frameCount1?frameCount0:frameCount1; numFrames -= outFrames; frameCount0 -= outFrames; frameCount1 -= outFrames; do { int32_t l0 = *in0++; int32_t r0 = *in0++; l0 = mul(l0, vl0); r0 = mul(r0, vr0); int32_t l = *in1++; int32_t r = *in1++; l = mulAdd(l, vl1, l0) >> 12; r = mulAdd(r, vr1, r0) >> 12; // clamping... l = clamp16(l); r = clamp16(r); *out++ = (r<<16) | (l & 0xFFFF); } while (--outFrames); if (frameCount0 == 0) { t0.bufferProvider->releaseBuffer(&b0); } if (frameCount1 == 0) { t1.bufferProvider->releaseBuffer(&b1); } } if (buff != NULL) { delete [] buff; } }看不懂了吧？？哈哈，知道有這回事就行了，專門搞數字音頻的需要好好研究下了！
三 再論共享audio_track_cblk_t
為什么要再論這個？因為我在網上找了下，有人說audio_track_cblk_t是一個環形buffer，環形buffer是什么意思？自己查查！
這個嗎，和我之前的工作經歷有關系，某BOSS費盡心機想搞一個牛掰掰的環形buffer，搞得我累死了。現在audio_track_cblk_t是環形buffer？我倒是想看看它是怎么實現的。
順便我們要解釋下，audio_track_cblk_t的使用和我之前說的Lock,讀/寫，Unlock不太一樣。為何？
l 第一因為我們沒在AF代碼中看到有緩沖buffer方面的wait，MixThread只有當沒有數據的時候會usleep一下。
l 第二，如果有多個track，多個audio_track_cblk_t的話，假如又是采用wait信號的辦法，那么由于pthread庫缺乏WaitForMultiObjects的機制，那么到底該等哪一個？這個問題是我們之前在做跨平臺同步庫的一個重要難題。
1. 寫者的使用
我們集中到audio_track_cblk_t這個類，來看看寫者是如何使用的。寫者就是AudioTrack端，在這個類中，叫user
l framesAvailable，看看是否有空余空間
l buffer，獲得寫空間起始地址
l stepUser，更新user的位置。
2. 讀者的使用
讀者是AF端，在這個類中加server。
l framesReady，獲得可讀的位置
l stepServer，更新讀者的位置
看看這個類的定義：
struct audio_track_cblk_t { Mutex lock; //同步鎖 Condition cv;//CV volatile uint32_t user;//寫者 volatile uint32_t server;//讀者 uint32_t userBase;//寫者起始位置 uint32_t serverBase;//讀者起始位置 void* buffers; uint32_t frameCount; // Cache line boundary uint32_t loopStart; //循環起始 uint32_t loopEnd; //循環結束 int loopCount; uint8_t out; //如果是Track的話，out就是1，表示輸出。 }注意這是volatile，跨進程的對象，看來這個volatile也是可以跨進程的嘛。
l 唉，又要發揮下了。volatile只是告訴編譯器，這個單元的地址不要cache到CPU的緩沖中。也就是每次取值的時候都要到實際內存中去讀，而且可能讀內存的時候先要鎖一下總線。防止其他CPU核執行的時候同時去修改。由于是跨進程共享的內存，這塊內存在兩個進程都是能見到的，又鎖總線了，又是同一塊內存，volatile當然保證了同步一致性。
l loopStart和loopEnd這兩個值是表示循環播放的起點和終點的，下面還有一個loopCount嗎，表示循環播放次數的
那就分析下吧。
先看寫者的那幾個函數
4 寫者分析
先用frameavail看看當前剩余多少空間，我們可以假設是第一次進來嘛。讀者還在那sleep呢。
uint32_t audio_track_cblk_t::framesAvailable() { Mutex::Autolock _l(lock); return framesAvailable_l(); } int32_t audio_track_cblk_t::framesAvailable_l() { uint32_t u = this->user; 當前寫者位置，此時也為0 uint32_t s = this->server; //當前讀者位置，此時為0 if (out) { out為1 uint32_t limit = (s < loopStart) ? s : loopStart; 我們不設循環播放時間嗎。所以loopStart是初始值INT_MAX，所以limit=0 return limit + frameCount - u; //返回0+frameCount-0，也就是全緩沖最大的空間。假設frameCount=1024幀 } }然后調用buffer獲得其實位置，buffer就是得到一個地址位置。
void* audio_track_cblk_t::buffer(uint32_t offset) const
{
return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;
}
完了，我們更新寫者，調用stepUser
uint32_t audio_track_cblk_t::stepUser(uint32_t frameCount)
{
//framecount，表示我寫了多少，假設這一次寫了512幀
uint32_t u = this->user;//user位置還沒更新呢，此時u=0；
u += frameCount;//u更新了，u=512
// Ensure that user is never ahead of server for AudioRecord
if (out) {
//沒甚，計算下等待時間
}
//userBase還是初始值為0，可惜啊，我們只寫了1024的一半
//所以userBase加不了
if (u >= userBase + this->frameCount) {
userBase += this->frameCount;
//但是這句話很重要，userBase也更新了。根據buffer函數的實現來看，似乎把這個
//環形緩沖鋪直了....連綿不絕。
}
this->user = u;//喔，user位置也更新為512了，但是useBase還是0
return u;
}
好了，假設寫者這個時候sleep了，而讀者起來了。
5 讀者分析
uint32_t audio_track_cblk_t::framesReady() { uint32_t u = this->user; //u為512 uint32_t s = this->server;//還沒讀呢，s為零 if (out) { if (u < loopEnd) { return u - s;//loopEnd也是INT_MAX，所以這里返回512，表示有512幀可讀了 } else { Mutex::Autolock _l(lock); if (loopCount >= 0) { return (loopEnd - loopStart)*loopCount + u - s; } else { return UINT_MAX; } } } else { return s - u; } }使用完了，然后stepServer
bool audio_track_cblk_t::stepServer(uint32_t frameCount) { status_t err; err = lock.tryLock(); uint32_t s = this->server; s += frameCount; //讀了512幀了，所以s=512 if (out) { }沒有設置循環播放嘛，所以不走這個
if (s >= loopEnd) { s = loopStart; if (--loopCount == 0) { loopEnd = UINT_MAX; loopStart = UINT_MAX; } }//一樣啊，把環形緩沖鋪直了
if (s >= serverBase + this->frameCount) { serverBase += this->frameCount; } this->server = s; //server為512了 cv.signal(); //讀者讀完了。觸發下寫者吧。 lock.unlock(); return true;6 真的是環形緩沖嗎？
環形緩沖是這樣一個場景，現在buffer共1024幀。
假設：
l 寫者先寫到1024幀
l 讀者讀到512幀
l 那么，寫者還可以從頭寫512幀。
所以，我們得回頭看看frameavail是不是把這512幀算進來了。
uint32_t audio_track_cblk_t::framesAvailable_l() { uint32_t u = this->user; //1024 uint32_t s = this->server;//512 if (out) { uint32_t limit = (s < loopStart) ? s : loopStart; return limit + frameCount - u;返回512，用上了！ } }再看看stepUser這句話
if (u >= userBase + this->frameCount) {u為1024，userBase為0，frameCount為1024 userBase += this->frameCount;//好，userBase也為1024了 } 看看bufferreturn (int8_t *)this->buffers + (offset - userBase) * this->frameSize;
看完上述內容，你們掌握Android中AudioFlinger的作用是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
