名前付きパイプからオーディオを読み書きしています。読み取りプロセスが遅れ、パイプのバッファがいっぱいになり、フレームがドロップするという問題が発生しています。任意の大きさのバッファをパイプに挿入したいのですが。
これを行うために「dd」を使用しようとしていますが、「obs」と「ibs」はバッファサイズではなく、読み取り/書き込みブロックサイズを参照しているようです。
この目的で「dd」を使用する方法はありますか?
それはそれ自体で使用することができますが、それはひどいです。
例えば、 dd bs=1M
は1MiBバッファーになりますが、オーディオの問題が解決しない場合があります。 dd
が短い読み取りを取得すると、それを直接渡すため、バッファ自体は使用されません。あなたは付け加えられます iflag=fullblock
dd
がバッファを完全にいっぱいにするように強制しますが、1 MiBのデータを読み取り、1 MiBのデータを書き込み、1MiBのデータを読み取ります...dd
はしません出力ステップが完了する前に新しい入力を受け入れるので、「バッファ」は100%いっぱい、100%空、100%いっぱいになります...そして、バッファがいっぱいになる/空になるのにどれだけ時間がかかるとしても、反対側は動きがとれない。
これは、パイプバッファについて考えるときに必要な/期待する特性ではありません。 bfr
やpv
などの実際のパイプバッファを見ると、出力の進行中にすべて新しい入力を受け入れ、全体を通して良好な充填率を維持しようと努めているため、どちらの側もこれ以上待つ必要はありません。絶対に必要以上に。
実際のパイプバッファでは、入力は常に受け入れられ(バッファがいっぱいでない間)、出力は常に提供されます(バッファが空でない間)。また、プリフィル、最小フィルなどの高度なオプションがある場合があります。 ..
dd
はそれを行いません。実際、dd
は外部で行われるバッファリングに依存しています。ブロックデバイスを操作する場合、読み取り/書き込みの同時実行性は主にカーネルによって提供されます(readahead /キャッシュ/...)。
基本的に、dd
は、使用可能なタスクに適した他のプログラムがない最小限の環境でのパイプバッファーと見なすだけです。
dd
を使用する必要があるが、dd
の特性がタスクに適していない場合は、複数のdd
をデイジーチェーン接続して、バッファーの「スムーズな」結果を得ることができます。ただし、それでも一部のユースケースには適さない場合があります。