+- Devialet Chat (https://devialetchat.com)
+-- Forum: Devialet Chat (https://devialetchat.com/Forum-Devialet-Chat)
+--- Forum: Streaming (https://devialetchat.com/Forum-Streaming)
+--- Thread: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server (/Thread-Mac-AIR-v-MiND-180-v-Auralic-ARIES-v-totaldac-d1-server)
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - philoouu - 09-Sep-2014
(08-Sep-2014, 22:17)PhilP Wrote: Ok, I tried to understand the post on the French forum which explains how AIR works (according to a Devialet engineer). I used Google translate but as is often the case the output is not always perfect Englishso I made some changes. My French is certainly not perfect ...
"AIR transmits stored data and not a digital audio stream...
AIR transmits only the audio portion of digital audio files removing metadata, data length, and associated files. It sends only one format of file (presumably WAV - my comment). The computer decompresses compressed formats and transcodes as necessary.. The file is then transmitted in packets with a buffer at the start and the finish, speed controlled by the Devialet. AIR works only with bi-directional connections with flow control and the ability to re-issue a lost frame." For them (Devialet) 'bit exact' is to find all of the information stored in the audio file.
There's then a discussion about how if AIR is bit-perfect then no other way to transmit an audio file can be more bit-perfect. Hence philloouu's comment about no need for a Totaldac.
As I said before, I think the Totaldac is still very interesting if you want to use a steamer rather than a computer source and Guillaume and Rufus clearly preferred it using AES/EBU to AIR so I don't think we have the whole story yet
Philip
Hi Philip
Thanks for your comments.
- Many people think that the sound with Totaldac is better
- Many people see differences with Air using different softwares
This is strange if we think that Devialet is taking care of everything once the file is in wave format...
So for me the discussion is not closed yet... and most probably nobody is wrong.
Regarding of rather using a NAS than a computer, I think this is not really different as a NAS is a computer and in both case you can control everyhing with a tablet/phone.
Rgds
philoouu
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Confused - 09-Sep-2014
I don't see any conflict between the notion that AIR is bit 100% perfect and Guillaume and Rufus finding sound quality benefits with the Totaldac. I think the key point here is that the Totaldac works best with AES/EBU, when it is replacing the clocking functions as performed by the Devialets asynchronous DAC. Via AIR / USB the Devialet takes over the clocking function. So the logical conclusion would be that the Totaldac's clocking ability is superior to AIR, and hence demonstrates sound quality benefits via AES/EBU or maybe SPDIF. Via USB, this benefit is lost.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - IanG-UK - 09-Sep-2014
As with "Confused", I don't see any practical conflict either, between the technical claim that AIR is measurably 100% bit perfect and the listening claim that Totaldac sounds better than AIR.
But in the overall scheme of things, here is a minor section of the audio chain (code on a CD moving to an analogue output from a DAC) preceded by, at the start, the recorded musical event, which none of us has ever heard, and concluded with the reproduced musical event, in a flawed and different listening environment with flawed loudspeakers and (probably) far from perfect and different ears.
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. So I doubt AIR is really 100% bit perfect.
Likewise I know nothing about human hearing apart from knowing it is fragile, inconsistent and not wholly reliable. So if two guys prefer "a" to "b" on certain music at a certain time with certain peripheral kit and listening room, that tells us simply that.
Where I differ a bit with "Confused" is his conclusion that the Totaldac clocking ability is superior to AIR. Surely it is just audibly different to two individuals' sets of ears in a way which pleases them!
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Confused - 09-Sep-2014
(09-Sep-2014, 12:41)IanG-UK Wrote: Where I differ a bit with "Confused" is his conclusion that the Totaldac clocking ability is superior to AIR. Surely it is just audibly different to two individuals' sets of ears in a way which pleases them!
Actually I would have to stick with a conclusion that the Totaldac may have superior clocking ability. The fact is I have never listened to a Totaldac D1, and hearing is believing for me. However, looking a some of Guillaume's and Rufus' previous posts, it is clear that they think that they are hearing a most definate improvement, i.e. they sound like they are a little beyond the subjective range. As I mentioned, I would need to hear one myself before stating anything more than a tentative "may have".
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - thumb5 - 09-Sep-2014
(09-Sep-2014, 12:41)IanG-UK Wrote: 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.
(09-Sep-2014, 12:41)IanG-UK Wrote: 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.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Rufus McDufus - 09-Sep-2014
Also where does the "bit perfect" claim refer to, the output of AIR or at the Devialet end? It'd be a brave claim to make that ticking "bit perfect" ensures perfect bits at the Devialet 100% of the time in all situations. In a normally functioning network I suspect, much like the disk drive analogy, there will be errors but at a level so small as to be insignificant, errors that could occur at several layers of the protocol stack. The network performs to a "good enough" level of performance error-wise and I'd be surprised if the network when functioning normally could give rise to significant differences in sound quality, unless there's other factors such as electrical effects in the physical layer.
Superior clocking sounds like a plausible explanation for all or most of the difference but it'd be great to have a definitive answer. Thumb5's work on reverse-engineering the AIR protocols is really worthwhile and will really help understand. I've been looking at comparing packet streams from two separate source players (I.e jRiver or say, VLC) to determine whether the packet checksums really are identical or not.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - PhilP - 09-Sep-2014
Given the description of the way AIR works and the fact the data are transmitted via TCP/IP I would be very surprised if the data sent from the buffer in the Devialet to the DAC are not bit perfect. But I don't think we should get too hung up on the bit perfect point as that may well not be why AIR sounds different to the Totaldac.
People have reported hearing differences between ethernet cables even in situations where router logs have shown zero packet errors and zero discards so the reason for the differences is not in the data. Many have suggested that the cause is probably the ethernet cable introducing RF interference into the receiving device. It's likely that different cables and devices in heterogeneous environments interact in different ways which is possibly why some people hear differences between cables in their systems and others don't. The ideal would be to stop/reduce the RFI getting into the receiving device and this can be done using shielded cable or ferrite beads or go to the extreme lengths that Totaldac have done with their ethernet cable.
RFI could also get into a device via its Wi-Fi antennae so even that method is not immune.
Oops sorry I have to stop there as I'm late for an apptmt.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - f1eng - 09-Sep-2014
(09-Sep-2014, 08:40)Confused Wrote: I don't see any conflict between the notion that AIR is bit 100% perfect and Guillaume and Rufus finding sound quality benefits with the Totaldac. I think the key point here is that the Totaldac works best with AES/EBU, when it is replacing the clocking functions as performed by the Devialets asynchronous DAC. Via AIR / USB the Devialet takes over the clocking function. So the logical conclusion would be that the Totaldac's clocking ability is superior to AIR, and hence demonstrates sound quality benefits via AES/EBU or maybe SPDIF. Via USB, this benefit is lost.
Well put. That is the most plausible explanation I can think of too.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - PhilP - 09-Sep-2014
(09-Sep-2014, 17:53)f1eng Wrote:(09-Sep-2014, 08:40)Confused Wrote: I don't see any conflict between the notion that AIR is bit 100% perfect and Guillaume and Rufus finding sound quality benefits with the Totaldac. I think the key point here is that the Totaldac works best with AES/EBU, when it is replacing the clocking functions as performed by the Devialets asynchronous DAC. Via AIR / USB the Devialet takes over the clocking function. So the logical conclusion would be that the Totaldac's clocking ability is superior to AIR, and hence demonstrates sound quality benefits via AES/EBU or maybe SPDIF. Via USB, this benefit is lost.
Well put. That is the most plausible explanation I can think of too.
I wouldn't disagree though other factors obviously impact the sound via both routes including, as I mentioned above, RFI interference.
I only got part way though my previous post. I was going to go through all the possible sources of differences in sound but had to run of to a meeting. I didn't mean to imply that cables were the main source of the difference in sound - just that they are one factor to be considered.
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
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Confused - 09-Sep-2014
(09-Sep-2014, 17:53)f1eng Wrote: Well put. That is the most plausible explanation I can think of too.
You sure it might not be the cables Frank?
