关于安卓AudioTrack::getMinFrameCount的分析

http://blog.youkuaiyun.com/u013150907/article/details/44674805

转载自http://www.cnblogs.com/andriod-html5/archive/2012/06/06/2539531.html，感谢大神分享

1. // Ensure that buffer depth covers at least audio hardware latency  
2. uint32_t minBufCount = afLatency / ((1000 * afFrameCount) / afSampleRate);  

minBufCount = 200 / （（1000×1536）/44100） = 5.


消化消化。
afFrameCount的意思是硬件buffer里能放多少frame，afFrameCount/afSampleRate的意思是，播放一次硬件buffer中的数据需要多少时间，算出来的单位是秒。
再乘以个1000，即将秒转为了毫秒。
这样就与afLatency的单位一致了。
这样算出来的结果，就是说，为了满足硬件延迟，软件侧的buffer大小只是要是硬件侧buffer大小的多少倍。


感觉还是没消化彻底。
什么是硬件延迟？为什么软件侧的buffer size需要这个倍数呢？
硬件延迟，就是说，硬件侧可能会延迟这么久，也就是说硬件可能有这么长的时间都没有从软件侧取数据。
而软件侧还在不停地写数据，为了保证软件侧的数据不被丢失，就需要软件侧的buffer足够大。
多大才是足够大呢？
就是在硬件允许的最大时间，不取数据的情况下，软件侧的buffer也不至于爆仓。
这样基本上消化彻底了。


frameCount的计算与传入参数sampleRate有关：

1. *frameCount = (sampleRate == 0) ? afFrameCount * minBufCount :  
2.           afFrameCount * minBufCount * sampleRate / afSampleRate;  

如果sampleRate为0，frameCount为 7680.
如果sampleRate不为0，frameCount为7680×sampleRate/44100.


消化一下。
既然上面已经算出来了软件buffer 大小只是要是硬件的多少倍，而硬件buffer中包含的frame个数已经知道为afFrameCount，
算出软件buffer中包含多少frame也没什么困难了。
如果软件侧过来的数据与硬件侧的sampling rate未指定，或者与硬件侧的一样，软件侧的buffer能装的frame个数即为afFrameCount * minBufCount。

如果软件侧的sampling rate与硬件侧不一致，就拿上面的结果再乘以个sampleRate / afSampleRate即可。

         基于以上大神分析，加上我的理解总结如下：

uint32_t minBufCount = afLatency / ((1000 * afFrameCount) / afSampleRate);

afFrameCount为硬件buffer一次能够播放多少个frame，单位为frame。

afSampleRate为每秒采样多少个frame。

afFrameCount/afSampleRate表示硬件buffer能够一次播放多少秒的数据。乘以1000表示播放多少ms的数据。

afLatency 硬件延迟表示硬件从第一次取数据到第二次去数据总共花了多少ms。

所以minBufCount表示上层需要最少准备多少个硬件buffer大小的软件buffer，才能保证传输数据不会出现中断。单位为个。

afFrameCount * minBufCount * sampleRate / afSampleRate; 

afFrameCount * minBufCount表示我这个软件buffer里面有多少个frame。

sampleRate / afSampleRate可看成比值，即所需传输的采样率和硬件支持的采样率比值，表示我这个软件buffer如果用在传输实际sampleRate的数据的话，可以大一些，也可以小一些。那么就看这个比值了。以上公式就表示我软件buffer需要多少个frame才能保证不会断音。

frameCount * nbChannels * (audioFormat == ENCODING_PCM_16BIT ? 2 : 1);

再加上这个就表示我软件buffer需要多少个字节的空间了。