(02-Oct-2014, 10:57)GuillaumeB Wrote: [ -> ] (02-Oct-2014, 09:54)smokejumper Wrote: [ -> ]After Kunter's comments I am now trying an Audioquest Diamond ethernet cable. No going back is correct, huge improvement from Vodka
It's an excellent cable and it seems that most who try it agree. Another cable also worth trying is the TotalDac one:
http://www.totaldac.com/ethernet_cable-eng.htm
At 390 euros for 2M it's quite a bit cheaper than the Diamond and to my ears certainly equal in performance. It has quite a unique construction and is very different from anything else on the market: it has a massive choke comprising of dozens of ferrite rings, these supposedly act as a low pass filter.
I've also got a couple of Sablon ethernet cables here to try and will report back once I get a chance.
Guillaume
Can't wait to hear from you about your thoughts of the Sablon ethernet cables vs Audioquest Diamonds
I have tested the following configurations:
1) Macbook -> WiFi -> Airport using Apple Airplay -> SPDIF -> Devialet
2) Macbook -> WiFi -> Airport -> WiFi -> Devialet using Air
3) Macbook -> WiFi -> Airport -> Powerline (Eth over power) -> an other Airport using Apple Airplay -> SPDIF -> Devialet
4) Macbook -> Ethernet -> Devialet using Air
5) Macbook -> WiFi -> Airport -> Powerline -> an other Airport creating a 1m long dedicated WiFi Exclusively for the Devialet -> WiFi -> Devialet using Air
6) Macbook -> WiFi -> Airport -> Powerline -> Ethernet -> Devialet using Air
configurations 1) and 3) were sounding identical between each other but were having a spatial resolution and stability slightly inferior to 2), 4), 5) and 6)
2), 4), 5) and 6) were undisguishable to my ear and therefore I settled on 6).
I should probably mention that I'm using iTunes as my player and I'm using probably 98% of 44.1KHz 16 bits ALAC either ripped from my CDs or bought from Qobuz and 2% of 'High Res' files.
Also to mention that the difference of spatialization was perceptible mostly on classical music played by large symphonic orchestras and much less on smaller formations or Jazz or Variety.
I can't change my vote, but if I could I would change it now from 'Computer via AIR/Ethernet' to 'Computer via USB'.
I have no idea how these things work or, indeed, if there is an sound difference with a technical correlation, but one starting point would be to know whether there are any technical bases as to why these things might sound different.
Clearly there is a limitation on consistency of source output even if that is described simply as CD storage or computer storage (ignoring any necessary or optional intermediate kit aside from the cable); but if we look at the Devialet inputs there are (or have been) 8 digital possibilities as far as I know:
1. Wireless AIR
2. Ethernet RJ45 AIR
3. USB
4. Optical Toslink
5. Optical Toslink mini
6. RCA S/PDIF
7. XLR AES/EBU
8. HDMI
Are there any technical reasons why, at the Devialet socket, these should be different?
(16-Oct-2014, 16:45)IanG-UK Wrote: [ -> ]1. Wireless AIR
2. Ethernet RJ45 AIR
3. USB
4. Optical Toslink
5. Optical Toslink mini
6. RCA S/PDIF
7. XLR AES/EBU
8. HDMI
Are there any technical reasons why, at the Devialet socket, these should be different?
Yes.
It depends on who controls the flow of data and hence the clocking. Also the input's ability to reject errors also needs to be taken into account - and I guess if that input injects electrical noise into the Dev' then will sound worse.
Inputs 4..8 are 'push' inputs and will be clocked by the source (CD player, TV, PC etc) so will be completely dependent on the quality of clock provided by that source - Garbage In, Garbage Out etc. If you had a fantastic CD player then you would hope to get excellent results (Also jitter will be source dependent).
Inputs 1..3 (USB only if Async drivers) are 'pull' inputs. The Dev's will decide when it wants the next chunk of input and is probably buffering internally. There is scope and input errors to be re-read[1] and all clocking / jitter will be handled by the Dev'. There is an argument that AIR over Wi-Fi may sound slightly worse as it requires a Wi-Fi chipset to be enabled within the Dev' but they no doubt have this will isolated.
All other things being equal I would expect that USB is the 'best' input but it is very difficult to construct a valid ABX test to prove this.
Rik - but what do I know..
[1] The Dev' uses 'unreliable' UDP/IP for audio input BUT has a X.25 like sliding windows to allow it to correct for any errors. So this will (or SHOULD) not be a problem.
(16-Oct-2014, 17:00)rik Wrote: [ -> ]Yes.
It depends on who controls the flow of data and hence the clocking. Also the input's ability to reject errors also needs to be taken into account - and I guess if that input injects electrical noise into the Dev' then will sound worse.
Inputs 4..8 are 'push' inputs and will be clocked by the source (CD player, TV, PC etc) so will be completely dependent on the quality of clock provided by that source - Garbage In, Garbage Out etc. If you had a fantastic CD player then you would hope to get excellent results (Also jitter will be source dependent).
Inputs 1..3 (USB only if Async drivers) are 'pull' inputs. The Dev's will decide when it wants the next chunk of input and is probably buffering internally. There is scope and input errors to be re-read[1] and all clocking / jitter will be handled by the Dev'. There is an argument that AIR over Wi-Fi may sound slightly worse as it requires a Wi-Fi chipset to be enabled within the Dev' but they no doubt have this will isolated.
All other things being equal I would expect that USB is the 'best' input but it is very difficult to construct a valid ABX test to prove this.
Rik - but what do I know..
[1] The Dev' uses 'unreliable' UDP/IP for audio input BUT has a X.25 like sliding windows to allow it to correct for any errors. So this will (or SHOULD) not be a problem.
Thank you very much - I feel better informed and my choices are much reduced which is great
(16-Oct-2014, 17:00)rik Wrote: [ -> ]All other things being equal I would expect that USB is the 'best' input but it is very difficult to construct a valid ABX test to prove this.
Why (in theory) should USB be superior to Ethernet AIR? By the way, this is a genuine question, myself, I have no idea one way or the other with respect to this specific point.
(16-Oct-2014, 14:20)Antoine Wrote: [ -> ]I can't change my vote, but if I could I would change it now from 'Computer via AIR/Ethernet' to 'Computer via USB'.
I second that, I think USB from PC with Jplay is superior to Air—Air do not work so well with Jplay on my system with 24/96 music.
Kind regards Morten
The fast that Dev' appear to be having issues with White noise on the PC & OS incompatibility under OS-X makes me think that the protocol isn't bullet proof. Which could lead to data loss, which would be a loss of quality!
As the protocol isn't open I can't investigate this which means I can only take someone else's word as to how well it is implemented.
However as AIR is a protocol with a lot of buffering (Which we know from it's configuration) it may be better than Async USB (Which work's rather like the sync-link Linn used for their Numerik i.e. no clock signals just a 'go a bit faster / slower' message to stop a buffer emptying or filling up.).
Rik
So far with my 200 I have gotten far better sound using a Halide Bridge usb to SPDIF converter which is feed by an Aqvox external power supply. I tried a couple of expensive usb cables (Cardas and AQ) and went directly to Devialet using software from site, but none came close. The difference is immediately noticeable for myself and wife. I know this adds an extra step but by getting the computer out of direct connection to the Devialet is well worth it. I notice Berkeley Audio recommends using their usb to SPDIF with the TOL set-up they have also. I have considered testing the Berkeley usb to SPDIF but have not felt the need. I hope to test one day.