前面讲解了AudioFlinger的工作方式，但AT和AF以及那个神秘的CB对象的工作原理，一直都还没能讲解。对于Audio系统来说，如果最终也解决不了这个，真会有当年岳飞在朱仙镇被十二道金牌召回时一样的悲愤心情。幸好我们没遇到秦桧，那就奋力穷追猛打，去解决这个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等几个变量，将一段有限长度的线性缓冲变成了一段无限长的缓冲，这不正是环形缓冲的精髓吗！