Android 节拍器
好多年没写了，写完公司内部wiki，效果挺明显的，转过来记录下。
1，延迟：
同样的，音乐人按照节奏数拍，假如拍子有30ms的延迟，也是能够感受到迟滞。如果是大于50ms，则是明显感觉到卡顿。特别是在BPM数值大，拍号时值短的情况下，拍子之间的间隔很短（4/4，BPM=240, 间隔=250ms）。
2，现状：
当前版本的节拍器的实现方案是：Thread.sleep + SoundPool。
这里有两个问题：
1，Thread.sleep 不能保证睡眠时间的精确性，因为他们受到系统计时器和调度程序精度和准确性的影响。往往有10ms以上的差异。
所以，针对于精确性要求高的节拍器并不适合。
2，SoundPool 底层由AudioTrack实现，相对于MediaPlayer，对短小音效的支持很好。相对于AudioTrack会有更低的延迟。因为底层实现上，SoundPool的AudioTrack实例的 audio_output_flags_t 参数中设置位 AUDIO_OUTPUT_FLAG_FAST。使其成为快速音轨（FastTrack）。而且对同一个音效会复用底层的AudioTrack实例，从而避免多次创建浪费资源。即使如此，SoundPool 在高BPM的情况下，播放密度大时，偶尔会出现一点卡顿。甚至低BPM也会出现，没有深入调研SoundPool源码，排除定时器不够精确的情况，猜测是由于AudioTrack自身延迟（传递数据到硬件抽象层 (HAL)路径长）或者jvm触发内存回收时导致的。所以表现并不是很稳定。
下图是Thread.sleep + SoundPool 实现的节拍器（最简单的 4/4拍，BPM 分别是 60，120，240，480）播放时录音的效果。
可以看到，第一轨，BPM = 60 时，本应该在2秒处的第三拍，却在2.15秒后才播出。足足延迟了 150毫秒。
Thread.sleep + SoundPool
同样的，下图第三轨，BPM = 240 时，本应该在0.75秒处的第四拍，却在0.85秒后才播出。延迟了 100毫秒。
Thread.sleep + SoundPool
3，重构
1，针对定时器不准，直接使用c++ 系统级别的 std::this_thread::sleep_for，精确到 1ms。
c++ 倒计时
2，采用 Google Oboe 低延迟音频框架。
大概的思路如下：
创建音频输出流 → 加载节拍音效 → 设置最低的缓冲区帧数→ 通过定时不断的切换强弱拍子将数据推送到输出流中 → 输出声音。
下图是（最简单的 4/4拍，BPM 分别是 60，120，240，480）播放时录音的效果。
虽然有时会延迟，但基本都在可接受范围(30ms)内的误差，而且很稳定。无论是低BPM，还是高BPM。
倒计时线程 + Oboe 音频线程
4，优化
上个方案是采用 c++线程 和 Oboe 来实现的。
虽然比原有方案有了质的飞跃，但是这里存在有一个致命的问题。那就是更高BPM下（ bpm >= 480）或者节奏更快的拍式（1拍4个16音符）时，依然存在误差。
如上图，录音文件清楚的反应了这个问题。在bpm = 480时，已经变得不稳定，甚至不可用了。
这里主要是由于多线程的关系，播放状态同步不及时导致。 新启c++线程去控制状态的变化（此时该播什么拍子）跟 Oboe的音频播放线程。
所以，再优化了一波，只保留Oboe音频播放线程，并且在这个线程里控制播放状态的改变。
最终效果，如下图。
Oboe 单音频线程
最后，来个终极对比。
下图是 （最复杂的 4/4拍，节奏是4个16音符， BPM 分别是 60，120，240）播放时录音的效果。
原有方案：Thread.sleep + SoundPool
Thread.sleep + SoundPool
最新方案：Google Oboe
Oboe 单音频线程
