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

[Mohmm]

I also think there's nothing wrong with AIR (ok, apart from some of the reliability issues).

Hi

I am not sure of this statement...

There has been a lot of "uncertainties" about "who" achieves track decoding (making an audio flux with clock signals from the tracks)' for Devialet AIR:
- the computer
or
- Devialet

On the 2 years old Devialet White Paper, it seemed that it was Devialet, AIR transmitting track files (as in UPNP Linn, or Lumin or Ayon streamers) and not an audio flux.

Looking at the current Devialet website and as Jriver or Audivarna can be used, it seems now clear that it is the computer that achieves track decoding, transmitting an audio flux to Devialet.

When doing track decoding on a computer, it is only a first view to say that the clock (hard or software) of the computer is no longer used when the receiver clock masters the process.
In any audio flux protocol, you have to share a "time definition" between emitter and transmitter. And even if it is an atomic clock that drives the process, the computer side clock is still involved and has to be able to "obey" to the main clock.

In my opinion, Devialet streaming could and should have been done with tracks and not with audio flux. Computer software and hardware clocks, general purpose Operating Systems as Windows or OSX, decoding softwares, etc., have difficulties to compete with dedicated chips, clocks and software.
In my opinion, a redesign of AIR protocol (transmitting files and no audio flux) and the addition of a dedicated chip inside the Devialet to decode the tracks, may be the only way to really improve the digital part of Devialet (apart from buying an additional drive), keeping the computer in the role of file server, with 0 audio function.

The possibility of dramatically improve Devialet with a d1-server comes (in my opinion) from this design approach weakness.

d1-server really solves these issues with:
- Linux Real Time as Operating System inside a Cubox
- dedicated power supply to Cubox
- shielding the Cubox
- building any audio flux inside a FPGA with a proprietary Clock (and proprietary algorithms), the Cubox clock being not used at all
- recklocking in the FPGA before any audio flux manipulation and creation.

These principles are also used in Totaldac DACs, solving nearly all the usual issues of SPDIF, AES and USB.

In my opinion, d1-server uses the "state of the art" technologies and design (also much ahead of any Aurender that I tested).
Drives as Auralic Aries or 3DLab Nano, at a much lower price, could be good competitors to d1-server, as they use the same kind of design and ideas.
Only direct comparisons will allow conclusions. I should have an Aries for a review in a week or two...

Thanks, Thierry, for this contribution as it is the first post that lets me see a reason for using an external "server" be it called d1 or other, or an external renderer together with a Devialet. (Calling the d1 a server sounds a bit exaggerated as it lacks any storage device and is basically a half empty box.)

Basically it is hard to understand why one would want to complicate the signal path with a machine like the Devialet. Originally the D can do all the streaming together with AIR. AFAI understand, however, Thierry's explanation indicates that the Dev company has not solved a clocking problem that totaldac is able to solve (the "audio flux" vs. "track decoding").

But there are two ways of bringing a signal to the Devialet:
(1) streaming via AIR and ethernet or wirelessly through a (dedicated or not) network (this is the setup where totaldac and other renderers come into play); or
(2) feeding the digital signal directly from a Mac via firewire, AES/EBU, SPDIF, (or via USB, if you rely on a PC).

I would like to know, Thierry, if the problem you mention applies only to the number (1) way of streaming the music via a network or if it applies also to case number (2)?

I use both, (1) and (2), alternatingly but find (2) marginally better than (1) with ethernet.