我在某些 Android 平台 (>= 4.1.1) 上工作，其中 openSL ES 音频驱动程序表现出非常不规则的回调模式。
我的期望是，如果我将音频驱动程序配置为每 10 毫秒给我一次回调，我将大约每 10 毫秒(给定或花费几毫秒)获得一次回调。理想情况下，回调模式看起来像这样:
t = 0ms : 扬声器回调
t = 1ms : 麦克风回调
t = 10ms : 扬声器回调
t = 11ms : 麦克风回调
t = 20ms : 扬声器回调
t = 21ms : 麦克风回调
t = 30ms : 扬声器回调
t = 31ms : 麦克风回调
麦克风回调获取接收到的麦克风数据并将其写入环形缓冲区。然后它向另一个线程发送“信号”以唤醒并处理麦克风数据。麦克风数据的处理会生成 10 毫秒的扬声器数据。该扬声器数据被写入扬声器环形缓冲区，扬声器回调从中读取。
如果回调模式看起来像我上面描述的扬声器和麦克风轮流回调，则一切正常。
但是，如果回调模式不规则，事情就会变得一团糟。例如:一阵麦克风回调将驱动扬声器环形缓冲区的大小达到顶峰。如果我 - 无论出于何种原因 - 没有得到同样的扬声器回叫突发，我突然在扬声器路径中有很大的延迟。
另一个问题是如果我收到一连串的扬声器回呼。在那种情况下，扬声器环形缓冲区将耗尽样本，我将不得不返回静音数据包。
所以我想知道是否有针对此类问题的某种标准解决方案？我想不出任何。
以下链接是回调模式的示例:
http://wikisend.com/download/143908/timestamps.txt
其中“1”是麦克风回叫，“2”是扬声器回叫。
最佳答案
您可以查看 audio-echo示例，在 README.md 中，回调的不规则性也是其中提到的一个因素。将您的音频放入平台快速音频路径将改善回调不规则性，它取决于平台，可能值得一试。
关于android - opensl es : audio callback patterns，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22088854/