問題タブ [opensl]

Android OpenSL ES AACデコーダーコードを使用してAACフレームをPCMにデコードする方法のサンプルソースコードはありますか？メモリバッファに保存されているAACフレーム（ADTSヘッダーありまたはなし）をPCMにデコードする必要があります。

AndroidでOpenSLを使用してサウンドを再生しています。このエラーが発生し続けます: CAudioPlayer の不明な AudioTrack イベント 5 が発生しました。android_AudioPlayer.cpp によると、値 5 (EVENT_BUFFER_END) はエラーとして扱われないため、これは発生しないはずです。Android 4.1.1 を使用しています。

OpenSLES仕様1.0.1は、3Dオーディオの実装を示しています。私の興味は、3Dオーディオソースの場所を指定することです。

これをAndroid14に実装しようとしましたが、結果として「SL_RESULT_FEATURE_UNSUPPORTED」が表示されました。このリンクで通知されているように、3Dロケーション、リスナー、および一般的にすべての3D機能などのOpenSL ES機能の3Dサウンドでは、USE_PROFILES_GAMEを設定する必要があります。

OpenSLESは独立したエンティティではなく、他のシステムライブラリ（wilhelm.soなど）に依存しているため、そのライブラリを独立してコンパイルすることはできませんでした。そこで、Androidソース全体をダウンロードし、USE_PROFILES_GAMEフラグを設定し、Android.mkに3D関連のクラスを含めました。これはデフォルトで除外されており、新しいシステムを構築します。

新しいAndroidシステムイメージを使用して、ロケーション推論を取得できますが、機能していないようです。つまり、ソースオーディオのロケーションが変化しているのを感じることができません。

誰かがAndroidに3Dオーディオ機能（特に3Dオーディオロケーション）を正常に実装したことがありますか？3Dオーディオ機能のモバイルハードウェアへの依存性はありますか？

どんな助けでも大歓迎です。

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

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 を使用しても、プラットフォームが一般的に提供するものよりもオーディオ レイテンシが低くなったり、スケジューリングの優先度が高くなったりすることはありません。」

実行中のデバイスでサポートされている OpenSL ES エフェクトを特定しようとしています。

Andorid SDK の AudioEffect クラスは、そのためのメソッドを提供します。

public static Descriptor[] queryEffects ()

私の問題は、そのメソッドによって返されたすべてのAudioEffect.Descriptorを考えると、それらの1つが実際に必要なものであるかどうかを判断する方法がわからないことです。

パブリック UUID タイプ

API レベル 9 で追加されました。エフェクトのジェネリック タイプを示します (イコライザー、ベース ブースト ...)。UUID は、このタイプのエフェクトの OpenSL ES インターフェイス ID に対応します。

type属性を使用する必要があるようですが、すべてのエフェクト タイプ UUID が指定されている OpenSL ES リファレンスが見つかりません。

どこで見つけられるか知っていますか？

デバイスでメソッドの結果をテストするUUIDを見つけることができましたが、

UUID は、特定の種類のエフェクトのすべてのデバイスで常に同じであると想定できますか?

前もって感謝します

デジタル フィルターを使用して、他の (ストック ミュージック プレーヤーや Spotify など) アプリからのオーディオ再生を処理するアプリを構築しようとしています。

これまでのところ、OpenSL ES でマイクからのオーディオ入力用のフィルターを作成できました。フィルタリングされたオーディオは、ハードウェア出力に送信されます。このアプリは、このチュートリアルhttp://audioprograming.wordpress.com/2012/03/03/android-audio-streaming-with-opensl-es-and-the-ndk/に基づいています。

ハードウェア出力に送信される前に処理できるように、他のアプリから同様の入力バッファを取得するにはどうすればよいですか?

OpenSL ES やその他のネイティブ コードを使用する必要はありません。明確にするために; アプリは、非推奨になる前にandroid.media.audioofx.AudioEffectと同様の方法でカスタム フィルター効果を適用する必要があり、グローバル オーディオ出力ミックス (オーディオ セッション 0) にアタッチできます。

このリンクで説明されている同様の問題があります。

OpenSL の RecorderObject は、Android で音量を設定または構成するためのインターフェイスを実装していません

問題は、Android の OpenSL ES ではレコーダーのボリューム インターフェイスの取得がサポートされていないため、レコーダーのボリュームを設定できないことです。これはほとんどの携帯電話では問題になりませんが、一部の携帯電話 (Samsung Note 2 など) では、マイクに向かって大きな声で話すと、キャプチャされた音声が大きく歪んでしまいます。

OpenSL ES でキャプチャされたオーディオの音量を調整するための回避策はありますか?

私が作成した 1 つのアプリは、顧客のデバイスで大規模なログ スパムを引き起こします。

リアルタイム オーディオ生成のために、NDK 環境で OpenSL を使用しています。SLAndroidSimpleBufferQueueItf の Enqueue() 関数を使用するたびに、android はログ エントリを作成します。これは、その呼び出しがオーディオ インターフェイスで暗黙的に play() を呼び出すためです。

これは次のようになります。

これは、新しいオーディオ バッファを OpenSLES にエンキューする方法です。

OpenSLES はその呼び出しについて文句を言わず、SL_RESULT_SUCCESS を返します。

少しググったところ、ログ エントリが Android ソースの AudioTrack からのものであることがわかりました。

https://android.googlesource.com/platform/frameworks/base/+/android-2.2.3_r2.1/media/libmedia/AudioTrack.cpp

start() 関数の先頭にログがあります。

しかし、新しいバッファがキューに入れられるたびに OpenSL が暗黙のうちに play() を呼び出すようにしている理由は何でしょうか? ここで OpenSL の仕様を確認しました: http://www.khronos.org/registry/sles/specs/OpenSL_ES_Specification_1.0.1.pdf

174 ページで、「プレーヤーが SLPlayItf インターフェイス [セクション 8.32 を参照] によって制御される SL_PLAYSTATE_PLAYING 状態にある場合、バッファーを追加すると、暗黙的に再生が開始されます。キュー内のバッファーが不十分なために飢餓状態になった場合、再生はオーディオ データの停止. プレーヤーは SL_PLAYSTATE_PLAYING 状態のままです. 追加のバッファーをキューに入れると、オーディオ データの再生が再開されます. キューに入れられたバッファーが不足すると、オーディオ データ ストリームに可聴ギャップが生じることに注意してください.再生中の状態では、バッファを追加してもオーディオの再生は開始されません。」

電話はパチパチ音をたてていないので、オーディオはまだうまく再生されていると思います。ドキュメントのこの説明は、常に暗黙的に再生を開始するように聞こえます。これは、このログのスパムを防ぐ機会がないことを意味します.

何か案は？

2 つ以上 (たとえば、最大 5 つ) の短い ogg ファイルを同時に再生できる必要があります。同時にとは、完全な同期を意味します。それらをSoundPoolにロードして再生することはできますが、これにより再生開始時間に顕著な差が生じることがあります。これを取り除きたいです。

私の理解では、PCM を 1 つのバッファーにミックスして再生すると、これを回避できます。しかし、OGG は PCM ではないため、再生前に何らかの方法で効率的にデコードする必要があり、理想的にはユーザーがボタンを押した直後にレイテンシーを非常に低くする必要があります。そこで、OGG を PCM にストリーミングする方法が必要だと考えました。バッファを受信したら、それらをミックスして AudioTrack にフィードします。私の要件は Android 2.3.3+ であるため、Jelly Bean で提供される新しいコーデックは使用できません。

また、OGG 自体は小さいですが、たくさんあります。そのため、それらをすべてメモリにデコードしておくと (SoundPool または一部のプリデコード)、問題が発生する可能性もあります。

誰かがどこを掘るべきかヒントをくれますか? OpenSL ES はそれを行うことができますか? または、ffmpeg の統合を検討する必要がありますか? また、低遅延で同時ファイルをストリーミングすることさえ可能ですか?

ありがとう