Androidでの低遅延オーディオ再生
私は現在、単純なアプリケーションのオーディオ遅延を最小限にしようとしています：
PCにビデオがあり、ビデオのオーディオをRTPを介してモバイルクライアントに送信しています。非常に類似したバッファリングアルゴリズムを使用すると、iOSで90ミリ秒のレイテンシを達成できますが、 Androidで恐ろしい±180ms。
違いは、Androidの よく知られている 遅延 問題 に起因すると推測しています。
しかし、少し読んでから この記事に出くわした には次のように書かれています。
特定のデバイスではAndroid 4.1/4.2であるため、低遅延オーディオが利用可能です。
低遅延オーディオは、 libpd、AndroidのPure Dataライブラリ を使用して実現できます。
これら2つのステートメントに直接関連する2つの質問があります。
Jellybeanの新しい低遅延オーディオに関する詳細情報はどこで入手できますか？ これは私が見つけることができるすべてですが、それは特定の情報に非常に欠けています 。変更は私に透過的ですか、またはアプリケーションの変更に気付くために実装する必要がある新しいクラス/ APIコールがありますか？私はAudioTrack APIを使用していますが、この改善の恩恵を受けるかどうか、またはオーディオ再生のための他のメカニズムを検討すべきかどうかもわかりません。
Libpdの使用を検討すべきですか？低レイテンシーを達成する唯一のチャンスのように思えますが、私は常にPDをオーディオ合成ユーティリティとして考えていたので、単につかむプロジェクトに本当に適していますか？ネットワークストリームからフレームを再生して再生しますか？合成を実際に行っていません。
補足説明として、誰かがOpenSL ESについて言及する前に、 この記事では、レイテンシーの改善がそれを使用することによって期待されるべきではないことを明確にしています ：
」OpenSL ESはネイティブC APIであるため、OpenSL ESを呼び出す非Dalvikアプリケーションスレッドには、ガベージコレクションの一時停止などのDalvik関連のオーバーヘッドはありません。ただし、これ以外のOpenSL ESの使用。特に、OpenSL ESの使用は、プラットフォームが一般的に提供するものよりも低いオーディオ遅延、高いスケジューリング優先度などをもたらしません。 "
Androidバージョン4.2.2以降で最小のレイテンシーを実現するには、次の手順を実行する必要があります。
可能であればFEATURE_AUDIO_PROをサポートするデバイスを選択し、そうでない場合はFEATURE_AUDIO_LOW_LATENCYを選択します。 （「低遅延」は片道50ミリ秒、プロは20ミリ秒未満の往復です。）
OpenSLを使用します。 Dalvik GCの償却コストは低くなりますが、実行時には、低遅延のオーディオスレッドが許容できる時間よりも時間がかかります。
バッファキューコールバックでオーディオを処理します。システムは、通常のユーザーモードスレッドよりも有利なスケジューリングを持つスレッドでバッファーキューコールバックを実行します。
バッファーサイズをAudioManager.getProperty（PROPERTY_OUTPUT_FRAMES_PER_BUFFER）の倍数にします。そうしないと、コールバックは1つではなくタイムスライスごとに2つの呼び出しを取得することがあります。 CPU使用量が本当に少ない場合を除き、これはおそらくグリッチを引き起こすでしょう。 （Android Mでは、バッファ処理コードのバグのため、システムバッファサイズを正確に使用することが非常に重要です。）
AudioManager.getProperty（PROPERTY_OUTPUT_SAMPLE_RATE）によって提供されるサンプルレートを使用します。それ以外の場合、バッファはシステムリサンプラーを迂回します。
バッファコールバック内でsyscallを作成したり、同期オブジェクトをロックしたりしないでください。同期する必要がある場合は、ロックフリー構造を使用してください。最良の結果を得るには、シングルリーダーシングルライターリングバッファーなど、完全に待機のない構造を使用してください。多くの開発者がこれを誤解し、予測不能でデバッグが困難なグリッチが発生します。
NEON、SSE、または同等の命令セットがターゲットプロセッサ上にあるものなど、ベクトル命令を使用します。
コードをテストおよび測定します。実行にかかる時間を追跡します。最悪のケースがグリッチの原因であるため、平均ではなく最悪のケースのパフォーマンスを知る必要があることを忘れないでください。そして保守的になります。オーディオを処理するのに、再生するよりも時間がかかる場合、レイテンシーが低くなることはないことを既に知っています。ただし、Androidこれはさらに重要です。CPU周波数が大きく変動するためです。おそらくオーディオのCPUの60〜70％を使用できますが、これはデバイスとして変更されることに注意してくださいより高温または低温になるか、wifiまたはLTE無線が起動および停止するなど）。
低遅延オーディオはAndroidの新機能ではなくなりましたが、ハードウェア、ドライバー、カーネル、およびフレームワークのデバイス固有の変更が必要です。つまり、さまざまなデバイスから期待できるレイテンシには多くのばらつきがあり、さまざまな価格帯Android電話が販売されている数を考えると、おそらく常に違いがあります。FEATURE_AUDIO_PROまたはFEATURE_AUDIO_LOW_LATENCYを使用して、アプリに必要な遅延基準を満たすデバイスを特定します。
OpenSL ESを使用する場合、Jellybeanおよびそれ以降のバージョンのAndroidで低遅延出力を取得するには、次の要件を満たす必要があります。
オーディオは、モノラルまたはステレオのリニアPCMである必要があります。
オーディオのサンプルレートは、出力のネイティブレートと同じサンプルレートである必要があります（一部のデバイスでは、
FastMixerisベンダーがそうするように設定した場合、リサンプリングできますが、私のテストでは、FastMixer）で44.1から48 kHzにアップサンプリングすると、非常に顕著なアーティファクトが得られました。BufferQueueには少なくとも2つのバッファーが必要です。 （この要件はその後緩和されました。GlennKastenによる this commit を参照してください。どのAndroidこのバージョンが最初に登場したバージョンかはわかりませんが、推測は4.4 ）。特定のエフェクト（リバーブ、ベースブースト、イコライゼーション、仮想化など）を使用することはできません。
SoundPoolクラスは、可能な場合、内部で高速AudioTracksを使用しようとします（BufferQueue部分を除き、上記と同じ基準が適用されます）。
ポイント1のリンクから：
「低遅延オーディオ
Android 4.2では、OpenSL ES、Soundpool、およびトーンジェネレーターAPIを使用した音声出力遅延のAndroid 4.1リリースでの改善から始まり、低遅延音声再生のサポートが改善されています。これらの改善はハードウェアサポートに依存しています。これらの低遅延オーディオ機能を提供するデバイスは、ハードウェア機能定数を介してサポートをアプリにアドバタイズできます。」
完全な形式の引用：
「パフォーマンス
OpenSL ESはネイティブC APIであるため、OpenSL ESを呼び出す非Dalvikアプリケーションスレッドには、ガベージコレクションの一時停止などのDalvik関連のオーバーヘッドはありません。ただし、OpenSL ESを使用しても、これ以外のパフォーマンス上の利点はありません。特に、OpenSL ESを使用しても、プラットフォームが一般的に提供するものよりもオーディオレイテンシが低くなったり、スケジューリングの優先順位が高くなったりすることはありません。一方、Androidプラットフォームおよび特定のデバイス実装が進化し続けるにつれて、OpenSL ESアプリケーションは、将来のシステムパフォーマンスの改善から恩恵を受けることが期待できます。」
そのため、ドライバーと通信し、次にhwと通信するapiはOpenSlです（Openglがグラフィックスと同じ方法で）。ただし、以前のバージョンのAndroidは、ドライバーやハードウェアの設計が不適切です。これらの問題は4.1および4.2バージョンで対処および修正されたため、hdにパワーがある場合は、OpenSLを使用して低レイテンシを取得します。
繰り返しになりますが、puredataライブラリWebサイトのこのノートから、ライブラリがOpenSL自体を使用して低レイテンシを実現していることが明らかです。
準拠デバイスの低遅延サポートAndroidの最新バージョンのPd（2012/12/28現在）は、準拠Androidデバイスの低遅延オーディオをサポートしています。コピーを更新するときは、pd-for-Androidとlibpdサブモジュールの両方の最新バージョンをGitHubから取得してください。
執筆時点で、Galaxy Nexus、Nexus 4、およびNexus 10は、オーディオ出力用の低レイテンシトラックを提供します。低遅延トラックに到達するには、アプリはOpenSLを使用し、正しいサンプルレートとバッファーサイズで動作する必要があります。これらのパラメーターはデバイスに依存します（Galaxy NexusおよびNexus 10は44100Hzで動作し、Nexus 4は48000Hzで動作します。バッファーサイズはデバイスごとに異なります）。
当然のことながら、AndroidのPdは、これらすべての複雑さを可能な限り網羅し、以前のバージョンのAndroidとの下位互換性を維持しながら、新しい低遅延機能へのアクセスを提供します。内部では、AndroidのPdのオーディオコンポーネントはAndroid 2.3以降でOpenSLを使用し、Javaの古いAudioTrack/AudioRecord APIにフォールバックします。 Android 2.2およびそれ以前。
Androidの10ミリ秒の問題、つまりAndroidの低遅延オーディオに関心がある方。 Superpoweredでは、Android Audio Path Latency Explainerを作成しました。こちらをご覧ください。
http://superpowered.com/androidaudiopathlatency/#axzz3fDHsEe56
新しいC++ライブラリ Oboe があり、オーディオレイテンシーの削減に役立ちます。私は自分のプロジェクトでそれを使用しましたが、うまく機能しています。オーディオレイテンシの削減に役立つ次の機能があります。
- 自動レイテンシー調整
- オーディオAPIを選択します（API 16+ではOpenSL ES、API 27+ではAAudio）
SampleRateおよびbufferSizeを測定するためのアプリケーション： https://code.google.com/p/high-performance-audio/source/checkout および http://audiobuffersize.appspot.com/ 結果のDB