41

現在、単純なアプリケーションのオーディオ遅延を最小限に抑えようとしています:

PC にビデオがあり、ビデオのオーディオを RTP 経由でモバイル クライアントに送信しています。非常によく似たバッファリング アルゴリズムを使用すると、iOS では 90 ミリ秒のレイテンシを達成できますが、Android では恐ろしい ±180 ミリ秒です。

この違いは、Androidでよく知られている遅延の問題に起因していると思います。

ただし、少し読んだ後、次の記事に出くわしました。

  1. 一部のデバイスでは、Android 4.1/4.2 以降で低遅延オーディオを利用できます。

  2. Android 用の Pure Data ライブラリである libpdを使用して、低遅延のオーディオを実現できます。

これらの 2 つのステートメントに直接関連する 2 つの質問があります。

  1. Jellybean の新しい低遅延オーディオに関する詳しい情報はどこで入手できますか? これは私が見つけることができるすべてですが、具体的な情報が非常に不足しています。変更は透過的である必要がありますか?それとも、アプリケーションの変更に気付くために実装する必要がある新しいクラス/API 呼び出しはありますか? 私は AudioTrack API を使用していますが、この改善の恩恵を受けるかどうか、またはオーディオ再生のための他のメカニズムを検討する必要があるかどうかさえわかりません。

  2. libpd の使用を検討する必要がありますか? 低レイテンシーを達成する唯一のチャンスのように思えますが、私は常に PD をオーディオ合成ユーティリティと考えてきたので、ネットワーク ストリームからフレームを取得して再生するプロジェクトに本当に適していますか? ? 私は実際に合成を行っていません。私は間違った道をたどっていますか？

追記として、誰かが OpenSL ES について言及する前に、この記事では、OpenSL ES を使用しても遅延の改善は期待できないことを明確にしています。

「OpenSL ES はネイティブ C API であるため、OpenSL ES を呼び出す非 Dalvik アプリケーション スレッドには、ガベージ コレクションの一時停止などの Dalvik 関連のオーバーヘッドはありません。しかし、これ以外に OpenSL ES を使用することによる追加のパフォーマンス上の利点はありません。特に、OpenSL ES を使用しても、プラットフォームが一般的に提供するものよりもオーディオ レイテンシが低くなったり、スケジューリングの優先度が高くなったりすることはありません。」

4

7 に答える 7

69

バージョン 4.2.2 の時点で Android のレイテンシを最小限に抑えるには、次の手順を実行する必要があります。

  1. 可能な場合は FEATURE_AUDIO_PRO をサポートするデバイスを選択し、そうでない場合は FEATURE_AUDIO_LOW_LATENCY をサポートするデバイスを選択します。(「低遅延」は片道 50 ミリ秒、プロは往復 20 ミリ秒未満です。)

  2. OpenSL を使用します。Dalvik GC の償却コストは低くなりますが、実行すると、低レイテンシのオーディオ スレッドが許容できる以上の時間がかかります。

  3. バッファ キュー コールバックでオーディオを処理します。システムは、通常のユーザー モード スレッドよりも有利なスケジューリングを持つスレッドでバッファー キュー コールバックを実行します。

  4. バッファー サイズを AudioManager.getProperty(PROPERTY_OUTPUT_FRAMES_PER_BUFFER) の倍数にします。そうしないと、タイムスライスごとにコールバックが 1 回ではなく 2 回呼び出されることがあります。CPU 使用率が非常に低い場合を除き、これはおそらくグリッチを引き起こすでしょう。(Android M では、バッファ処理コードのバグにより、システム バッファ サイズを正確に使用することが非常に重要です。)

  5. AudioManager.getProperty(PROPERTY_OUTPUT_SAMPLE_RATE) によって提供されるサンプル レートを使用します。そうしないと、バッファーはシステムのリサンプラーを迂回します。

  6. syscall を作成したり、バッファ コールバック内で同期オブジェクトをロックしたりしないでください。同期する必要がある場合は、ロックフリー構造を使用してください。最良の結果を得るには、シングル リーダー、シングル ライターのリング バッファーなど、完全にウェイトのない構造を使用してください。多くの開発者がこれを誤解し、予測不能でデバッグが困難な不具合を引き起こします。

  7. NEON、SSE などのベクトル命令、またはターゲット プロセッサにある同等の命令セットを使用します。

  8. コードをテストして測定します。実行にかかる時間を追跡します。また、平均ではなく、最悪の場合のパフォーマンスを知る必要があることを忘れないでください。最悪の場合がグリッチの原因となるためです。そして保守的であること。オーディオの再生よりも処理に時間がかかる場合、レイテンシーが低くなることはありません。しかし、Android では、CPU 周波数が大きく変動するため、これはさらに重要です。おそらく 60 ～ 70% の CPU をオーディオに使用できますが、これは、デバイスが熱くなったり冷たくなったり、wifi や LTE 無線の開始と停止などによって変化することに注意してください。

低レイテンシ オーディオは、もはや Android の新しい機能ではありませんが、ハードウェア、ドライバー、カーネル、およびフレームワークでデバイス固有の変更を行う必要があります。これは、さまざまなデバイスで予想される遅延に多くのばらつきがあることを意味し、Android スマートフォンが販売されているさまざまな価格帯の数を考えると、おそらく常に違いがあるでしょう. FEATURE_AUDIO_PRO または FEATURE_AUDIO_LOW_LATENCY を探して、アプリが必要とするレイテンシ基準を満たすデバイスを特定します。

于 2013-04-25T02:21:57.337 に答える
6

OpenSL ES を使用する場合、Jellybean 以降のバージョンの Android で低遅延の出力を取得するには、次の要件を満たす必要があります。

  • オーディオは、モノラルまたはステレオのリニア PCM である必要があります。

  • オーディオのサンプル レートは、出力のネイティブ レートと同じサンプル レートである必要があります (これは一部のデバイスでは実際には必要ない場合があります。これは、ベンダーが再サンプリングを行うように構成している場合、 は再サンプリングできるためFastMixer です。しかし、私のテストでは、非常に目立ちました。で 44.1 から 48 kHz にアップサンプリングするときのアーティファクトFastMixer)。

  • BufferQueue少なくとも 2 つのバッファーが必要です。(この要件はその後緩和されました。Glenn Kasten によるこのコミットを参照してください。これが最初に登場した Android バージョンはわかりませんが、4.4 と推測されます)。

  • 一部のエフェクトは使用できません (リバーブ、バス ブースト、イコライゼーション、バーチャライゼーションなど)。

このSoundPoolクラスは、可能な場合には fast を内部的に使用しようとしますAudioTrack(一部を除いて、上記と同じ基準が適用されますBufferQueue)。

于 2013-02-21T15:43:20.087 に答える
5

ポイント1のリンクから：

「低遅延オーディオ

Android 4.2 では、Android 4.1 リリースで行われた OpenSL ES、Soundpool、およびトーン ジェネレータ API を使用したオーディオ出力レイテンシの改善から始めて、低レイテンシ オーディオ再生のサポートが改善されています。これらの改善は、ハードウェア サポートに依存します。これらの低レイテンシ オーディオ機能を提供するデバイスは、ハードウェア機能定数を介してアプリにサポートを通知できます。」

完全な形式のあなたの引用:

"パフォーマンス

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 で動作します。バッファ サイズはデバイスごとに異なります)。

いつものように、Pd for Android はこれらすべての複雑さについて可能な限り詳しく説明し、以前のバージョンの Android との下位互換性を維持しながら、利用可能な場合は新しい低遅延機能へのアクセスを提供します。内部的には、Pd for Android のオーディオ コンポーネントは Android 2.3 以降では OpenSL を使用し、Android 2.2 以前では Java の古い AudioTrack/AudioRecord API にフォールバックします。

于 2013-02-21T15:21:14.213 に答える
3

Android の 10 ミリ秒問題、つまり Android での低遅延オーディオに関心のある方。Superpowered では、Android Audio Path Latency Explainer を作成しました。こちらをご覧ください：

http://superpowered.com/androidaudiopathlatency/#axzz3fDHsEe56

于 2015-07-07T16:10:48.573 に答える
1

オーディオ レイテンシの削減に役立つ新しい C++ ライブラリOboeがあります。私は自分のプロジェクトでそれを使用しましたが、うまく機能します。オーディオの遅延を減らすのに役立つ次の機能があります。

  • 自動遅延調整
  • オーディオ API を選択します (API 16+ の OpenSL ES または API 27+ の AAudio)
于 2018-11-09T14:08:34.887 に答える
0

sampleRate と bufferSize を測定するためのアプリケーション: https://code.google.com/p/high-performance-audio/source/checkoutおよびhttp://audiobuffersize.appspot.com/結果の DB

于 2013-08-19T14:19:20.520 に答える