Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server
#51
(31-Aug-2014, 19:55)ThierryNK Wrote: 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. Smile
PS Audio P3, Shunyata ΞTRON Alpha Digital and HC/Furutech power cables, Paul Hynes SR7EHD-MR4, DIY Roon Server & Roon Endpoint running AudioLinux Headless, Phasure Lush^2 USB cable, Audioquest Diamond RJ/E ethernet, Uptone Audio etherREGEN, Mutec MC-3+ USB, Shunyata ΞTRON Anaconda Digital XLR AES/EBU, Devialet Expert 250 Pro CI, Nordost Tyr Reference LS cables, Von Schweikert VR-5 SE Anniversary Edition, Anti-Mode Dual Core 2.0, JL Audio Fathom F112. More detail here.

The Netherlands
Reply


Messages In This Thread
CuBox - by Kunter - 31-Aug-2014, 13:49
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - by Antoine - 31-Aug-2014, 20:21

Forum Jump:


Users browsing this thread: 5 Guest(s)