【发布时间】：2011-03-23 02:35:58
【问题描述】：
为什么 onPeriodicNotification() 行为如此不规律？
背景
我正在开发一个适用于 Android 的音频可视化器，它使用 AudioRecord.read()（16 位单声道）从麦克风中采样。我已经对 setPositionNotificationPeriod() 的采样率和帧周期进行了大量测试。最后，我决定：
采样率： 8000
帧周期： 采样率 * 41 / 1000 = 328
缓冲区大小： 5 * 采样率
我选择的帧周期是 41 毫秒，因为我希望我的可视化器每秒大约 24 帧。
一开始我认为以这种速度在画布上绘图会是个问题，但在 DroidX 和 Nexus One 上进行测试后，我获得了惊人的性能。我可以将这些设备上的延迟降低到 20 毫秒，而不会出现缓冲区溢出，但没有必要。
一旦我开始在 Galaxy S 和 Nexus S 上进行测试，我的表现就下降了。这似乎很奇怪，因为 Nexus S 在很大程度上优于这两种设备。在消除了绘图和计算的问题后，我将计时调用放在 onPeriodicNotification() 中。我能够确认这个问题是由于这个回调在任意时间间隔被调用，我不明白为什么。
创建一个公平的基准
作为一个公平的测试，我将所有的音频处理和绘制都从循环中取出，这样我的应用程序所做的就是在循环中读取音频并将数据记录在 onPeriodicNotification() 中。我将帧周期设置为 100 毫秒，并使用以下时序代码：
currentTime = SystemClock.elapsedRealtime();
Log.v(TAG, "time since last record update: " + (currentTime - lastTime));
lastTime = currentTime;
最后，我在每台设备上采样了 5 分钟的数据。在 DroidX 上，我达到了我的预期：
# 点数： 3008
Min： 92
Max： 105
平均： 100
标准差： 6.64
这似乎是合理的，我愿意接受。在 Galaxy S 上，我得到：
# 点数： 3004
Min： 0！
Max： 274
平均： 100.05
标准差： 126.30?!?
StdDev 为 126，这意味着随后的一组计时调用通常看起来像这样 [253, 0, 1, 258, 1, 0, 263]。
结论和其他杂项数据
在执行这些测试时，我密切关注 CPU 使用率。我的进程在 2-3% 的 CPU 使用率左右徘徊，需要处理大量开销。我注意到，如果我将通知之间的延迟增加到 250 毫秒左右，Galaxy S 就会开始像我预期的那样运行（stddev 下降到 6-7 左右）。不幸的是，250 毫秒远不是音频可视化的可用延迟。
在输入完所有这些后，我不禁觉得这更好地属于一些错误报告，但是这又是我们正在谈论的三星，我们知道他们有 no internet android bug reporting presence :(
我们非常感谢您提供替代方案、见解和经验。
【问题讨论】：
标签： android audio audio-recording