背景
某客户反馈了一个问题，在播放音频的场景下，部分设备使用aaudio 正常，切换成opensl就会出现卡顿，乍一看不太符合常识，延时越低的通道应该越容易出问题，现在反过来了。那根本原因是什么？本篇就来揭开这个谜题。
原因分析
是什么导致了播放卡顿？
通过分析客户提供的case，发现音频播放卡顿时有个共同点是远端流数量较多，至少在3路及以上。这样就会出现在一次播放回调中串行处理多路流的情况，导致回调处理时长超过回调的数据时长阈值。 比如一次播放回调需要10ms的数据，结果在播放回调中收集数据就花了15ms，这样就比较容易出现underrun，合理的情况应该是在10ms内完成数据收集。
针对播放回调加上时间监控后，异常时候的log如下，可以看到的确有超过阈值的情况。
为什么AAudio不卡顿？
opensl的数据回调时长是大于等于aaudio的数据回调时长，一般opensl的回调数据时长固定成了20ms，aaudio是4ms或者2ms不等，如果opensl可以出现underrun，那么aaudio理论上也会出现underrun，于是同样的方法监控aaudio回调，果然aaudio也出现了underrun。
看起来aaudio 的underrun比opensl更为严重。
那为什么aaudio不卡顿呢？首先需要了解是否出现underrun一定代表卡顿。按照常规逻辑来理解，这两者应该是等同的，系统向应用要数据，应用没给，所以系统播放就出现不连续了。可真的是这样么？如果要回答这个问题，就需要了解下 Android audio的体系。app到音频驱动之间的数据是如何流转的呢？
如下是一种：
app ->os ->audio driver
app写一帧数据到os，os再把这帧数据写入驱动。如果是这种结构，只要app的播放线程出现一点抖动，就会出现问题。所以android很明显不是这样做的。
那怎样做能抵抗app的线程抖动呢？常规方法就是添加一个buffer，如下:
app --周期T1 --> os buffer
os buffer --周期T2 --> audio driver
这样的确是一种思路，而且也接近了目前部分app的实现方式，不过在os层的具体实现还有些点需要考虑，如何协调T1和T2？如果是一样的值，那也会出现问题，甚至和上面的方式没啥区别了。这时候就需要借助IRQ了，app可以周期性写入，但是需要让T2间接影响到app的写入，比如buffer数据不多了，就希望app可以快点多写点，buffer数据快写满了，就希望app可以写慢点。
那具体怎么做呢？在系统里面可以搞一个阻塞机制，在app写数据时判断下buffer的数据量，如果少了，就立马返回，如果快满了，就阻塞下。本质上就是一把锁就好了。也可以用非阻塞机制，控制buffer的数据量，如果少了，就全部写入，如果快满了，就不写入，告诉app写入的数据量是0。实际上 Android的audiotrack/opensl 就是类似于这种模式实现的。当然audiotrack也提供了被动回调的方式，让os 主动回调app要播放数据。
那还有一个问题，这儿的buffer该多大呢？这就和每次写入的数据量有关了，如果每次写入20ms的数据，buffer 就设置为20ms，这样肯定也是不合适的，稍微的咬合偏差都会导致underrun。如果设置为40ms，那就是一个典型的双缓存机制。buffer越大，越能抵抗咬合抖动，不过延时也越高，而buffer越小，抵抗咬合抖动的能力也越弱，不过延时也会低一些。知道这点对于分析这个问题非常关键！
继续梳理思路，是否还有其他的实现方式？可以延时尽可能低，能想到的就是干脆不要搞buffer了，也不要IRQ了，只要让应用周期去写播放数据就好了，最好播放数据可以直达audio driver，这样连拷贝都没了，肯定延时最低！
app --周期-- >audio driver
其实aaudio就是类似于这样的一个链路，去掉拷贝，去掉IRQ，路径极简，把buffer 挪到audio driver中，app和audio driver直接共享buffer，app周期讲数据写到audio driver的共享buffer中，audio driver直接从共享buffer中读取数据。至于如何控制周期，只要让audio driver告诉os当前的buffer状态就好了。
这样的确就快了，这就是aaudio的实现思路，控制周期的就是aaudioserver。这儿的buffer大小也很重要，如果设置不当也会有underrun问题。同样也不能太大，也不能太小，原因和上面提到的一样。
那underrun是怎么来的呢？并不一定是buffer没数据了，向app要数据，app没在规定时间内提供就是underrun，也可能是周期向app要数据，app没在规定时间内提供，这时候即使underrun了，buffer内还有数据，也能抗上几次underrun。这样的话，即使出现underrun，只要不长期处于这个状态，就不会导致播放卡顿。
那这样看起来opensl和aaudio一样了啊，都出现underrun了，应该都有问题。真的是这样吗？不，aaudio和opensl还有一个重要差异，aaudio 在时机运行时会监控underrun，并且按照underrun的情况调节buffer。aaudio 根据underrun调节buffer
int32_t previousUnderrunCount = 0;
int32_t framesPerBurst = AAudioStream_getFramesPerBurst(stream);
int32_t bufferSize = AAudioStream_getBufferSizeInFrames(stream);
int32_t bufferCapacity = AAudioStream_getBufferCapacityInFrames(stream);
while (go) {
result = writeSomeData();
if (result < 0) break;
// Are we getting underruns?
if (bufferSize < bufferCapacity) {
int32_t underrunCount = AAudioStream_getXRunCount(stream);
if (underrunCount > previousUnderrunCount) {
previousUnderrunCount = underrunCount;
// Try increasing the buffer size by one burst
bufferSize += framesPerBurst;
bufferSize = AAudioStream_setBufferSize(stream, bufferSize);
}
}
}
实际在case中也的确发现了有调节buffer的操作:
而opensl就不行了，因为opensl的实现机制本质上还是audiotrack那一套，buffer在创建的时候就已经确定了，无法再调整了，如果调整就会影响到线程咬合的控制，而aaudio却可以实时调整。
到了这儿原因其实原因就差不多了，aaudio没问题是因为aaudio调整buffer了，buffer大了后对underrun的抗性也就强了，opensl有问题，是因为opensl在出现underrun后也没调节buffer的机会，这样对underrun的抗性就很弱。
如何验证这个猜想呢？
默认创建的opensl走的是低延时模式，也就是出现卡顿的时候，这时候buffer会比较小，可以看到是384个采样点。
尝试不让opensl 走低延时模式，比如采样率用44.1k或者强制用powersaving模式，测试发现不再卡顿了，此时的buffer如下, 达到1920个采样点了。
通过该方法证明了猜想有效！
通过这个case，可以看到，并不一定opensl的兼容性就比aaudio好，还是需要坚持具体问题具体分析。
