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

[thumb5]

I know nothing about digital transmission but it seems to me that you surely do not build a system which collapses entirely if it fails to transmit 100% of the data 100% of the time. And at 16/44.1, there are 7 million alternative codings per second, rising to 3.5 billion at 24/96. So if the odd few are wrong, you surely do not want a system which shuts down. There must be some tolerance/redundancy in there somewhere.

This would normally be handled by an error detection and correction mechanism. For example, errors can be detected by a CRC or checksum generated by the transmitter (computer running AIR) and checked by the receiver (firmware on the Devialet).

There are various ways to handle the case when an error is detected, the most obvious being either to discard it, or to arrange for it to be re-transmitted. In a typical communication protocol stack this error detection and correction can be handled at multiple levels, possibly using different approaches in different levels.

In the specific case of AIR, apart from the error detection done at the network hardware level, which would result in faulty packets being dropped, it looks as though the audio payload is protected by a CRC. Although I haven't seen it happen, I expect the AIR protocol running on the host will re-send packets that the Devialet hasn't acknowledged successful receipt, either because they're dropped in the network or because of faulty CRC (the latter case probably being much less likely). At least, up to a point where it decides that things just aren't working at all and gives up.

So I doubt AIR is really 100% bit perfect.

I don't think the fact that the AIR protocol has to be tolerant of errors necessarily prevents it from being bit perfect. Since the Devialet has quite a large buffer memory into which the data is streamed, it has time to run an error correction process before the samples have to be clocked out of the buffer and into the audio pipeline.

In principle it's not a fundamentally different problem to recovering data from a spinning disc drive, or transferring a file across the internet, both of which you would expect to be 100% bit perfect of course. The error detection mechanisms are similar but the correction mechanisms vary because of different time constraints and impact of failure.

This is in contrast to clocking data directly into a DAC or streaming via isochronous USB, where - as far as I know - if errors are detected, there is no mechanism to correct them other than by re-transmission, and there's no time to do that.