Android深入淺出之Audio 第二部分 AudioFlinger分析

一 目的

本文承接Audio第一部分的AudioTrack，通過AudioTrack作為AF（AudioFlinger）的客戶端，來看看AF是如何完成工作的。

在AT（AudioTrack）中，我們涉及到的都是流程方面的事務，而不是系統Audio策略上的內容。WHY？因為AT是AF的客戶端，而AF是Android系統中Audio管理的中樞。AT我們分析的是按流程方法，那麼以AT為切入點的話，AF的分析也應該是流程分析了。

對於分析AT來說，只要能把它的調用順序（也就是流程說清楚就可以了），但是對於AF的話，簡單的分析調用流程 我自己感覺是不夠的。因為我發現手機上的聲音交互和管理是一件比較復雜的事情。舉個簡單例子，當聽music的時候來電話了，聲音處理會怎樣？

雖然在Android中，還有一個叫AudioPolicyService的（APS）東西，但是它最終都會調用到AF中去，因為AF實際創建並管理了硬件設備。所以，針對Android聲音策略上的分析，我會單獨在以後來分析。

二 從AT切入到AF

直接從頭看代碼是沒法掌握AF的主干的，必須要有一個切入點，也就是用一個正常的調用流程來分析AF的處理流程。先看看AF的產生吧，這個C/S架構的服務者是如何產生的呢？

2.1 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也准備好硬件了。不過，創建硬件對象就代表我們可以播放了嗎？

2.2 AT調用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的流程了。下面一個一個看。

2.3 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的返回值。

2.4 到底有少種對象

讀到這裡的人，一定會被異常多的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的話，一定會很不爽。有什麼意義嗎？有什麼好處嗎？

2.5 AF流程繼續

好了，這裡終於在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了

}

看看buffer

return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;

//offset是外界傳入的基於user的一個偏移量。offset-userBase，得到的正式從頭開始的那段數據空間。太牛了！