私は、openSL ES オーディオ ドライバーが非常に不規則なコールバック パターンを示すいくつかの Android プラットフォーム (>= 4.1.1) で作業しています。
私の予想では、10ms ごとにコールバックを返すようにオーディオ ドライバーを設定すると、約 10ms ごとにコールバックが返される (数ミリ秒かかる) と予想されていました。理想的には、コールバック パターンは次のようになります。
t = 0ms : スピーカー コールバック
t = 1ms : マイクのコールバック
t = 10ms : スピーカー コールバック
t = 11ms : マイクのコールバック
t = 20ms : スピーカー コールバック
t = 21ms : マイクのコールバック
t = 30ms : スピーカー コールバック
t = 31ms : マイクのコールバック
マイク コールバックは、受信したマイク データを受け取り、それをリング バッファーに書き込みます。次に、「シグナル」を別のスレッドに送信して、ウェイクアップし、マイク データを処理します。マイク データの処理により、10ms のスピーカー データが生成されます。そのスピーカー データは、スピーカー コールバックが読み取るスピーカー リング バッファーに書き込まれます。
コールバック パターンが、スピーカーとマイクのコールバックが交互に行われる上記のようなものであれば、すべてうまくいきます。
ただし、コールバック パターンが不規則な場合は、問題が発生し始めます。例 : マイク コールバックのバーストは、スピーカー リング バッファーのサイズを屋根を通して駆動します。なんらかの理由で、スピーカー コールバックの同じ種類のバーストが得られない場合、スピーカー パスで突然大きな遅延が発生します。
もう 1 つの問題は、スピーカーのコールバックが急増した場合です。その場合、スピーカーのリング バッファーのサンプルが不足するため、代わりに無音パケットを返す必要があります。
この種の問題に対する標準的な解決策があるかどうか疑問に思っていますか? 思いつきません。
次のリンクは、コールバック パターンの例です。
http://wikisend.com/download/143908/timestamps.txt
ここで、「1」はマイクのコールバック、「2」はスピーカーのコールバックです。