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

[GuillaumeB]

Hi guys,

I was wondering exactly the same as Antoine, as my computer is software optimized with Phil's solution too and, to be honest, it does sound gorgeous. Of course, that's very relative.

I may request to loan the server for 10 days and see how it goes!

BTW Guillaume, what is your experience with totaldac's USB cable?
Great idea to set up this forum, I must say I find it very enjoyable. Thank you!

Cheers,


Carlos

Cheers Carlos! Glad you are finding it fun in here!

Re the totaldac USB cable I am not using this to connect my Mac or other transport to the d1 server... Rather I have a 25cm USB cable/filter making a link between the embedded micro computer and the reclocker USB input. The "box" contains a filter which according to Vincent Brient "removes unwanted frequencies and makes a better sound." I believe totaldac also sell a 2m USB cable containing the same box.

Guillaume

[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.

[Rufus McDufus]

Regarding where the decoding is done. G & I were talking about this a few weeks ago and wondered whether this was the reason Devialet were taking so long to implement UPnP on the Devialet. If there's no onboard decoding then this would make it rather difficult to adhere to UPnP standards wouldn't it? I realise some UPnP servers (Asset I think for sure) will output a PCM stream though.

That's interesting ThierryNK - if onboard decoding was previously present and has now been dropped (or unused), I wonder why? Also it would make for quite a versatile device if onboard decoding was optional... My own guess without all the available facts is that perhaps there's been some misunderstanding along the way and onboard decoding has never been available, but then I'm usually wrong

[ThierryNK]

Hi

I do not know if on board decoding was previously present, I have the imppression that it was never on board (I only personally used a D1 during 3 weeks).

I have "indirect" confirmation by a friend who talked to Devialet people that said him that Flac/AIF/Wave etc file formats was not a question on Devialet but a question for software on the computer.

We have to be cautious with the word "PCM". It is both used for files and for flux.
A UPNP server can transcode (convert) Flac PCM "files" into Wave PCM "files" before streaming them, but a UPNP server never send an audio PCM flux with clock signals.

UPNP is based on standard tcp/ip protocol for file transfers that is generally based on a web server on the UPNP server side. This is "standard" home network or internet protocol, no audio involved at all here, all audio is done after the arrival of the (buffered) file inside the UPNP audio gear.

Cheers
Thierry

[Antoine]

I can't see a "design approach weakness". Yes, with AIR decoding is done by the computer. The Devialet is a virtual soundcard to the computer; in Windows it is recognized as 'Loudspeakers'. However the process is an asynchronous one (just as it is for many USB->SPDIF converters). The Devialet buffers the stream in a local 32MB memory chip on the AIR ('Asynchronous Intelligent Route') interface card (see: http://devialetchat.com/Thread-how-long-...80#pid1180) and from there assembles a stream, reclocks and upsamples it for output. It can also recall missing or damaged packets. So there is NO dependance on the computer clock, the computer just has to act on the follow the "send me more data to fill my buffer" commands the Devialet sends. The Devialet master clock takes care of both the streaming process and the D->A process.

The switch Devialet made from "AIR 1" to the current AIR that emulates a soundcard is that we can use all and any programs that run on a PC and use those to output sound/music through our Devialets. Instead of relying on the playback software AIR let's the OS take care of that now.

It's too bad it is a proprietary protocol so I can't really prove it with hard documented facts but as someone here has already tested/confirmed (see the same topic mentioned above) the Devialet keeps playing when the connection to the PC is disconnected until the buffer runs empty. This is proof enough for me.

---

Oh, and the USB output of the Devialet doesn't use AIR. It's an asynchonous XMOS USB interface.

---

Regarding where the decoding is done. G & I were talking about this a few weeks ago and wondered whether this was the reason Devialet were taking so long to implement UPnP on the Devialet. If there's no onboard decoding then this would make it rather difficult to adhere to UPnP standards wouldn't it? I realise some UPnP servers (Asset I think for sure) will output a PCM stream though.

That's interesting ThierryNK - if onboard decoding was previously present and has now been dropped (or unused), I wonder why? Also it would make for quite a versatile device if onboard decoding was optional... My own guess without all the available facts is that perhaps there's been some misunderstanding along the way and onboard decoding has never been available, but then I'm usually wrong

Whether we agree with it being better or not, the reason there is no uPnP is because Devialet chose not to use uPnP at the moment they made and released AIR.

No one (except Devialet and maybe some non-Devialet engineers that know what hardware is being used inside the Devialet and knows what that hardware can do) knows for sure if the hardware present in the Devialet is suited to run a UPnP media renderer 'stack'. They believed that their AIR approach is/was better, this has been confirmed many times by Devialet (although there could of course be some marketing going on as well.. )

[Kunter]

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.

I totally agree...

I just ordered a Cubox. I will try to see the overall effect of the first three items in the list compared to the full blown personal computer (a macbook pro in my case)

In theory, Devialet should be reclocking everything from the USB input (since async XMOS input stage is used) and if one manages to input "clean" usb without standard computer garbage, the result should be very good...

Computer Audiophiles who are really at it attack the USB output issue with custom USB output boards, with clean power supplies...

Lets see how this little unit will behave with proper linear supply and good shielding...

Fun little experiment...

Kunter

[ThierryNK]

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

[Confused]

@Antoine is correct, you can disconnect the Ethernet cable from the Devialet and it continues to play high quality music until the buffer runs out. Clearly during these last couple of seconds the PC is doing nothing, it is completely disconnected.

Or to quote Devilet's website:

"Devialet master clock controlling the asynchronous protocol"

[Antoine]

Computer Audiophiles who are really at it attack the USB output issue with custom USB output boards, with clean power supplies...

Yep, and also they try to strip the OS as much as possible to have the least number of active processes running as possible, optimize and prioritize audio tasks, optimize hardware power usage/timings, shield as much components as they can inside a PC, use clean filtered, multi-stage power/power supplies from linear PSU's or LiPo/LiFePO batteries etc. etc.

In other words, there is NO difference with music server manufacturers like the Aurenders, Olives, Totaldacs etc. except in those cases where they have the inhouse knowledge and resources to build their own 'purpose built' hardware like Aurender has done in the W20. Furthermore they usually use opensource software readily available to anyone.

[Rob35]

Anyone tried one of the Aurender streamers on a Devialet?