Audio 环形buffer

没有同步和锁所构建的缓冲系统，Android的经典之作！

http://blog.csdn.net/innost/article/details/47208109

audio_track_cblk_t的分析

前面讲解了AudioFlinger的工作方式，但AT和AF以及那个神秘的CB对象的工作原理，一直都还没能讲解。还是从AT和AF两端关于CB对象的调用流程开始分析，这一招可是屡试不爽啊！
1. AT端的流程
AT端作为数据的生产者，可称它为写者，它在CB对象中用user表示。它的调用流程是：
· 调用framesAvailable，看看是否有空余的可写空间。
· 调用buffer，获得写空间起始地址。
· 调用stepUser，更新user的位置。
一起来分析一下，由于这几个函数都相当简单，力争一气呵成。
先调用framesAvailable，看看当前剩余多少可写空间。假设是第一次进来，读者还在那等待数据，这样就不用考虑竞争等问题了，代码如下所示：
[–>AudioTrack.cpp::audio_track_cblk_t的framesAvailable()及相关]
uint32_t audio_track_cblk_t::framesAvailable()
{
Mutex::Autolock _l(lock);
returnframesAvailable_l();//调用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返回一个地址。
[–>AudioTrack.cpp]
void* audio_track_cblk_t::buffer(uint32_toffset) const
{
//buffers是数据缓冲的起始位置，offset是计算出来的基于userBase的偏移。
//通过这种方式巧妙地把数据缓冲当做环形缓冲来处理
return(int8_t )this->buffers + (offset - userBase) this->frameSize;
}
当把数据写到缓冲后，调用stepUser。
[–>AudioTrack.cpp]
uint32_t audio_track_cblk_t::stepUser(uint32_tframeCount)
{
/*
framecount，表示写了多少帧，前面分配了1024帧，但写的数据可以比这个少
假设这一次写了512帧
*/
uint32_t u = this->user;//user位置还没更新，此时u=0；

u +=frameCount;//u更新了，u=512......

/*
userBase还是初始值0。可惜只写了1024的一半,所以userBase加不了。
但这句话很重要，还记得前面的buffer调用吗？取数据地址的时候用offset-userBase，
一旦user位置到达缓冲的尾部，则userBase也会更新，这样offset-userBase的位置就会
回到缓冲的头部，从头到尾这么反复循环，不就是一个环形缓冲了吗？非常巧妙！
*/
if (u>= userBase + this->frameCount) {
userBase += this->frameCount;
}
this->user = u;//喔，user位置也更新为512了，但是useBase还是0
returnu;
}
假设写者这时因某种原因停止了写数据，而读者却会被唤醒。
2 AF端的流程
AF端作为数据的消费者，它在CB中的表示是server，可称它为读者。读者的使用流程是：
· 调用framesReady看是否有可读数据。
· 获得可读数据的起始位置，这个和上面的buffer调用基本一样，都是根据offset和serverBase来获得可读数据块的首地址。
· 调用stepServer更新读位置。
现在来分析framesReady和stepServer这两个函数，framesReady的代码如下所示：
[–>AudioTrack.cpp]
uint32_t audio_track_cblk_t::framesReady()
{
uint32_t u = this->user; //u为512
uint32_ts = 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;}

}
可读数据地址的计算方法和前面的buffer调用一样，都是通过server和serverBase来计算的。接着看stepServer，代码如下所示：
[–>AudioTrack.cpp]
bool audio_track_cblk_t::stepServer(uint32_tframeCount)
{
status_t err;
err = lock.tryLock();
uint32_t s = this->server;

s +=frameCount; //读了512帧了，所以s=512 ......

//没有设置循环播放，所以不走这个
if (s>= loopEnd) {
s =loopStart;
if (–loopCount == 0) {
loopEnd = UINT_MAX;
loopStart = UINT_MAX;
}
}
//和userBase一样的处理
if (s>= serverBase + this->frameCount) {
serverBase += this->frameCount;
}
this->server = s; //server为512了
cv.signal(); //读者读完了，触发一个同步信号，因为读者可能在等待可写的数据缓冲
lock.unlock();
returntrue;
}
3. 真的是环形缓冲？
满足下面场景的缓冲可称为环形缓冲（假设数据缓冲最大为1024帧）：
· 写者先写1024帧，此后便无剩余空间可写。
· 读者读了前面的512帧，那么这512帧的数据空间就空余出来了。
· 所以，写者就可以重新利用这空余512帧的空间了。
关键是第三步，写者是否跟踪了读者的位置，并充分利用了读者已使用过的数据空间。所以得回头看看写者AT是否把这512帧利用了。
先看写者写完1024帧后的情况，stepUser中会有下面几句话：
if (u >= userBase + this->frameCount) {
//u为1024，userBase为0，frameCount为1024
userBase += this->frameCount;//好，userBase也为1024了
}
此时userBase更新为1024帧。再看写者获取可写空间的framesAvailable_l函数，按照以前的假设，应该返回512帧可写空间，代码如下所示：
[–>AudioTrack.cpp]
uint32_t audio_track_cblk_t::framesAvailable_l()
{
uint32_t u = this->user; //1024，写者上一次写完了整个1024帧空间
uint32_t s = this->server;//512，读者当前读到的位置

if(out) {   uint32_t limit = (s < loopStart) ? s : loopStart;   return limit + frameCount - u;//返回512}

}
framesAvailable返回了512帧，但可写空间的地址是否是从头开始的呢？要是从其他地方开始的，情况就惨了。来看buffer中最后返回的可写空间地址：
return (int8_t )this->buffers + (offset -userBase) this->frameSize;
//offset是外界传入的基于userBase的一个偏移量，它的值是userBase+512，所以
//offset-userBase将得到从头开始的那段数据空间。真的是一个环形缓冲。
从上面的分析中看出，CB对象通过userBase和user等几个变量，将一段有限长度的线性缓冲变成了一段无限长的缓冲，这不正是环形缓冲的精髓吗！