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 单音频线程

你可能感兴趣的:(Android 节拍器)