buffer的机制（AndroidAudioFlinger的流控三漫谈buffer）

前两篇主要给大家介绍了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在工作的时候要么保持满的状态，要么保持为空，采用节拍的方式推进。