Agreed about S/PDIF. I have guesses as to why they “got it wrong”, but I don’t know for sure.
Roon/RAAT are based on a pull model. I’m not sure where my explanation went wrong to cause confusion.
(Meridian’s streaming protocol is also a pull model).
For multi-zone, we run in pull mode with the zone that has been elected as clock master and push to the other zones, which are forced to compensate for drift internally.
The actual implementation is slightly indirect. The core knows how quickly to send packets to an endpoint not because of an explicit request for data, but because the core knows what time it is at the high-resolution clock that’s driving the audio stream, and it understands the intended relationship between wall time and stream time. It behaves like a soft real time system based on those time relationships + periodic synchronization with the endpoint clock.
This turns out to be much more elegant than explicit pull requests, and lets single-zone and multi-zone cases share virtually the whole implementation. There is one extra API for slave zones, which basically tells them to go sync with a clock source of the server’s choice and adjust accordingly.
(The Meridian protocol actually uses explicit “pull” requests and has explicitly different flows for single and multi-zone cases. That works too, but that protocol has about 2.5x as much surface area, a lot more chatter, and the lesser-used multi-zone paths never got enough testing and were/are a constant source of trouble.).