它可以这样使用，但它很糟糕。
例如，dd bs=1M将是 1 MiB 缓冲区，但它可能无法解决您的音频问题。如果dd读取时间较短，它将直接传递它，因此它不会使用缓冲区。您可以添加iflag=fullblock以强制dd完全填充其缓冲区，但随后它将读取 1 MiB 数据、写入 1 MiB 数据、读取 1 MiB 数据……dd在输出步骤完成之前不会接受新输入，因此您的“缓冲区”将是 100% 满、100% 空、100% 满……无论缓冲区填满/清空需要多长时间，另一边都会被卡住。
在考虑管道缓冲区时，这不是您想要/期望的特性。如果您查看实际的管道缓冲区，例如bfr或pv，它们在输出进行时都接受新输入，它们始终努力保持良好的填充率，因此任何一方都不必等待超过绝对必要的时间。
对于真正的管道缓冲区，将始终接受输入（当缓冲区未满时）并始终提供输出（当缓冲区不为空时）并且它们可能具有高级选项，例如保证预填充、最小填充、. ..
dd不做任何事情，实际上dd依赖于在外部完成的缓冲，当使用块设备时，读/写并发主要由内核提供（预读/缓存/...）。
基本上，您只会dd在没有其他适合该任务的程序的简约环境中将其视为管道缓冲区。
如果您必须使用dd但dd不适合您的任务的特性，您可以菊花链多个dd以获得缓冲区的“更平滑”结果。但即便如此，它也可能不适合某些用例。