0

私は純粋な Java オーディオ ミキシング ライブラリの作成をいじっています。できれば Android で使用できるもので、完全に実用的ではありませんが、間違いなく興味深いものです。私はそれがすでに行われていると確信していますが、私自身の学習経験のために、通常は回避する圧縮モデルがないため、wav ファイルでこれを実行しようとしています。

java.io の性質上、多くの InputStream タイプのクラスが定義されています。それぞれは、主に基礎となるリソースからデータを読み取るための操作を実装します。後でデータをどうするか、ダンプするか、独自のアドレス空間に集約するかなどは、あなた次第です。私はこれを純粋な Java にしたいと考えています。たとえば、何でも動作し (JNI は必要ありません)、低メモリ構成用に最適化され、拡張が簡単です。

RIFF 形式の性質と PCM サンプル データの組み立て方は理解できましたが、ファイルをメモリに展開するために必要なメモリを管理する最善の方法がわかりません。FileInputStream を使用すると、基盤となるファイル システムと読み取り操作の呼び出し方法に基づいて、一度に読み取られるデータの量が制限されます。FileInputStream は、後でミキシングするためにストリームを取得できないように、ファイル内の場所にインデックスを作成する方法を提供しません。私の目標は、RIFF ドキュメントを、基になるチャンクの適切な領域の読み取りと書き込みを可能にする Java オブジェクトに拡張することです。

すべての PCM サンプル データなど、全体にスペースを割り当てると、平均的な曲あたり 50 MB になります。一般的なスマートフォンまたはタブレットで、これが全体的なパフォーマンスに影響を与える可能性はどのくらいありますか? チャンクが InputStream のどこにあるかを追跡する独自の InputStream タイプを考えた方がよいでしょうか? ファイルの場合、これにより PCM サンプルを取得するときに多くのブロックが発生しますが、それでもシステムの全体的なメモリ フットプリントは削減されます。

4

1 に答える 1

1

あなたの質問のすべてを理解しているかどうかはわかりませんが、できる限りお答えします。コメントで明確にしてください。編集します。

DAW タイプのアプリや、大きなファイルの再生を想定するファイル/ビデオ プレーヤーでは、すべてのファイル データをメモリに保持しないでください。これは、メモリ モデルによっては一部のデバイスで機能する可能性がありますが、問題が発生しています。

代わりに、ファイルの必要なセクションを必要に応じて (オンデマンドで) 読み取ります。オーディオ再生スレッドでファイルを読み取りたくないため、実際にはそれよりも少し複雑です (低レイテンシーのオーディオ再生を高レイテンシーのファイル IO に依存させたくないため)。 ）。これを回避するには、ファイルの一部を事前にバッファする必要がある場合があります。(コールバック モデルとブロッキング モデルのどちらを使用しているかによって異なります)

FileInputStream を使用すると問題なく動作します。ファイル内のすべての場所を自分で追跡する必要があります (これには、ミリ秒などをサンプルからバイトに変換し、ヘッダーのサイズを考慮する必要があります[1])。少し良いオプションは RandomAccessFile です。ジャンプできるからです。

オーディオ ソフトウェアのプログラミングに関する講演からの私のスライドは、特にコールバック v ブロッキングに混乱している場合に役立つかもしれません。

[1] または、より正確には、ファイル内のオーディオ データのオフセットを知っています。

于 2012-05-26T23:48:23.933 に答える