0

iPhone アプリの基本的なレイテンシーを測定するテストを実行していますが、結果は期待外れでした: プレイスルー テスト アプリで 50ms でした。アプリはマイク入力を取得し、同じレンダリング コールバックを使用して再生するだけで、他のオーディオ ユニットや処理は必要ありません。したがって、このような基本的なシナリオでは結果があまりにも悪いように見えました。結果が理にかなっているかどうか、またはテストに設計上の欠陥があったかどうかを確認するには、いくつかの指針が必要です。

このテストの基本的な考え方は、次の 3 つの役割を持つことでした。

  1. 参考音源は私のフィンガースナップ。
  2. #1 の最初のリスナーとしてのシンプルな iOS プレイスルー アプリ (内蔵マイクを使用)。
  3. Mac (USB マイクと Audacity を搭載) を #1 の 2 番目のリスナーとして使用し、iOS 出力 (iOS ヘッドフォン ジャック経由で接続されたスピーカーを介して) の唯一のリスナーとして使用します。

次に、Audacity を録音モードにすると、Mac は私の指からの音と、近距離にある iOS スピーカーからのその「クローン」の両方を拾います。最後に、Audacity の記録されたトラックの波形を視覚的に観察し、記録された 2 つのスナップのピーク間の時間間隔を測定します。

これは決して正確な測定値ではありませんでしたが、少なくとも Mac のレコーディング パイプラインの生来のレイテンシーはこの方法で相殺されているはずです。そのため、エラーは主にピーク距離測定に起因するはずであり、これはオーディオ パイプラインのレイテンシよりもはるかに小さく、無視できるはずです。

20 ミリ秒以下のレイテンシを期待していましたが、結果は明らかに 50 ～ 60 ミリ秒でした。私の ASBD は kAudioFormatFlagsCanonical と kAudioFormatLinearPCM をフォーマットとして使用します。

4

3 に答える 3

0

私の問題を解決した答えとして、Paul Rのコメントを要約します。

50 ミリ秒は、44.1 kHz のサンプル レートで約 2048 の合計バッファー サイズに相当します。これは、記録パスと再生パスの両方があることを考えると、不合理ではないようです。

バッファ サイズが 2048 であることはわかりませんが、記録再生ループバック テストには複数のバッファが存在する可能性がありますが、テストでの有効な合計バッファ サイズはおそらく 2048 程度のようです。理不尽に思えません。もちろん、質問のタイトルが示すように、レコードのレイテンシーのみに関心がある場合は、再生のレイテンシーとは別にそれを引き出す方法を見つける必要があります。

于 2013-05-21T21:50:09.293 に答える