Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server

[thumb5]

If clocking is the main reason for the difference in sound between AIR and Totaldac AES/EBU and both mechanisms provide bit-perfect data to the DAC then the implication is that Devialet's buffering and re-clocking of AIR-transported data is sub-optimal. If so, I'm very surprised that Devialet would have made that compromise given that AIR is one of their flagship technologies. And it sounds pretty good to me anyway

One key difference between AIR and AES/EBU (as I understand it, please correct me if I'm wrong) is that with AES/EBU, the source (e.g. Totaldac d1) encodes the data stream using its own clock and the Devialet has to extract the clock from the data stream. I'd assume it then has to either drive its own audio playback pipeline completely from the recovered clock, or somehow re-clock/re-sample the data to synchronise it with its own internally-generated clock. For what it's worth, my guess is the latter case. Although the two clocks should of course be nominally running at the same rate, over a long-enough time they will necessarily drift because neither of them can be completely accurate/stable. This clock synchronisation process might introduce subtle changes to the data stream - who knows?

Another factor is that the AES/EBU interface has limited error detection but essentially no mechanism for error correction. These AES/EBU guidelines suggest in section 3.8 that a DAC detecting errors in an AES/EBU input stream should handle them by interpolating between valid samples, or by muting its output. Needless to say, neither of these can be considered "bit perfect" activities. I've also seen this referred to as "error concealment" rather than error correction.

With AIR, by contrast, the Devialet can correct errors in incoming data (by having the host computer retransmit them) and it can clock samples out of the AIR buffer into its audio pipeline using its own internal clock. There is no need for clock recovery because the incoming sample data are implicitly delivered at the Devialet's own internal clock frequency. There is a closed-loop feedback mechanism between the Devialet and the host to handle small differences between the rate at which the host generates samples and the rate at which the Devialet plays them, hence there should be no need for the Devialet to re-sample for clock synchronisation.

It's no stretch of the imagination for me to believe that the complete path from the input of AIR (output from iTunes, Audirvana, etc.) through to the point where samples get into the Devialet's audio pipeline (i.e. start following the exact same path as input from USB, AES/EBU, etc.) can be completely error-free - bit-perfect, if you prefer.

So it seems to me that there are grounds for considering AIR to be a technically optimal solution to the streaming problem.

As always, subjective judgements of sound quality can and should continue independent of the technical discussion...