1

私はオーディオ再生を中心とした Android アプリに取り組んでおり、特定のデバイス、OS バージョン、またはデバイスのネイティブ バッファ サイズに固有の可能性があると思われる不規則な動作 (オーディオの吃音やしゃっくり) が発生しています。

私の実装について - 低レイテンシーが必要なので、オーディオを OpenSL ES コールバックで処理し、128 サンプルのかなり小さいバッファー サイズを使用してバッファーをエンキューしています。コールバック中に mp3 のデコードを行っていますが、リング バッファーのサイズでは、コールバック サイクルごとにデコードする必要はありません。

リモート テスト サービスを使用して、さまざまなデバイスや OS バージョンでのオーディオ再生品質を測定しています。ここに、私が見つけた不一致の例をいくつか示します。

  • Android 4.4搭載のSamsung Galaxy S4 - オーディオ再生の問題なし
  • Android 4.3 搭載の Samsung Galaxy S4 - デバイスのロック/ロック解除時にオーディオのドロップアウト/スタッターが発生する
  • Android 4.1.2 搭載の Samsung Galaxy Note 2 - 問題なし
  • Android 4.3 搭載の Samsung Galaxy Note 2 - 再生中にオーディオがドロップアウトし、画面のロック/ロック解除時に途切れます。

個人的には、4.1.2 を搭載した Galaxy S3 と 4.4 を搭載した Nexus 5 を使用していますが、これらの問題が発生したことはありません。また、これらの問題が発生しない古い 2.3.7 デバイスもいくつか持っています (2010 Droid Incredible、LG Optimus Elite)。

これは古いジンジャーブレッド デバイスでも問題なく実行できるため、プロセッサを使いすぎていないと確信しています。

私の質問:

  1. ベース SDK を 4.2 に上げると、ハードウェアからネイティブ バッファー サイズを検出し、バッファー キューのコールバック中にその倍数を使用できます。これは、特に画面ロック中に吃音やドロップアウトが問題になる場合に大きな違いをもたらすでしょうか?
  2. Android 4.3 の既知のバグで、特に画面ロック アクション中にオーディオの再生に問題はありますか? これはおそらくサムスンの問題ですか？
  3. この問題を回避するためにパフォーマンスを向上させる他の方法はありますか? アプリには OpenSL ES が絶対に必要です。

ありがとう。

4

1 に答える 1

0

バッファ サイズを大きくすると、歪みやノイズに関するいくつかの問題が解決されます。はい、SDK が 4.2 以上の場合、ハードウェアからネイティブ バッファ サイズを検出できます。

String size = audioManager.getProperty(AudioManager.PROPERTY_OUTPUT_FRAMES_PER_BUFFER);

しかし、オーディオ レコードの最小バッファ サイズを取得する別の方法は次のとおりです。

int minForAudioRecord = AudioRecord.getMinBufferSize(8000,
                AudioFormat.CHANNEL_IN_MONO,
                AudioFormat.ENCODING_PCM_16BIT);

オーディオ再生の場合:

int minForAudioTrack = AudioTrack.getMinBufferSize(8000,
                AudioFormat.CHANNEL_OUT_MONO,
                AudioFormat.ENCODING_PCM_16BIT);

SDK のバージョンが 4.2 以上の場合は、オーディオのサンプル レートを優先できます。

String rate = audioManager.getProperty(AudioManager.PROPERTY_OUTPUT_SAMPLE_RATE);

デバイスごとにオーディオ ドライバーを処理する方法が異なるため、これらの処理を行っているときにサムスンのデバイスが最悪であることがわかりました。

于 2014-03-19T11:05:53.383 に答える