問題タブ [extaudiofileread]

この問題は、オーディオの再生を頻繁に停止および開始し、ExtAudioFileRefオブジェクトを介して AAC オーディオ ファイル内を何度もシークするときに発生します。まれに、この奇妙な動作は次のように表示されExtAudioFileReadます。

場合によっては、これらの番号をmDataByteSizeの のみAudioBufferに割り当てAudioBufferListます。

16 進数では、これらの数値のパターンは0xFC....00です。

コード：

出力：

この問題は、iOS 7 の iPhone 4S で発生します。シミュレーターで問題を再現できませんでした。

ExtAudioFileRead を使用して iOS でオーディオ ファイルを読み取ると、eof に達するとリーダーが完全にフリーズするようです… 例では、_abl AudioBufferList と _eaf ExtendedAudioFileRef が割り当てられ、正しく構成されていると仮定します。

エラーは発生せず、リーダーがファイルの最後でスタックしたかのように、常に同じ動作をします。ExtAudioFileTell は要求されたシークを確認します。また、ファイル内の位置を追跡して、eof で利用可能なフレーム数のみを要求しようとしましたが、同じ結果になりました。最後のパケットが読み取られるとすぐに、シークは効果がないようです。

他の状況で喜んで探します。

バグ？特徴？差し迫った顔の手のひら？これを解決するための助けをいただければ幸いです。

これを iPad 3 ( iOS7.1 ) でテストしています。

乾杯、

グレッグゾ

そこで、マルチチャンネル ミキサーとリモート I/O ユニットをセットアップして、オーディオ ファイルから読み取った PCM データの複数のバッファーをミックス/再生しました。ゲームの短いサウンド エフェクトの場合、ファイル全体をメモリ バッファにロードしますExtAudioFileRead()。

バックグラウンド ミュージックとして、3 分間の圧縮オーディオ ファイルがあるとします。mp3 @ 128 kbps (44,100 Hz ステレオ) としてエンコードされていると仮定すると、1 分あたり約 1 MB、つまり合計 3 MB になります。無圧縮の記憶では、私の記憶が正しければ10倍くらいはあると思います。小さなファイルの場合とまったく同じ方法を使用できます。ExtAudioFileRead()利用可能な場合は（単一の）ハードウェアデコーダーを使用してデコードを処理すると思いますが、バッファー全体を一度に読み取るのではなく、ディスクから定期的に「ストリーミング」したいと思います。

最初に頭に浮かぶのは、(「拡張されていない」) Audio File Services API の 1 つ下のステップに進み、次AudioFileReadPackets()のように を使用することです。

1. 2 つのバッファ A と B を準備します。それぞれが 5 秒間のオーディオを保持するのに十分な大きさです。再生中、一方のバッファから読み取りを開始し、最後に到達したらもう一方のバッファに切り替えます (つまり、リング バッファの 2 つの半分を構成します)。

2. ファイルからオーディオの最初の 5 秒間をバッファー A に読み取ります。

3. 次の 5 秒間のオーディオをファイルからバッファ B に読み込みます。

4. 再生を開始します (バッファー A から)。

5. 再生ヘッドがバッファ B に入ったら、次の 5 秒間のオーディオをバッファ A にロードします。

6. 再生ヘッドが再びバッファ A に入ったら、次の 5 秒間のオーディオをバッファ B にロードします。

7. #5へ

これは正しいアプローチですか、それとももっと良い方法がありますか?

ファイルに再保存する前に、ExtAudioFileRead の出力の振幅を減らしたいと考えています。これが私の元のコードです：

私は、convertedData.mBuffers[0].mData をループして、各サンプルに分数を乗算することを考えていましたが、それは "void" 型です。読んでくれてありがとう！

編集：

これが私が今下っているパスです：

出力ファイルは間違いなく入力のスケーリングされたバージョンではありませんが、これは上記の誤った変数の選択が原因である可能性があると思います.

私のアプリは、マイク入力からのオーディオに対して膨大なデータ処理を行っています。「デモ モード」を取得するために、ローカルの .caf オーディオ ファイルに基づいて同じことを行いたいと考えています。音声ファイルを取得することができました。ExtAudioFileRead を使用して .caf ファイルを読み取り、データ処理を実行しようとしています。

このコードがまったく機能しないため、ExtAudioFileRead を理解していなかったり、間違っていることが明らかにあります。私には2つの主な問題があります:

1. ファイルは瞬時に再生されます。つまり、44'100 サンプルは明らかに 1 秒に等しくありません。3 分間の音声ファイルの処理が数秒で完了します...
2. 処理中に、UI を更新する必要があります。そのため、 とにいくつかの dispatch_sync がprocessaudioありrealtimeUpdateます。これは ExtAudioFileRead ではあまり評価されていないようで、フリーズします。助けてくれてありがとう。

リモート I/O オーディオ ユニットと、ExtAudioFileRead を使用してオーディオ フレームをレンダリングするレンダリング コールバックを使用して、オーディオ ファイル プレーヤーを正常に実装しました。

現時点では、ExtAudioFileRead を使用したレンダー コールバックの代わりに kAudioUnitSubType_AudioFilePlayer を使用した場合の違いは何だろうと思っていました。このアプローチの利点は何ですか？

アップルのドキュメントから、違いを差し引くことはできません。

を使用して読み取ったオーディオ データを処理しようとしていますExtAudioFile。ただし、このデータを循環バッファーに入れようとすると、いくつかの不具合が聞こえます。

以下のコード例では、データを「inBuffer」から直接「outBuffer」に渡します (どちらもTPCircularBufferMichael Tyson によるタイプです)。両方のバッファーのサイズは 10 xnumberOfFrames * sizeof(float)です。クライアント ストリーム フォーマットは、フロート サンプルを使用したモノラルです。

データを処理しなくても、これらの不具合が聞こえるのはなぜですか? 循環バッファーがなければ、サウンドは適切にストリーミングされます。私は何を間違っていますか、それとも別のアプローチがより良いでしょうか?

編集 以下の回答に基づいて、コールバック関数の外部でメモリを割り当てて解放し、循環バッファのサイズを大きくしてコードを修正しました。残念ながら、サウンドは循環バッファーがない場合よりもさらに悪くなります。これらの不具合には別の理由があるのでしょうか?