Poderia ser usado como tal, mas é uma droga.
Por exemplo, dd bs=1M seria um buffer de 1 MiB, mas pode não resolver seu problema de áudio. Se dd obtiver uma leitura curta, ela será transmitida diretamente, portanto, não usará o buffer como tal. Você pode adicionar iflag=fullblock para forçar o dd a preencher completamente seu buffer, mas depois ele leria 1 MiB de dados, gravaria 1 MiB de dados, leria 1 MiB de dados, ... dd não aceitaria novos entrada antes que o passo de saída seja feito, então o seu "buffer" estaria 100% cheio, 100% vazio, 100% cheio ... e por quanto tempo o buffer demorar para encher / esvaziar, o outro lado ficará preso .
Esta não é uma característica que você deseja / espera quando se pensa em buffers de pipe. Se você observar os buffers de pipe reais, como bfr ou pv , todos aceitam novas entradas enquanto a saída está em andamento, eles se esforçam para manter uma boa taxa de preenchimento para que nenhum dos lados precise esperar mais do que o necessário.
Com um buffer de tubo real, a entrada sempre será aceita (enquanto o buffer não estiver cheio) e a saída sempre será fornecida (enquanto o buffer não estiver vazio) e eles podem ter opções avançadas, como garantia de pré-preenchimento, preencha, ...
dd não faz nada disso, na verdade dd confia no buffering sendo feito no exterior, ao trabalhar com dispositivos de bloco, a simultaneidade de leitura / gravação é amplamente fornecida pelo kernel (readahead / cache /. ..).
Basicamente, você considera apenas dd como um buffer de tubulação em ambientes minimalistas que não possuem outros programas adequados à tarefa disponível.
Se você precisar usar dd , mas as características de dd não forem adequadas para sua tarefa, você poderá encadear vários dd para obter um resultado "mais suave" de um buffer. Mas, mesmo assim, pode não ser adequado para alguns casos de uso.