溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“Android中的AudioFlinger有什么用”，內容詳細，步驟清晰，細節處理妥當，希望這篇“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進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
