It could be used as such, but it sucks.
dd bs=1M would be a 1 MiB buffer, however it might not solve your audio problem. If
dd gets a short read, it will pass that along directly, so it won't use the buffer as such. You can add
iflag=fullblock to force
dd filling up its buffer entirely, but then it would read 1 MiB of data, write 1 MiB of data, read 1 MiB of data, ...
dd won't accept new input before the output step is done, so your "buffer" would be 100% full, 100% empty, 100% full... and for however long it takes the buffer to fill up / empty out, the other side will be stuck.
This is not a characteristic you want/expect when thinking of pipe buffers. If you look at actual pipe buffers such as
pv, they all accept new input while output is going on, they strive to maintain a good fill rate throughout so neither side has to wait more than absolutely necessary.
With a real pipe buffer, input will always be accepted (while the buffer is not full) and output will always be provided (while the buffer is not empty) and they might have advanced options such as guaranteeing a prefill, min-fill, ...
dd doesn't do any of that, in fact
dd relies on buffering being done on the outside, when working with block devices, read/write concurrency is largely provided by the kernel (readahead/cache/...).
Basically you'd only consider
dd as a pipe buffer in minimalistic environments that have no other programs suited to the task available.
If you must use
dd but the characteristics of
dd are not suited to your task, you could daisy chain multiple
dd to get a "smoother" result of a buffer. But even then it might not be suitable for some use cases.