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

[Antoine]

Hi

@Antoine (and others...)

Of course, I do not know the details of AIR. Maybe Devialet has found a way to get rid of a mandatory clock on the emitter side.

In any current and known audio protocol using computers, an external clock cannot handle the processor, the Operating System, Ethernet, software, etc. needs for a clock.

As I said above, the external clock masters the transfer process with a "time definition" that goes though the same media as data, in the opposite way, but it cannot master the needed clock for Audivarna, iTunes or Jriver, the Operating System, etc.

This is explained here:

http://www.edn.com/design/consumer/43761...-USB-Audio

for asynchronous USB by Principal Technologist at Xmos.

Among others, the important words, in my opinion, in this article are In order to ensure that the host sends the right amount of data, and not too much or too little...

In my opinion, the fact that this about USB does not make it less relevant for any audio flux transfer protocol.

If the emitter clock was not involved, you should not get any difference between Audivarna/iTunes/Jriver and different Operating Systems.

I apologize for being a bit harsh about those subjects: asynchronous and external clock being the magic bullet for computer audio is, in my opinion, not true. It may improve result, but marketing does not say the whole technical truth about it.

Cheers
Thierry

Hi Thierry, with this I fully agree. Of course there is a dependance on the computer clock for the data transfer process but this is a different process than the process of the 'stream reconstruction' (buffering, upsampling, reclocking etc.).

There's also a clock module on the AIR interface card that probably drives the processor and memory of this AIR interface. As I see it this card is solely responsible for collecting the 'music stream data' served by the WiFi/ethernet module and getting it ready to feed it to the DSP of the Devialet that further handles that data in the same way it does for coax/optical inputs (upsampling, reclocking, SAM etc.) There's probably a separate clock for the WiFi and ethernet hardware as well, which of course have their own functions in offloading the OSI layer 1 to 4 physical, ethernet, IP and UDP protocol duties from a 'main processor' inside the Devialet.

I think there's a big mystery why different OS's, media players etc. influence sound (if and when they do) in asynchronous playback systems.

It is generally known that the makers of JRiver say it all doesn't matter as long as the data is kept 'bit perfect'. They are very clear and open in stating that an "add-on" like JPlay can't make any difference. The truth is out there but I for sure am not sure what that/the exact truth is.

[GuillaumeB]

Just to get back to the subject of this thread Rufus and I will be having a part 2 on Saturday next week. Essentially we want to give the ARIES a second chance. We also want to try using it with a USB cable.

Guillaume

[Confused]

Good point Mr G, this PC optimising AIR debate is very interesting, but there are other slots on this forum, more appropriate for the topic. Keep up the good work and feedback with your back to back testing, although I am concerned that it might start sending you slightly insane ......

[ThierryNK]

Hi again

If you try a "cold blood analysis"...

Same hardware (Devialet, computer, cables etc...)

- There is a strictly unique way of making an audio flux from an audio track

- if you get different results when changing the player (iTunes/Jriver/Audivarna/Pure Music/ Amarra) then the data in the Devialet buffer are not the same depending of the player (electrical interferences are supposed to be the same, as cables, hardware, etc. are the same).

End of cold blood

The fact that you still get sound when disconnecting the computer is not really a "proof", it only demonstrates that there is a buffer, it does not proof that the data inside the buffer are the "right"ones. It is the same with USB and USB DAC that have a buffer.

Cheers
Thierry

[Antoine]

I'm really not daring to go there in explaining why (or if) different bit-perfect players (can) sound different. I've seen too many discussions on this topic ending bad on different fora/forums.

Regarding the disconnecting of the computer and continued playback; it is merely proof that the computer's clock is not needed for playback and thus it is an asynchronous system.

[ThierryNK]

Computer clock "was" needed to build what "is" in the buffer (because a computer and a software need a clock) and is listened to when computer is disconnected.

But you are right, I will stop here on this subject as there are enough information on this discussion thread for each one to make the difference between marketing and reality.

Cheers
Thierry

[thumb5]

Possibly repeating/paraphrasing what Antoine has already said, but…the Devialet seems to be entirely responsible for clocking the data received from the network interface through its audio pipeline. Based on what I can see by poking around in the AIR network packets, the Devialet sends explicit feedback to the computer allowing it to work out whether it needs to send samples at a higher or lower rate. Since the buffer is large, as Antoine noted, this doesn't have to be a particularly tight or accurate feedback loop - all it has to do is stop the buffer overflowing or underflowing. So the audio pipeline in the Devialet should be completely de-coupled from any clocks in the computer.

(Having spent the last few weeks writing software to implement an asynchronous USB audio device with rate adaptation and implicit feedback, this is a subject close to my heart and I can see that in some ways the Devialet AIR solution is simpler and more elegant.)

---

Guillaume and Rufus - you must be exhausted after all that listening! A very interesting comparison, and thanks for taking the time to share your results. Looking forward to see how the Aries fares in its re-match!

[Confused]

Some interesting posts, but isn't this a little off the topic of the thread, that is, something like the Totaldac can run through SPDIF or XLR hence bypassing whatever AIR might be doing. So the D1 might very well be doing much the same as AIR but possibly doing it fractionally better. Hence the reports of it sounding better. In costs a fair percentage of an entire Devialet integrated, so there is reason to think it might be able perform slightly better in some aspects, say clocking accuracy?

For me, I'd like to hear one, that's the only way I could form a firm view.

[thumb5]

Confused - yes, I agree, a bit off topic. I suppose the main point of my post was to say that whatever the sound quality of AIR depends on, I doubt that the quality of any clock(s) in the computer has any bearing on it.

[PhilP]

Hi Thierry,

I enjoy your posts and find them very thought provoking.

- if you get different results when changing the player (iTunes/Jriver/Audivarna/Pure Music/ Amarra) then the data in the Devialet buffer are not the same depending of the player (electrical interferences are supposed to be the same, as cables, hardware, etc. are the same).

Perhaps these software players are changing the signal before it is fed into AIR which as Antoine says is acting as a virtual sound card.

As I've said elsewhere, it's not clear to me what a player like Audirvana+ is really doing when it is functioning with AIR. I would have expected that the AIR developers would have taken every opportunity to optimise performance in a similar fashion to Audirvana. So I'm not sure what Audirvana really adds?

---

Confused - yes, I agree, a bit off topic. I suppose the main point of my post was to say that whatever the sound quality of AIR depends on, I doubt that the quality of any clock(s) in the computer has any bearing on it.

particularly when using AIR WiFi...