溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本文小編為大家詳細介紹“Android中的AudioFlinger有什么用”，內(nèi)容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“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的實例化靜態(tài)函數(shù)，在framework/base/libs/audioFlinger/audioFlinger.cpp中
void AudioFlinger::instantiate() { defaultServiceManager()->addService( //把AF實例加入系統(tǒng)服務 String16("media.audio_flinger"), new AudioFlinger()); }再來看看它的構造函數(shù)是什么做的。
AudioFlinger::AudioFlinger() : BnAudioFlinger(),//初始化基類 mAudioHardware(0), //audio硬件的HAL對象 mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0) { mHardwareStatus = AUDIO_HW_IDLE; //創(chuàng)建代表Audio硬件的HAL對象 mAudioHardware = AudioHardwareInterface::create(); mHardwareStatus = AUDIO_HW_INIT; if (mAudioHardware->initCheck() == NO_ERROR) { setMode(AudioSystem::MODE_NORMAL); //設置系統(tǒng)的聲音模式等，其實就是設置硬件的模式 setMasterVolume(1.0f); setMasterMute(false); } }AF中經(jīng)常有setXXX的函數(shù)，到底是干什么的呢？我們看看setMode函數(shù)。
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系統(tǒng)啟動的時候，看來AF也準備好硬件了。不過，創(chuàng)建硬件對象就代表我們可以播放了嗎？
我這里簡單的把AT調(diào)用AF的流程列一下，待會按這個順序分析AF的工作方式。
--參加AudioTrack分析的4.1節(jié)
1. 創(chuàng)建
AudioTrack* lpTrack = new AudioTrack(); lpTrack->set(...);
這個就進入到C++的AT了。下面是AT的set函數(shù)
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(); //下面很重要，調(diào)用AF的createTrack獲得一個IAudioTrack對象 sp<IAudioTrack> track = audioFlinger->createTrack(); sp<IMemory> cblk = track->getCblk();//獲取共享內(nèi)存的管理結構
總結一下創(chuàng)建的流程，AT調(diào)用AF的createTrack獲得一個IAudioTrack對象，然后從這個對象中獲得共享內(nèi)存的對象。
2. start和write
看看AT的start，估計就是調(diào)用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的調(diào)用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,//需要創(chuàng)建的buffer可包含的幀數(shù) 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); //根據(jù)output句柄，獲得線程？ PlaybackThread *thread = checkPlaybackThread_l(output); //看看這個進程是不是已經(jīng)是AF的客戶了 //這里說明一下，由于是C/S架構，那么作為服務端的AF肯定有地方保存作為C的AT的信息 //那么，AF是根據(jù)pid作為客戶端的唯一標示的 //mClients是一個類似map的數(shù)據(jù)組織結構 wclient = mClients.valueFor(pid); if (wclient != NULL) { } else { //如果還沒有這個客戶信息，就創(chuàng)建一個，并加入到map中去 client = new Client(this, pid); mClients.add(pid, client); } //從剛才找到的那個線程對象中創(chuàng)建一個track track = thread->createTrack_l(client, streamType, sampleRate, format, channelCount, frameCount, sharedBuffer, &lStatus); } //喔，還有一個trackHandle，而且返回到AF端的是這個trackHandle對象 trackHandle = new TrackHandle(track); return trackHandle; }這個AF函數(shù)中，突然冒出來了很多新類型的數(shù)據(jù)結構。說實話，我剛開始接觸的時候，大腦因為常接觸到這些眼生的東西而死機！大家先不要拘泥于這些東西，我會一一分析到的。
先進入到checkPlaybackThread_l看看。
AudioFlinger::PlaybackThread *AudioFlinger::checkPlaybackThread_l(int output) const { PlaybackThread *thread = NULL; //看到這種indexOfKey的東西，應該立即能想到： //喔，這可能是一個map之類的東西，根據(jù)key能找到實際的value if (mPlaybackThreads.indexOfKey(output) >= 0) { thread = (PlaybackThread *)mPlaybackThreads.valueFor(output).get(); } //這個函數(shù)的意思是根據(jù)output值，從一堆線程中找到對應的那個線程 return thread; }看到這里很疑惑?。?/p>
l AF的構造函數(shù)中沒有創(chuàng)建線程，只創(chuàng)建了一個audio的HAL對象
l 如果AT是AF的第一個客戶的話，我們剛才的調(diào)用流程里邊，也沒看到哪有創(chuàng)建線程的地方呀。
l output是個什么玩意兒？為什么會根據(jù)它作為key來找線程呢？
看來，我們得去Output的來源那看看了。
我們知道，output的來源是由AT的set函數(shù)得到的：如下：
audio_io_handle_t output = AudioSystem::getOutput( (AudioSystem::stream_type)streamType, //MUSIC類型 sampleRate, //8000 format, //PCM_16 channels, //2兩個聲道 (AudioSystem::output_flags)flags//0 );
上面這幾個參數(shù)后續(xù)不再提示了，大家知道這些值都是由AT做為切入點傳進去的
然后它在調(diào)用AT自己的createTrack，最終把這個output值傳遞到AF了。其中audio_io_handle_t類型就是一個int類型。
//叫handle?。亢孟駆inux下這種叫法的很少，難道又是受MS的影響嗎？
我們進到AudioSystem::getOutput看看。注意，大家想想這是系統(tǒng)的第一次調(diào)用,而且發(fā)生在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); //根據(jù)我們的參數(shù)，我們會走到這個里邊來 //喔，又是從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是如何創(chuàng)建的。不過這個剛才已經(jīng)說了，是和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做為參數(shù) //我們這里先使用普適的看看吧 mpPolicyManager = new AudioPolicyManagerBase(this); //使用硬件廠商提供的特殊的AudioPolicyManager //mpPolicyManager = createAudioPolicyManager(this); } }我們看看AudioManagerBase的構造函數(shù)吧，在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中，調(diào)用set函數(shù)
l 這個函數(shù)會通過AudioSystem::getOutput來得到一個output的句柄
l AS的getOutput會調(diào)用AudioPolicyService的getOutput
l 然后我們就沒繼續(xù)講APS的getOutPut了，而是去看看APS創(chuàng)建的東西
l 發(fā)現(xiàn)APS創(chuàng)建的時候會創(chuàng)建一個AudioManagerBase，這個AMB的創(chuàng)建又會調(diào)用APS的openOutput。
l APS的openOutput又會調(diào)用AudioFlinger的openOutput
有一個疑問，AT中set參數(shù)會和APS構造時候最終傳入到AF的openOutput一樣嗎？如果不一樣，那么構造時候openOutput的又是什么參數(shù)呢？
先放下這個懸念，我們繼續(xù)從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; //這個是在哪里創(chuàng)建的？在AMB構造的時候.. return output; }具體AMB的分析待以后Audio系統(tǒng)策略的時候我們再說吧。反正，到這里，我們知道了，在APS構造的時候會open一個Output，而這個Output又會調(diào)用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對象創(chuàng)建一個AudioStreamOut對象 AudioStreamOut *output = mAudioHardware->openOutputStream(*pDevices, (int *)&format, &channels, &samplingRate, &status); mHardwareStatus = AUDIO_HW_IDLE; if (output != 0) { //創(chuàng)建一個Mixer線程 thread = new MixerThread(this, output, ++mNextThreadId); } //終于找到了，把這個線程加入線程管理組織中 mPlaybackThreads.add(mNextThreadId, thread); return mNextThreadId; } }明白了，看來AT在調(diào)用AF的createTrack的之前，AF已經(jīng)在某個時候把線程創(chuàng)建好了，而且是一個Mixer類型的線程，看來和混音有關系呀。這個似乎和我們開始設想的AF工作有點聯(lián)系喔。Lock，讀緩存，寫Audio硬件，Unlock?？赡芏际窃谶@個線程里邊做的。
2 繼續(xù)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); //暈，調(diào)用這個線程對象的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的意思是這個函數(shù)進入之前已經(jīng)獲得同步鎖了。
跟著sourceinsight ctrl+鼠標左鍵就進入到下面這個函數(shù)。
下面這個函數(shù)的簽名好長啊。這是為何？
原來Android的C++類中大量定義了內(nèi)部類。說實話，我之前幾年的C++的經(jīng)驗中基本沒接觸過這么頻繁使用內(nèi)部類的東東。--->當然，你可以說STL也大量使用了呀。
我們就把C++的內(nèi)部類當做普通的類一樣看待吧，其實我感覺也沒什么特殊的含義，和外部類是一樣的，包括函數(shù)調(diào)用，public/private之類的東西。這個和JAVA的內(nèi)部類是大不一樣的。
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真是層層封裝啊，名字取得也非常相似。 //看看這個參數(shù)吧，注意sharedBuffer這個，此時的值應是0 track = new Track(this, client, streamType, sampleRate, format, channelCount, frameCount, sharedBuffer); mTracks.add(track); //把這個track加入到數(shù)組中，是為了管理用的。 } lStatus = NO_ERROR; return track; }看到這個數(shù)組的存在，我們應該能想到什么嗎？這時已經(jīng)有：
l 一個MixerThread，內(nèi)部有一個數(shù)組保存track的
看來，不管有多少個AudioTrack，最終在AF端都有一個track對象對應，而且這些所有的track對象都會由一個線程對象來處理。----難怪是Mixer啊
再去看看new Track，我們一直還沒找到共享內(nèi)存在哪里創(chuàng)建的?。?！
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?什么時候創(chuàng)建的？？ //只能看基類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; }//調(diào)用client的allocate函數(shù)。這個client是什么？就是我們在CreateTrack中創(chuàng)建的
那個Client，我不想再說了。反正這里會創(chuàng)建一塊共享內(nèi)存
mCblkMemory = client->heap()->allocate(size);
有了共享內(nèi)存，但是還沒有里邊有同步鎖的那個對象audio_track_cblk_t
mCblk = static_cast<audio_track_cblk_t *>(mCblkMemory->pointer());
下面這個語法好怪啊。什么意思？？？
new(mCblk) audio_track_cblk_t();
//各位，這就是C++語法中的placement new。干啥用的啊?new后面的括號中是一塊buffer，再
后面是一個類的構造函數(shù)。對了，這個placement new的意思就是在這塊buffer中構造一個對象。
我們之前的普通new是沒法讓一個對象在某塊指定的內(nèi)存中創(chuàng)建的。而placement new卻可以。
這樣不就達到我們的目的了嗎？搞一塊共享內(nèi)存，再在這塊內(nèi)存上創(chuàng)建一個對象。這樣，這個對象不也就能在兩個內(nèi)存中共享了嗎？太牛牛牛牛牛了。怎么想到的？
// clear all buffers mCblk->frameCount = frameCount; mCblk->sampleRate = sampleRate; mCblk->channels = (uint8_t)channelCount; }
好了，解決一個重大疑惑，跨進程數(shù)據(jù)共享的重要數(shù)據(jù)結構audio_track_cblk_t是通過placement new在一塊共享內(nèi)存上來創(chuàng)建的。
回到AF的CreateTrack，有這么一句話：
trackHandle = new TrackHandle(track);
return trackHandle；----》注意，這個對象是最終返回到AT進程中的。
trackHandle的構造使用了thread->createTrack_l的返回值。
讀到這里的人，一定會被異常多的class類型，內(nèi)部類，繼承關系搞瘋掉。說實話，這里廢點心血整個或者paste一個大的UML圖未嘗不可。但是我是不太習慣用圖說話，因為圖我實在是記不住。那好吧。我們就用最簡單的話語爭取把目前出現(xiàn)的對象說清楚。
1 AudioFlinger
class AudioFlinger : public BnAudioFlinger, public IBinder::DeathRecipient
AudioFlinger類是代表整個AudioFlinger服務的類，其余所有的工作類都是通過內(nèi)部類的方式在其中定義的。你把它當做一個殼子也行吧。
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端使用的共享內(nèi)存，通過它分配 pid_t mPid;//C端的進程id };3 TrackHandle
Trackhandle是AT端調(diào)用AF的CreateTrack得到的一個基于Binder機制的Track。
這個TrackHandle實際上是對真正干活的PlaybackThread::Track的一個跨進程支持的封裝。
什么意思？本來PlaybackThread::Track是真正在AF中干活的東西，不過為了支持跨進程的話，我們用TrackHandle對其進行了一下包轉。這樣在AudioTrack調(diào)用TrackHandle的功能，實際都由TrackHandle調(diào)用PlaybackThread::Track來完成了。可以認為是一種Proxy模式吧。
這個就是AudioFlinger異常復雜的一個原因！?。?/p>
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系統(tǒng)單獨定義的一個以Thread為基類的類。------》FT，真的很麻煩。
ThreadBase我們不說了，反正里邊封裝了一些有用的函數(shù)。
我們看看PlayingThread吧，里邊由定義了內(nèi)部類：
5 PlayingThread的內(nèi)部類Track
我們知道，TrackHandle構造用的那個Track是PlayingThread的createTrack_l得到的。
class Track : public TrackBase
暈喔，又來一個TrackBase。
TrackBase是ThreadBase定義的內(nèi)部類
class TrackBase : public AudioBufferProvider, public RefBase
基類AudioBufferProvider是一個對Buffer的封裝，以后在AF讀共享緩沖，寫數(shù)據(jù)到硬件HAL中用得到。
個人感覺：上面這些東西，其實完完全全可以獨立到不同的文件中，然后加一些注釋說明。
寫這樣的代碼，要是我是BOSS的話，一定會很不爽。有什么意義嗎？有什么好處嗎？
好了，這里終于在AF中的createTrack返回了TrackHandle。這個時候系統(tǒng)處于什么狀態(tài)？
l AF中的幾個Thread我們之前說了，在AF啟動的某個時間就已經(jīng)起來了。我們就假設AT調(diào)用AF服務前，這個線程就已經(jīng)啟動了。
這個可以看代碼就知道了：
void AudioFlinger::PlaybackThread::onFirstRef() { const size_t SIZE = 256; char buffer[SIZE]; snprintf(buffer, SIZE, "Playback Thread %p", this); //onFirstRef，實際是RefBase的一個方法，在構造sp的時候就會被調(diào)用 //下面的run就真正創(chuàng)建了線程并開始執(zhí)行threadLoop了 run(buffer, ANDROID_PRIORITY_URGENT_AUDIO); }到底執(zhí)行哪個線程的threadLoop？我記得我們是根據(jù)output句柄來查找線程的。
看看openOutput的實行，真正的線程對象創(chuàng)建是在那兒。
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，或者聲道數(shù)不是2立體聲 //則創(chuàng)建DirectOutputThread。 } else { //可惜啊，我們創(chuàng)建的是最復雜的MixerThread thread = new MixerThread(this, output, ++mNextThreadId); 1. MixerThread 非常重要的工作線程，我們看看它的構造函數(shù)。 AudioFlinger::MixerThread::MixerThread(const sp<AudioFlinger>& audioFlinger, AudioStreamOut* output, int id) : PlaybackThread(audioFlinger, output, id), mAudioMixer(0) { mType = PlaybackThread::MIXER; //混音器對象，傳進去的兩個參數(shù)時基類ThreadBase的，都為0 //這個對象巨復雜，最終混音的數(shù)據(jù)都由它生成，以后再說... mAudioMixer = new AudioMixer(mFrameCount, mSampleRate); }2. AT調(diào)用start
此時，AT得到IAudioTrack對象后，調(diào)用start函數(shù)。
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就是調(diào)用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的時候，不是已經(jīng)有個map保存創(chuàng)建的track了 //這里怎么又出現(xiàn)了一個類似的操作？ PlaybackThread *playbackThread = (PlaybackThread *)thread.get(); playbackThread->addTrack_l(this); return status; }看看這個addTrack_l函數(shù)
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的數(shù)組啊 status = NO_ERROR; }//我靠，有戲?。】吹竭@個broadcast，一定要想到：恩，在不遠處有那么一個線程正
//等著這個CV呢。
mWaitWorkCV.broadcast(); return status; }
讓我們想想吧。start是把某個track加入到PlayingThread的活躍Track隊列，然后觸發(fā)一個信號事件。由于這個事件是PlayingThread的內(nèi)部成員變量，而PlayingThread又創(chuàng)建了一個線程，那么難道是那個線程在等待這個事件嗎？這時候有一個活躍track，那個線程應該可以干活了吧？
這個線程是MixerThread。我們?nèi)タ纯此木€程函數(shù)threadLoop吧。
bool AudioFlinger::MixerThread::threadLoop() { int16_t* curBuf = mMixBuffer; Vector< sp<Track> > tracksToRemove; while (!exitPending()) { processConfigEvents(); //Mixer進到這個循環(huán)中來 mixerStatus = MIXER_IDLE; { // scope for mLock Mutex::Autolock _l(mLock); const SortedVector< wp<Track> >& activeTracks = mActiveTracks; //每次都取當前最新的活躍Track數(shù)組 //下面是預備操作，返回狀態(tài)看看是否有數(shù)據(jù)需要獲取 mixerStatus = prepareTracks_l(activeTracks, &tracksToRemove); } //LIKELY，是GCC的一個東西，可以優(yōu)化編譯后的代碼 //就當做是TRUE吧 if (LIKELY(mixerStatus == MIXER_TRACKS_READY)) { // mix buffers... //調(diào)用混音器，把buf傳進去，估計得到了混音后的數(shù)據(jù)了 //curBuf是mMixBuffer，PlayingThread的內(nèi)部buffer，在某個地方已經(jīng)創(chuàng)建好了， //緩存足夠大 mAudioMixer->process(curBuf); sleepTime = 0; standbyTime = systemTime() + kStandbyTimeInNsecs; } 有數(shù)據(jù)要寫到硬件中，肯定不能sleep了呀 if (sleepTime == 0) { //把緩存的數(shù)據(jù)寫到outPut中。這個mOutput是AudioStreamOut //由Audio HAL的那個對象創(chuàng)建得到。等我們以后分析再說 int bytesWritten = (int)mOutput->write(curBuf, mixBufferSize); mStandby = false; } else { usleep(sleepTime);//如果沒有數(shù)據(jù)，那就休息吧.. }3. MixerThread核心
到這里，大家是不是有種煥然一新的感覺？恩，對了，AF的工作就是如此的精密，每個部分都配合得絲絲入扣。不過對于我們看代碼的人來說，實在搞不懂這么做的好處----哈哈 有點扯遠了。
MixerThread的線程循環(huán)中，最重要的兩個函數(shù)：
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個數(shù)，這里假設就是我們創(chuàng)建的那個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已經(jīng)write數(shù)據(jù)了。所以肯定會進到這來。 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); //計算音量 } //注意，這里對混音器設置了數(shù)據(jù)提供來源，是一個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已經(jīng)停止了，那么把它加到需要移除的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的功能是什么？根據(jù)當前活躍的track隊列，來為混音器設置信息?？上攵?，一個track必然在混音器中有一個對應的東西。我們待會分析AudioMixer的時候再詳述。 為混音器準備好后，下面調(diào)用它的process函數(shù) void AudioMixer::process(void* output) { mState.hook(&mState, output);//hook？難道是鉤子函數(shù)？ }暈乎，就這么簡單的函數(shù)？？？
CTRL+左鍵，hook是一個函數(shù)指針啊，在哪里賦值的？具體實現(xiàn)函數(shù)又是哪個？
沒辦法了，只能分析AudioMixer類了。
4. AudioMixer
AudioMixer實現(xiàn)在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，是該類的靜態(tài)函數(shù) 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中定義的一個數(shù)據(jù)結構
//注意，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對應的可選函數(shù)實現(xiàn)有：
process__validate
process__nop
process__genericNoResampling
process__genericResampling
process__OneTrack16BitsStereoNoResampling
process__TwoTracks16BitsStereoNoResampling
AudioMixer構造的時候，hook是process__nop，有幾個地方會改變這個函數(shù)指針的指向。
這部分涉及到數(shù)字音頻技術，我就無力講解了。我們看看最接近的函數(shù)
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 { //計算音量等數(shù)據(jù)，和數(shù)字音頻技術有關。這里不說了 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); } }好像挺簡單的啊，不就是把數(shù)據(jù)處理下嘛。這里注意下buffer。到現(xiàn)在，我們還沒看到取共享內(nèi)存里AT端write的數(shù)據(jù)吶。
那只能到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; //哈哈，看看數(shù)據(jù)準備好了沒， 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; } 獲得真實的數(shù)據(jù)地址 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中實現(xiàn)了 void AudioFlinger::ThreadBase::TrackBase::releaseBuffer(AudioBufferProvider::Buffer* buffer) { buffer->raw = 0; mFrameCount = buffer->frameCount; step(); buffer->frameCount = 0; }看看step吧。mFrameCount表示我已經(jīng)用完了這么多幀。
bool AudioFlinger::ThreadBase::TrackBase::step() { bool result; audio_track_cblk_t* cblk = this->cblk(); result = cblk->stepServer(mFrameCount);//哼哼，調(diào)用cblk的stepServer，更新 服務端的使用位置 return result; }到這里，大伙應該都明白了吧。原來AudioTrack中write的數(shù)據(jù)，最終是這么被使用的呀?。?！
恩，看一個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; } }看不懂了吧？？哈哈，知道有這回事就行了，專門搞數(shù)字音頻的需要好好研究下了！
三 再論共享audio_track_cblk_t
為什么要再論這個？因為我在網(wǎng)上找了下，有人說audio_track_cblk_t是一個環(huán)形buffer，環(huán)形buffer是什么意思？自己查查！
這個嗎，和我之前的工作經(jīng)歷有關系，某BOSS費盡心機想搞一個牛掰掰的環(huán)形buffer，搞得我累死了。現(xiàn)在audio_track_cblk_t是環(huán)形buffer？我倒是想看看它是怎么實現(xiàn)的。
順便我們要解釋下，audio_track_cblk_t的使用和我之前說的Lock,讀/寫，Unlock不太一樣。為何？
l 第一因為我們沒在AF代碼中看到有緩沖buffer方面的wait，MixThread只有當沒有數(shù)據(jù)的時候會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; //循環(huán)起始 uint32_t loopEnd; //循環(huán)結束 int loopCount; uint8_t out; //如果是Track的話，out就是1，表示輸出。 }注意這是volatile，跨進程的對象，看來這個volatile也是可以跨進程的嘛。
l 唉，又要發(fā)揮下了。volatile只是告訴編譯器，這個單元的地址不要cache到CPU的緩沖中。也就是每次取值的時候都要到實際內(nèi)存中去讀，而且可能讀內(nèi)存的時候先要鎖一下總線。防止其他CPU核執(zhí)行的時候同時去修改。由于是跨進程共享的內(nèi)存，這塊內(nèi)存在兩個進程都是能見到的，又鎖總線了，又是同一塊內(nèi)存，volatile當然保證了同步一致性。
l loopStart和loopEnd這兩個值是表示循環(huán)播放的起點和終點的，下面還有一個loopCount嗎，表示循環(huán)播放次數(shù)的
那就分析下吧。
先看寫者的那幾個函數(shù)
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; 我們不設循環(huán)播放時間嗎。所以loopStart是初始值INT_MAX，所以limit=0 return limit + frameCount - u; //返回0+frameCount-0，也就是全緩沖最大的空間。假設frameCount=1024幀 } }然后調(diào)用buffer獲得其實位置，buffer就是得到一個地址位置。
void* audio_track_cblk_t::buffer(uint32_t offset) const
{
return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;
}
完了，我們更新寫者，調(diào)用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也更新了。根據(jù)buffer函數(shù)的實現(xiàn)來看，似乎把這個
//環(huán)形緩沖鋪直了....連綿不絕。
}
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) { }沒有設置循環(huán)播放嘛，所以不走這個
if (s >= loopEnd) { s = loopStart; if (--loopCount == 0) { loopEnd = UINT_MAX; loopStart = UINT_MAX; } }//一樣啊，把環(huán)形緩沖鋪直了
if (s >= serverBase + this->frameCount) { serverBase += this->frameCount; } this->server = s; //server為512了 cv.signal(); //讀者讀完了。觸發(fā)下寫者吧。 lock.unlock(); return true;6 真的是環(huán)形緩沖嗎？
環(huán)形緩沖是這樣一個場景，現(xiàn)在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有什么用”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內(nèi)容的文章，歡迎關注億速云行業(yè)資訊頻道。
免責聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權內(nèi)容。
