audiophile ethernet and USB cables

well at least Naim (kudos to them) provide a bit perfect method of testing

An on my macbook pro, in iTunes it passes the 44.1/16 bit test.

The other sample rates do not work?

also got one of the sample rates on squeezebox touch to work. at least we know there is a objective way to verify that the correct bits are being passed on to the DAC V1

OK, this thread could get loooong. 

S-i-S is really your man for this.

But in simple terms, both Asynchronous USB and TCP/IP use error correction, so the data that's sent from one end is validated at the other. Certainly many, many computers around the world use TCP/IP, so the protocol is robust. USB can have somewhat different implementations, but the term 'asynchronous' refers to how it is clocked rather than the data itself.

I haven't seen any evidence that high-quality digital cables are any better at sending noughts and ones than low quality ones (within reason). The argument in their favour is more to do with other, unwanted stuff such as RFI. It's worth remembering that these 'digital' cables are sending an electrical signal - which is by nature analogue - interpreted at the receiving end as noughts and ones. That electrical signal can generate RFI, so a better cable may reduce or eliminate that.

That's the logic, but I'm not buying personally. Unlike all-analogue systems, there's a 'break' in the path at the DAC. In other words, unlike all-analogue systems, the electricity that comes from the socket does not go in a 'stream' all the way to the speakers. In fact, the electrical signal sent to the DAC via the data cables is incredibly 'coarse' to delineate clearly between a change from nought to one or one to nought. It's only the purely analogue signal downstream of the DAC that is fed to the speakers. So IMHO, outside of clocking issues, which are another debate, anything upstream of the DAC should make no difference to the sound. Hence people use a Raspberry Pi to feed a £50k hi fi.

But opinions vary, and I respect people who can hear the difference - I just couldn't personally.

I can't answer your technical questions analogue but when I bought the Hugo I tried a few different USB cables. As you know the Hugo uses a micro B connection and there aren't any 'audiophile' micro B USB cables so I had to use an Audioquest adaptor with the demo cables. I was using a 1.5m micro USB cable that came with an Amazon Kindle as a base point. I was lent a relatively cheap Chord Silver Plus and an expensive WireWorld Platinum Silver cable by a cable dealer, after leaving a deposit. I had them for three weeks and couldn't discern any improvement with them over the 'free' Amazon Kindle micro USB cable I was using. That saved a bit of money.

Hi

There is no error checking on async transfer DACs, audio data transfer is too time critical for that, which is why it is not implemented.  Therefore I am open minded to the idea that a rubbish, or faulty USB cable could introduce issues, but draw the line myself at a well made example, and would not entertain more then £100 for one.  I see no reason why they should effect the audio quality of a DAC-V1 where an existing cable is delivering a bit-perfect result on the built in tests, yet I heard one anyway.  

On TCP/IP, I believe good quality cable is advisable to prevent the risk blips, dropouts and delays perhaps, but nothing more, and I do not 'audiophile' cables are required.  Not on my setup anyway, where my NAS is just used as a file share over TCP/IP. rather than UPnP server etc.  However, I would be highly surprised if ethernet cables made any difference to audio quality either way.

Actually I should correct what I said at the start there.  While there is means to check for errors, there is no retry option to get the correct data, for time critical reasons I mentioned.  That's where error correction comes in within the DSP in a V1 for example.  It will use maths to smooth out the error should there be one, as the original data cannot be obtained / re-sent.

One of my friends uses an audio quest ethernet cable and said it makes a audible difference and so does the Naim dealer where I live. I have heard an UQ2 wired using audio quest ethernet cable at the dealer and it sounded amazingly fantastic. 

By the way I have no relationship with audio quest.

I am open minded about all this, just want a technical understanding. 

Are you sure about that...

Analogue - an interesting question that's been debated quite a few times. I'd go and do a bit of research on digital to analogue conversion and understand how critical the clock is and what clock jitter does to the resulting analogue output. The clock design itself isolation of the clock from ground noise etc is all related to this. 

I'd still like to see a DAC design which totally isolated itself from upstream influences but this is very difficult to do. I reckon if you were to load each track into a memory buffer and when the track was loaded, disconnect the input (whether USB, Ethernet, S/PDIF) turn off the input clock to the memory buffer, then play the track, you'd be cable, transport agnostic. 

I don't understand why, even while I am an IT guy, but for instance the already mentioned audio quest cable does make an audible difference.

so I just trust my ears, Simin I guess will be able to explain why.

The only way to find out is to listen to the cables in your own system and make up your own assessment. With hifi that's the only and best way to see if it works for you.

I've posted before on this, but I know that my empirical (and repeatable) findings are worthless in the face of those who "know" that it makes no difference, or who can tell by the look of things that they don't work.

The ethernet cabling between NAS and router made a difference varying from "worthwhile" to "wow". Not imaginary by any means, so something is happening to those bits and pieces.

If I were to bet (and I don't) it'd be RFI shielding, but to be brutally honest I don't know and don't really care, just as I don't know exactly (and equally don't care) why better mains leads and plugs improve the sound (when it's just electricity isn't it guys).

I've been a member of this forum for 15 years. I've heard a number of members systems (some fantastic, some less so, admittedly) and made numerous enduring friends through it, but there's been one unifying characteristic throughout - open-mindedness and a willingness to just listen.

The degree of close-mindedness exhibited lately, in the name of skepticism (which is a good attribute) is something that has been noticeable and quite depressing.

If your referring to my comment I'm hardly being closed-minded Gary. I gave my own experience but also suggested the OP should listen and make his own mind up whether they work or not. 

Steve, you posted while I was pecking away at my keyboard and your post was exactly what I expect should be happening. My comments were aimed at others who scream "Foo", "Snake oil" etc. 

If folk listen and hear nothing then great, they've tried. If they don't because they "know" then...

And to back that up, if anyone (with an open mind) finds themselves in the west Kent area and fancies a listen, drop me a line.

Thank you.

Well I may have made a jest previously about religious relics . . .  but it was just a jest. And in all my posts on this topic, including that one, I explain what I understand to be the case for high-quality digital cables. I also explain that I have done an audition and couldn't tell the difference. I tried swapping for several days, and later tried a blind test (for as long as my wife would put up with it) and couldn't tell. There may be other reasons for that - quality of kit, electricity supply, wooden ears, other RFi - but that was my experience.

I think that explaining both sides diligently and agreeing with one, while explicitly accepting the value of the other, having tried both personally, is pretty open minded. 

Ok I found this. I think the key is in the last sentence. If there are errors then it will request for a retransmission.

It's not ideal : it means both the receiver and sender have to work harder and are under more time pressure to do so. Also there may be buffer issues if too many errors.

I guess with time critical transmission like digital audio, it helps not to have errors here in the first place.

"Short for Transmission Control Protocol/Internet Protocol, TCP/IP also commonly abbreviated as TCP was developed in 1978 and driven by Bob Kahn and Vint Cerf. Today, TCP/IP is a language governing communications among all computers on the Internet.

TCP/IP is two separate protocols, TCP and IP, that are used together. The Internet Protocol standard dictates how packets of information are sent out over networks. IP has a packet-addressing method that lets any computer on the Internet forward a packet to another computer that is a step (or more) closer to the packet's recipient. The Transmission Control Protocol ensures the reliability of data transmission across Internet connected networks. TCP checks packets for errors and submits requests for re-transmissions if errors are found."

"The more I learn, the more I realise how much I don't know"

I would add, where possible, go cabled over wireless Ethernet. You are likely to have a stronger signal/connection with less 'collision' than that of competing WiFi devices, unless the serfs are a good couple of acres from the manor house. 

I Recently tried a Chord C Stream ethernet cable and it certainly sounded different to the good quality, but standard, cat 6 cable i use. Have no idea why, but I don't think its to do with error correction or retries, at least not over 1m.

Hi Analogmusic, I am not an expert in USB design, but you are correct 'Asynchronous USB' has no error correction.  Asynchronous Audio USB uses an isochronous USB transfer method. That is the sender sends the data, and the receiver collects the sent data and puts it in its buffer. If the CRC fails the frame or packet is discarded rather than resent. However for asynchronous audio the key thing is that every 1mS a frame is sent with a specific number of samples. If the receiver starts to receive to much data or starts to run out, it can signal back to the sender by changing the impedance between the data twisted pair of wires at the end of a frame. This is detected by the sender before each frame is sent by the sender and the sender increases or decreases the number of samples every 1mS as appropriate. But there is no data correction - just adjustment of the data rate.

Now why do cables make a difference, well the USB is a transmission line and carries electrical current at radio frequencies. Therefore is liable for emitting and conducting RFI as ell as coupling RFI to the power and ground cables. The balanced serial pair also has its balance deliberately broken as part of the signalling and so is another cause of pulsed RFI. All of this electrical noise needs to careful consideration to reduce its impact.

Now TCP/IP is a different beast entirely. It is a set of protocols for communicating data. TCP/IP includes a transport protocol called TCP - and this is used as the transport protocol to transport the packets of data - that include our digitised audio data. TCP's job is to ensure reliable data transfer, as opposed to reliable timing of data (different to asynchronous audio USB which is the other way around)

Therefore the receiver on TCP has a large set of buffers - including specifically one called a 'window'. This window can collect data packets received in different order and timing - and when the window is full it tells the sender all is ok - and the sender and receiver both move onto the next window. This carries on until the data transfer is complete. However if the window never completes, then that window is discarded and is sent again. Both the sender and receiver can dynamically agree the size of this window depending on the reliability of the transfer. A larger window is better, but more susceptible to network transfer errors.

Now with TCP there no concept of data timing (other than keeping the receive buffer non empty) . Jitter is meaningless for TCP. Timing is purely managed by the receiver clocking the data out of the received buffer that has been filled by the TCP windows described above. 

Again the main consideration of ethernet cables in our audio applciation is to reduce electrical noise and RFI. Data integrity is pretty much assure for our home LANs and if the worst happens is corrected by the TCP protocol, which could be considered over kill for home LANs unless you are using wifi or power line adapters.

Audiophile cables waxing lyrical about low jitter, and ability to support non Ethernet frequencies really is  irrelevant and in my opinion hood winking if using the cable for Ethernet.

Simon

Ethernet cables and TCP/IP with regard to audio quality just does not compute to a winner for me.

Here is a weird story, and I can't actually believe I am about to post it.  When I was very young, maybe 5 or 6 six years old, I had a record player with a single built in speaker.  I much preferred, for reasons I wouldn't have understood properly at the time, my father's stereo music system.  To address the aesthetic element at least, I made speaker looking....ish things, using two empty cornflake boxes, and ran wires from them, connected to nothing at all ultimately, to the back of my record player.  The next record I played, my jaw dropped in amazement.  They made noise.  The sound actually did come from my lovingly crafted hand made speakers.  That was not what I expected, knowing of course, they were essentially empty cardboard boxes.  I was confused, and I asked my mother to listen.  As I remember, she claimed I had put something behind them to make the sound, and I wasn't actually playing the record.  

The mind plays tricks folks, and we...well I, am / are, not as smart as we...possibly I, think.

Yes but how did they sound. You would have got a better sound from Frosties, after all there GGGGreat

Too true.  Personally though, I found Frosties just a little over powering.  In the end, for the reference version, I used Special K for a more lighter more articulate sound.  :-D