+- 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 - Jwg1749 - 31-Aug-2014
I like the fact that this thread has become a bit controversial but has remained polite and calm.
Please keep it going, chaps!
Matt
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - ThierryNK - 31-Aug-2014
Arffff
you are going to make me lie about stopping about this subject. Computer clock is the only one used for building the data by a software running on a computer, and all issues of non real time operating systems and of software not written close enough to hardware happen.
External clock is the one that decides and "asks" what audio samples are to be sent and is also responsible for timing the transfer.
The "issue" comes from the interaction between "building the data" which is entirely done by the computer, and "transferring the data" which is mastered by the external clock.
Here is a paper by Damien Plisson, the father of Audivarna, that provides some "flavor" of what happens at the computer level, which is independent of any external clock.
http://www.amr-audio.co.uk/large_image/MAC%20OSX%20audio%20players%20&%20Integer%20Mode.pdf
Cheers
Thierry
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Confused - 31-Aug-2014
(31-Aug-2014, 22:15)Jwg1749 Wrote: I like the fact that this thread has become a bit controversial but has remained polite and calm.
Please keep it going, chaps!
Matt
Alternatively, everyone could meet up at the Guilford Audio "Devialet Workshop" in October, and then have a massive scrap in the car park! Joking aside, I agree that the fact that this forum remains civilised is a real plus, and perhaps says something about Devialet owners.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - thumb5 - 31-Aug-2014
Hello Thierry,
I understand about the two different clock domains. My hypothesis is that the buffer in the Devialet means that when streaming via AIR, the two clock domains are almost entirely de-coupled and therefore don't suffer from the issues that you refer to.
In other words, the "building the data" part doesn't depend on having a good clock, provided the computer can read and decode the audio file to generate the output samples quickly enough. That's a matter of throughput rather than clock accuracy. I'm assuming we're talking about streaming from an audio file, with a codec that's just a deterministic, algorithmic process - so given the same input data it would produce the same output data whether or not it's run in real time. Another way of thinking of it is that instead of running the codec you could simply have a file full of already-decoded audio samples. The bits would be the same irrespective of how and when they were generated.
I know some might argue that's not the case, but I hold the point of view that if the computer runs correctly it will always decode a given audio file to the same bits (assuming the codec is deterministic). Maybe that's where we should agree to differ?
Also, I believe transferring the data between the computer and the Devialet via AIR is not critically time-sensitive. Because of the buffer in the Devialet, the computer can deliver the data at roughly the right overall rate and there should be no difference in end result provided all the data arrive and the buffer doesn't over- or under-flow. In practice this must be the case because AIR is implemented using a mechanism (UDP) that may drop packets even when running over wired Ethernet. This means that packets may need to be re-sent if they're "lost" in transit, which could give quite large timing variations in delivery of audio samples to the Devialet. Nevertheless the buffer means that such timing variations aren't important provided the packets reach it before they're needed.
It seems to me the only part that is critically-dependent on a good clock is the transfer of data from the buffer to the Devialet's audio system. And of course that's all controlled by clocks internal to the Devialet.
Cheers,
Ian
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - ThierryNK - 01-Sep-2014
(31-Aug-2014, 23:42)thumb5 Wrote: …
Another way of thinking of it is that instead of running the codec you could simply have a file full of already-decoded audio samples. The bits would be the same irrespective of how and when they were generated.
I know some might argue that's not the case, but I hold the point of view that if the computer runs correctly it will always decode a given audio file to the same bits (assuming the codec is deterministic). Maybe that's where we should agree to differ?
...
Hi Ian
Yes, that is the key point (IMHO).
I assume, as you do, that transfer is "perfect".
As we all get differences (from tiny to huge) according to Operating System, Player Software, both on audio gear as Devialet, but also with USB DAC, we have to accept the fact that the data and the bits are NOT the same in the receiver buffer depending on software and operating system.
As I mentioned before and as you do, there is a unique way to decode the tracks.
If you put all together:
- a unique way of decoding tracks
- perfect transfer
- important differences depending on OS and software (everything being the same for everything else), leading to the fact that data are not the same at the arrival
I think that a simple logic leads to the fact that something is "scr**ed" during the track decoding on the computer.
Some of the probable causes of these difficulties are mentioned in Damien Plisson paper (link given above). I did not want to write this word, because it is so used… Software induced Jitter (see Damien Plisson paper, and it only speaks about few elements, there are many others).
If we admit this, this explains improvements with d1-server on Devialet, and it explains that "network players" with no audio flux transfers are always better than a Computer-DAC with the same DAC as the network player.
Cheers
Thierry
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Eddye - 01-Sep-2014
Very nice read. Would both of you (Guillaume and Rufus) rather listen to the MiND or the ARIES?
I couldn't justify buying a D1.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - patcam - 01-Sep-2014
For the MIND 180
Guillaume or Rufus, can you indicate if you used the Moon MIND 180 power supply or an advanced one ?
I have heard that the Moon is not so good
Thanks
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - Rufus McDufus - 01-Sep-2014
Personally as of now I'd rather listen to the Moon MiND. The development of the MiND firmware-wise has been a little slow though and I suspect the Aries has more potential on that front. The Aries is more impressive to me - bigger soundstage, depth, but just a bit flat dynamically (to me anyhow). We'll try it with a good USB cable in the next few days - could be very different...
patcam - we were told at one point that Simaudio would bring out an improved power supply but this seems to have fallen by the wayside. I understand there are one or two third-party linear PSUs available but you have to be wary! The PSU with the MiND, even though it looks like a wall-wart SMPS, is apparently a linear power supply and is maybe not as bad as people might think.
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - GuillaumeB - 01-Sep-2014
(01-Sep-2014, 18:07)patcam Wrote: For the MIND 180
Guillaume or Rufus, can you indicate if you used the Moon MIND 180 power supply or an advanced one ?
I have heard that the Moon is not so good
Thanks
Yes we used the standard Moon power supply.
According to the distributor for Simaudio in the UK - Renaissance Audio (and I am quoting this from an email): "The PSU that comes with the unit is not pretty but works very well as it has good voltage regulation." It actually looks like one of those cheap wall warts.
There were some rumours last year of an updated power supply for the MiND 180 but these never materialised.
Having said all this the MiND 180 is a decent piece of kit, and one that I've enjoyed owning for the past year or so. In our tests last Friday it performed surprisingly well and above the Aries (although it lacked in some of the Aries' top end detail and expansive soundstage). The end result is however quite dependent on having a decent AES/EBU cable - Rufus and I tried a few with varying results.
My biggest gripe with the MiND however is the control point software which has been stuck in some kind of time warp and had very few updates. Since it doesn't use the same UPnP extensions as Linn's OpenHome it isn't so easy to use Kinsky instead (although PlugPlayer worked fine with some limited functionality).
Guillaume
RE: Mac AIR v MiND 180 v Auralic ARIES v totaldac d1 server - GuillaumeB - 01-Sep-2014
(31-Aug-2014, 22:15)Jwg1749 Wrote: I like the fact that this thread has become a bit controversial but has remained polite and calm.
Please keep it going, chaps!
Matt
I agree and I must say I have been most impressed by the quality of the debate in here
I was literally watching this thread like a hawk at one point ready to pounce!
Little did I need worry. Top class debate.Guillaume