名前付きパイプからオーディオを読み書きしています。読み込み処理が遅れてパイプバッファがいっぱいになってフレームが削除される問題が発生しました。パイプにランダムに大きなサイズのバッファを挿入したいと思います。
これを行うために「dd」を使用しようとしていますが、「obs」と「ibs」はバッファサイズではなく読み書きブロックサイズを表すようです。
これを達成するために「dd」を使用する方法はありますか？
答え1
こうして使えますが、悪く使えます。
たとえば、dd bs=1M1MiBバッファですが、オーディオの問題が解決しない場合があります。短い読み取りを受け取ると、ddバッファを使用しないように直接渡されます。バッファを完全に埋めるようにiflag=fullblock強制することができますが、ddそれは1MiBのデータを読み込み、1MiBのデータを書き、1MiBのデータを読み取る...dd出力ステップが完了するまで新しい入力を受け入れません。 「バッファ」は100%完全、100%空いて、100%完全でした。バッファがいっぱいになるか空になるのにどれくらい時間がかかっても、反対側は止まります。
これは、パイプバッファを考えるときに望んだり期待したりする機能ではありません。bfrあるいは、そのような実際のパイプバッファを見てみると、どちらも出力がpv進行中に新しい入力を受け入れ、プロセス全体にわたって良好な充填速度を維持しようとするので、どちらも絶対に必要なものより長く待つ必要はありません。
実際のパイプバッファを使用すると、入力が常に許可され（バッファがいっぱいでない場合）、出力が常に提供され（バッファが空でない場合）、保証された事前入力、最小充填待機などの高度なオプションがあります。 ..
dd何もせず、実際にdd外部で実行されるバッファリングに依存します。
デフォルトでは、使用可能なdd操作に適した他のプログラムがない最小限の環境では、パイプバッファと見なされます。
必ず使用する必要がありますddが、その特性がdd操作に適していない場合は、dd「より滑らかな」結果のために複数のバッファをデイジーチェーン方式でリンクできます。しかし、それにもかかわらず、一部のユースケースには適していない可能性があります。