前兩篇主要給大家介紹了AudioFlinger流控中播放線程的睡眠策略，從本篇開始介紹AudioFlinger中的buffer管理。

先談幾個變量：

mFrameSize：一個音頻幀的大小，一般如果是16bit，雙聲道的話那就是4個字節

mBufferSize：hal層告訴Audioflinger的底層（ALSA）buffer的大小

mFormat：當前如果播放數據的格式類型，比如：

mNormalFrameCount：Audioflinger中的各個buffer的大小

mFrameCount：hal層一下的buffer大小，和mNormalFrameCount是倍數關系，倍數關系如下：

// Calculate size of normal sink buffer relative to the HAL output buffer size

下面介紹一下上述代碼的含義，第一行英文注釋寫的比較清楚，就是計算normalsink，也就是audioflinger的server層的buffer大小和hal層的輸出buffer大小的關系，這個關系直接影響了fastmix的創建進而影響線程的睡眠時間，kMinNormalSinkBufferSizeMs = 20，kMaxNormalSinkBufferSizeMs = 24代表一組經驗值，代表最小和最大的sinkbuffer數據的duration，minNormalFrameCount和maxNormalFrameCount是換算到frame後的變量，一個會round up到16的整數倍，一個會round down到16的整數倍，如果hal層的buffer設置的相對比較大，則multiplier會小于1，最終的系數會設置成1，也就是audioflinger的server和hal層的buffer大小保持一緻，如果hal層的buffer大小設置的比較小則multiplier會大于1,如果沒有超過2則系數最終是2,如果更小則系數就是maxNormalFrameCount / (double) mFrameCount，當然hal層的buffer size直接決定了audioflinger的延遲情況，關于延遲後續開辟專題來講。

mSinkBuffer：緊鄰hal層的寫buffer

mMixerBuffer：混音後的buffer，所有的track共用

mEffectBuffer：緊跟混音buffer，如果有音效的話

由以上各個buffer的大小計算可以看出，雖然大小不一樣，但是frame都是一樣的，這三個buffer在工作的時候要麼保持滿的狀态，要麼保持為空，采用節拍的方式推進。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!