6

OpenSL ES を使用して Android 6.0.1 を実行している Nexus 6 で低遅延のストリーミング オーディオ再生を実装しようとすると、奇妙な問題が発生します。

私の最初の試みは飢餓の問題に苦しんでいるようだったので、バッファ完了コールバック関数にいくつかの基本的なタイミング ベンチマークを追加しました。私が見つけたのは、アプリが開いているときに画面をタップし続けるとオーディオが正常に再生されることですが、数秒間そのままにしておくと、コールバックに時間がかかり始めます。この動作を一貫して再現できます。注意すべき点がいくつかあります。

  • 「数秒」 ~= 3 ～ 5 秒、画面の変更をトリガーするのに十分な長さではありません
  • 私のアプリケーションのアクティビティは FLAG_KEEP_SCREEN_ON を設定するので、とにかく画面の変更は発生しません
  • 私は、オーディオ コールバック スレッドの優先度を上げるための措置を講じていません。Android がこれらのスレッドに対してすでに高い優先度を予約しているという印象を受けていたからです。
  • この動作は Nexus 6 (Android 6.0.1) で発生しますが、Galaxy S6 (Android 5.1.1) でも発生しません。

私が見ている症状は、電話との対話がない状態が数秒間続くと、OS がオーディオ スレッドの優先順位を下げるように見えます。これは正しいですか？この動作を回避する方法はありますか?

4

3 に答える 3

2

Android 6 のオーディオ パイプラインが完全に書き直されたことはよく知られています。これにより、ほとんどの場合、レイテンシー関連の問題が改善されましたが、通常、このような大規模な変更でよくあるように、多くの望ましくない副作用が発生する可能性はあります。

あなたの問題は一般的なものではないようですが、いくつかのことを試すことができます:

  • オーディオ スレッドの優先順位を上げます。Android のオーディオ スレッドのデフォルトの優先度は-16で、最大は で-20、通常はシステム サービスでのみ使用できます。この値をオーディオ スレッドに割り当てることはできませんが、スレッドの優先度を設定するときにフラグ-19を使用することで、次善の策を割り当てることができます。ANDROID_PRIORITY_URGENT_AUDIO

  • バッファーの数を増やして、あらゆる種類のジッターやレイテンシーを防ぎます (最大 16 にすることもできます)。ただし、一部のデバイスでは、新しいバッファを埋めるためのコールバックが必要なときに常に呼び出されるとは限りません。

  • この SO 投稿には、Anrdoid でのオーディオ レイテンシを改善するための提案がいくつかあります。特に興味深いのは、受け入れられた回答のポイント 3、4、および 5 です。

  • またはを照会して、現在の Android システムが低レイテンシーに対応hasSystemFeature(FEATURE_AUDIO_LOW_LATENCY)しているかどうかを確認しhasSystemFeature(FEATURE_AUDIO_PRO)ます。

さらに、この学術論文では、バッファおよびコールバック間隔に関連するアプローチを含む、Android/OpenSL のオーディオ レイテンシ関連の問題を改善するための戦略について説明しています。

于 2016-03-07T12:14:49.370 に答える