The benefits are consistent regardless of whether the receiving device is a DAC or a USB bridge (network streamer to USB device).
I’m going to define STREAMER as “a device that receives audio over the network”.
I’m going to define PLAYER as “Roon, or any other transmitter of audio over the network”.
Airplay/Songcast:
[PLAYER] ---- [STREAMER with internal clocking crystal]
PLAYER pushes audio using it’s own clock, STREAMER pulls audio using it’s own clock. BAD: 2 CLOCKS FIGHTING!
[PLAYER] ---- [STREAMER connected to USB device that has its own clocking crystal]
PLAYER pushes audio using it’s own clock, USB device pulls from STREAMER using its own clock, STREAMER feeds its buffer of audio from the PLAYER to USB as it requests it. BAD: 2 CLOCKS FIGHTING!
The problem here is there no “flow control” – I describe this more here: What’s wrong with UPnP? (or read Brian’s post above).
RAAT/OpenHome/UPnP:
[PLAYER] ---- [STREAMER with internal clocking crystal]
STREAMER pulls audio using it’s own clock, PLAYER pushes it out on-demand.
[PLAYER] ---- [STREAMER connected to USB device that has its own clocking crystal]
USB device pulls audio from STREAMER using its own clock, STREAMER requests it from PLAYER on-demand, PLAYER pushes it out on-demand
RAAT:
[PLAYER] ---- [STREAMER with internal clocking crystal]
Signal Chain shows anything going on inside STREAMER
[PLAYER] ---- [STREAMER connected to USB device that has its own clocking crystal]
Signal Chain shows anything going on inside STREAMER, AND exposes any information about the USB endpoint if it is a Roon Certified USB Device.
Now, you may have noticed that in the above, I never mentioned a DAC chip or S/PDIF – this is because both use a clocking crystal, and the problem here is the impedance mismatch between the 2 clocks, not what is done with the data on those clocks. This dual clock issue is the core problem with clocking… two clocks will never align and allowing for 1 clock on the entire system will never introduce hacks to fix this problem (see above link).