[mbell]

> introduces timing

SPDIF also combines the clock and data in a single signal, it has more or less the same issues with jitter that USB does. Not that it matters since I'm not aware of a single proper study that indicates jitter is audible.

[DigitalJack]

I would be shocked if there wasn't a hardware fifo in that receiver path.

[mbell]

Depends on the device.

Often there is a receiver IC that will perform clock recovery and convert from S/PDIF to an internal digital audio format, I2S most commonly, to send it to a DAC IC. In this simple setup there generally is no more buffering than needed for operation of the pieces.

In more complex situations, either where the S/PDIF signal is being re-clocked or where the data on the S/PDIF line needs to be decoded, then they will be buffering.

To clarify some terms:

Re-clocking - the system detects the clock rate of the signal but does not use that clock as the reference, instead it will generate it's own clock at the proper frequency. Some buffering is needed here to offset drift between the clocks causing sample starvation.

Encoded data - S/PDIF (really AES3 for the most part) has a framed block transmission format not entirely dissimilar to a TCP packet. There is meta-data, frames, sub-frames, etc, it's not just 'pure audio'. Various formats can be stuffed into these data frames, like compressed audio data (5.1 Dolby Digital for example).