Then the question becomes - how interoperable are AES3 based bits of kit?
I am guessing the AES3 outputs will be the closest to source, more than the analog. They didn't talk much about those in the video.
That's where I'm heading.
I was rather disappointed that the Trinnov discussion focussed on Dante, while the best solution IMHO is sitting there right alongside.
HDMI, USB and Dante are complex interfaces with high data rates and complex protocols and clocking structures. They seem to me to compromise sonics.
AES3 is the opposite - it's relatively old, slow, robust, bit-perfect and simple, it's well established, and it just works.
You don't need a training course first, but I've just done a bit of a refresher as I was starting to doubt my memory.
To the best of my knowledge AES3 is a synchronous unidirectional digital audio connection that can carry one or two channels at a variety of sample rates.
The digital audio is transmitted in blocks, and the start of the block has a preamble that allows the receiver to be synchronised to the source.
The source defines the audio format being transmitted, so the receiver knows what it has to process, and the format can be changed on the fly.
Digital audio consists of audio data and audio clock, and the clock is embedded, and travels from the source to the receiver. That means the source sits unambiguously at the top of the clocking hierarchy, the timing information flows downwards throughout the system until it reaches the DACs, and everything is synchronised to the source.
It also means that the embedded clock is slightly corrupted by the audio data itself, causing jitter. It would have been simple to get round that by having a physically separate clock connection, like I2S. There were a few proprietary solutions, but they were never really standardised like AES/EBU. It took much longer than those-that-believe-everything-they-read realised, but the better DACs are now good enough at clock recovery to get over that.
The advantage of this old, flawed, imperfect architecture is that everything is synchronised to the source, which is how it ought to be.
You can use SRC if you want to, but unlike Dante, you don't have to.
Kal Rubinson put it much more succinctly at the beginning of the
Nuprime H16-AIP thread on Audiophile Style:
Yes and another point to recognize is that, to play nicely in the real world, all devices should be able to reset their sampling rates in response to that of the incoming signal.
