我的书签
添加书签
移除书签7.3.3 audio_track_cblk_t分析
前面讲解了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）；
return framesAvailable_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_t offset）const
{
//buffers是数据缓冲的起始位置，offset是计算出来的基于userBase的偏移。
//通过这种方式巧妙地把数据缓冲当做环形缓冲来处理。
return（int8_t）this-＞buffers+（offset-userBase）this-＞frameSize；
}
当把数据写到缓冲后，调用stepUser，代码如下所示：
[—＞AudioTrack.cpp]
uint32_t audio_track_cblk_t：stepUser（uint32_t frameCount）
{
/*
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。
return u；
}
假设写者这时因某种原因停止了写数据，而读者却被唤醒。
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_t s=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_t frameCount）
{
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（）；
return true；
}
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等几个变量，将一段有限长度的线性缓冲变成了一段无限长的缓冲，这不正是环形缓冲的精髓吗！
