Question

为什么onPeriodicNotification（）表现得如此不规律？

背景
我正在开发一款Android音频可视化器，它使用AudioRecord.read（）（16位单声道）从麦克风采样。我已经对setPositionNotificationPeriod（）的采样率和帧周期进行了相当多的测试。最后，我决定：
采样率： 8000
帧周期：采样率* 41/1000 = 328
缓冲区大小： 5 *采样率

我选择的帧周期是41 ms，因为我希望我的可视化工具每秒约24帧。

我认为以这个速度绘制画布起初会是一个问题，但是在对DroidX和Nexus One进行测试后，我的表现非常出色。我可以在没有缓冲区溢出的情况下将延迟降低到20 ms，但不需要。

一旦我开始测试Galaxy S和Nexus S，我的性能就会下降。这看起来很奇怪，因为Nexus S在很大程度上优于两种设备。在消除绘图和计算问题之后，我将定时调用放在onPeriodicNotification（）中。我能够确认问题是由于这个回调是在多个时间间隔被调用的，我不明白为什么。

创建公平基准
作为一个公平的测试，我完成了所有的音频处理和绘制循环，这样我的应用程序所做的就是循环读取音频并在onPeriodicNotification（）中记录数据。我将帧周期设置为100 ms并使用以下时序代码：

currentTime = SystemClock.elapsedRealtime();
Log.v(TAG, "time since last record update: " + (currentTime - lastTime));
lastTime = currentTime;

最后，我在每台设备上对数据进行了5分钟的采样。在DroidX上，我得到了我的期望：
＃Points： 3008
敏 92 最大： 105
平均： 100
StdDev： 6.64

这似乎是合理的，我愿意忍受这个。在Galaxy S上，我得到了这个：
＃Points： 3004
Min： 0！
最大： 274
平均：100.05
StdDev： 126.30？！？

StdDev为126，这意味着后续的一组定时调用通常看起来像[253,0,1,258,1,0,263]。

结论＆amp;其他misc数据
在执行这些测试时，我一直关注CPU使用情况。我的进程占用了大约2-3％的CPU使用率，并且需要大量的开销。我注意到，如果我将通知之间的延迟增加到大约250毫秒，Galaxy S开始表现如我所料（stddev下降到6-7左右）。不幸的是，250毫秒远远不是音频可视化的可用延迟。

输入所有这些之后我忍不住感觉这更好地属于一些错误报告，但是这又是我们所谈论的三星，我们知道他们有no internet android bug reporting presence :(

非常感谢替代方案，见解和经验。

Answer 1

最终这个似乎归结为音频驱动程序。我发现三星的音频实现导致了令人难以置信的高延迟，而摩托罗拉，HTC等足够低，我没有注意到。

低延迟音频已经在bug list很长一段时间了，所以也许这并不奇怪。如果您正在进行实时音频可视化，请准备对三星设备感到失望:(

onPeriodicNotification（）在* some * devices上有抖动

1 个答案: