@foggyus91 Good choice in cables, I prefer silver for digital, but not for analog. OCC for everything. I use a similar cable, probably Neotech underneath:
How can different CAT5/6 cables affect sound.
While is is beyond doubt that analog cables affect sound quality and SPDIF, TOSlink and AES/EBU can effect SQ, depending on the buffering and clocking of the DAC, I am at a loss to find an explanation for how different CAT5 cables can affect the sound.
The signals over cat5 are transmitted using the TCP protocol. This protocol is error correcting, each packet contains a header with a checksum. If the receiver gets the same checksum then it acknowledges the packet. If no acknowledgement is received in the timeout interval the sender resends the packet. Packets may be received out of order and the receiver must correctly sequence the packets.
Thus, unless the cable is hopeless (in which case nothing works) the receiver has an exact copy of the data sent from the sender, AND there is NO timing information associated with TCP. The receiver must then be dependent on its internal clock for timing.
That is different with SPDIF, clocking data is included in the stream, that is why sources (e.g. high end Aurenders) have very accurate and low jitter OCXO clocks and can sound better then USB connections into DACs with less precise clocks.
Am I missing something as many people hear differences with different patch cords?
@foggyus91 Good choice in cables, I prefer silver for digital, but not for analog. OCC for everything. I use a similar cable, probably Neotech underneath:
|
Personaly I use NeoTech Solid Core Silver: Excellent CAT6 and not to darn expensive.
https://www.hificollective.co.uk/catalog/neotech-neet-1008-1-silver-rj45-cable.html
https://www.hificollective.co.uk/sites/default/files/2022-06/neotech-neet-1003-2-350_1.jpg |
@devinplombier The folks at Sablon pay for advertising on WBF, hence the banner ad and he supports a Tech Talk thread about their products. I know reading is fundamental. |
Each new debate of this topic brings new perspectives and experience with new configurations and equipment, I find it useful and entertaining. As a retired software engineer who worked on operating systems and used lots of protocols over the years, I understand well the argument from that side of the fence. However, empirical evidence, listening to different configurations, has confirmed for me that the last run to the streamer makes a difference in my environment, and for very little cost. |
chatGPT claims that anything over cat 6 is overkill for audio use & may in fact induce noise, stating: Cat6A (and above) connects shield to ground through the RJ45 connectors, which means:
I realize chatGPT is not the ultimate authority, but food for thought
|
I laugh at some of the discussions on this forum. I can tell the difference between DACs, Preamplifers, power amplifiers, speakers, and speaker cable, interconnects between sources which can be quite apparent. With the discussions about Ethernet switch and Ethernet cable quality it's a wonder why my system doesn't sound like a transistor radio, or at best, an off shelf all in one chepo. I am very critical of my stereo sound. But can accept budget restraints and push as much quality as I can for my dollars spent. I have been an information technology pro for 35 yrs, before that an electronics tech which has nothing to do with my ears. I cannot imagine my system sounding better for my money spent. I use a cheap $35 Ethernet switch over a 100mb/s network. Comcast claims audio takes only 5mbs streaming. ??? I have been at the brick and mortor show rooms and in that heaven, listened to systems 5 times the cost of mine. Did they sound better, well yes in some ways, but not in others. Was there enough difference in quality for me to upgrade to the next level. Nope! To sum it up, My picky ears which caused me to be critical about my sound is perfectly happy with the cheapo LAN, and Ethernet switch and I would be hard pressed to change anything. I completely enjoy the streamers connected to that cheapo Netgear $35 switch and it kicks booty. Laugh if you want, but I laugh to the bank and from what I am hearing, it's great. |
@steakster thank you for posting this link, it illustrates my point. Didn't know you were allowed to straight up hawk your stuff on What's Best Forum. Maybe you have to be a VIP donor? |
@toyman +1 I tried about a half dozen ethernet cables before settling on the Sablon Audio 2020. In my system, it was pretty easy to hear the improvement in SQ. Better tone, timbre, dynamics. More articulate. I have two in my streaming chain. |
Tedious as these threads are (here we agree), they exist because some folks keep spouting nonsense, rooted in ignorance and false superstition, as fact. Come to think of it... Oh, never mind. Until these folks either start educating themselves or stop posting, I am afraid these discussions will continue, even if, like you, I’d rather they didn’t. |
@herman My first post on this thread mentioned the endless repetition of the same old tired refrains on this subject, and then I get involved yet again. I will try to remember this and simply tune out next time. |
@retiredaudioguy. I am confident there are those who claim to here the differences between 568 A and B. Im equally confident they will hear differences between 568 A and 568A as in your first post. @oberoniaomnia Oooh, there you go getting all logical and facty again. ;-) @richardbrand The network failure you describe would drop any non-validated packet data received and request a resend until either a correct packet is received or the process times out. The last complete CRC error-checked and packet acknowledged is the last valid data. The sequence number is the byte number of the first byte of data in the TCP packet sent (also called a TCP segment). The acknowledgement number is the sequence number of the next byte the receiver expects to receive. One more TCP feature that ensures data quality. When the missing packet arrives, TCP can reorder the packets based on their sequence numbers before delivering them to the application layer. I'll stop here, but the more you study TCP, the absolute brilliance of it becomes more and more apparent.Remember, the idea was to literally have a bomb-proof network. J |
Post removed |
I think that the consensus is that the sonic differences are caused, not by digital issues, but by RFI or other noise induced in the patch cord leaking through into the analog circuitry. Perhaps I am lucky (or hard of hearing) but yesterday I listened back to back to the Weilerstein Elgar from my Aurender SSD, USB connected to the Esoteric K-01XD SE and the same work streamed from Presto through the Bluesound Vault, TOSlinked to the DAC and detected no differences. I live in the country, and my system is located far from any in-home electrical or electronic devices. Also, the Esoteric unit is engineered to separate analog and digital processing. My streaming is limited by drop-out in my internet connection.
|
here is a response to the same topic in last week's Weekly Recap. You can up the numbers by a bit. I spend about 5 minutes a week here hoping for something interesting but you guys debate this same topic over and over and over and the same responses are repeated over and over and over. .If you search "Ethernet" in this forum you get 12,599 hits as of a few minutes ago. Everything that can be said has been said in those posts. Let's move on |
You're correct that TCP/IP ensures error-free data transmission, so theoretically, CAT5/6 cables shouldn't affect sound quality. However, some argue that differences in noise, shielding, or EMI from cables could influence the DAC's analog output stage or power supply, potentially causing subtle audible changes—though this isn't strictly about the digital data itself. It's a debated topic, with some attributing perceived differences to placebo or system-specific interactions rather than the protocol itself. |
In many instances, those differences are heard in systems that are not galvanically isolated behind at least one run of SFP fiber. When differences are still heard with components or cables located upstream of fiber isolation, explanations still exist for that phenomenon, to the extent that psychology is indeed a science.
|
On the issue of networks and their impact on sound quality. Those approaching this from the science perspective, prima facie argument precludes yielding any validity to those reporting networks do indeed impact sound quality. Ignoring this and reverting to prima facie arguments is not good science. Quality scientific inquiry requires addressing this counter argument through development of more rigorous research into the possible causes for this variability. Simply writing off this evidence as some derangement syndrome, based on emotions and/or distrust of human senses doesn't pass muster.
Instead of retreating to the same old refrains, try to find explanations for why individuals hear differences with a multitude of audio streaming devices. Another option is to actually experience these devices in your own streaming chain. |
Post removed |
Anyone who holds the mistaken belief that cables supporting TCP transmissions, routers, network switches and the like can make a difference in sound quality should be required to read the following before opining further: http://units.folder101.com/cisco/sem1/Notes/ch7-technologies/encoding.htm Followers of the "all-digital-is-analog" superstitions won’t likely read past the first page, so the TLDR is that TCP protocols guarantee error-free data delivery regardless of the vector on which it’s transmitted, thereby effectively abstracting the physical layer. That said, copper cables transmitting TCP can indirectly affect sound quality by hosting parasitic noise. As others have confirmed, this is easily solved by using SFP (fiber) in the last run of cabling going into your streamer. This prevents any ground noise from reaching your system by galvanically isolating it (fiber is non-metallic, therefore non-conductive, therefore it does not pick up or transmit EMI or RFI). Best practice is to keep all Ethernet gear in a utility closet / room at a remove from the listening room, wall warts and SMPS-powered computers and what not included (keep them on a separate AC circuit from your system), and run SFP fiber from your switch to your streamer. This way what happens in the utility room stays in the utility room, and inky black noise floors are yours.
|
A question for people who do hear a difference between cables. Is your streamer integrated with the DAC or is there a link to an external DAC? The answer to this might provide insights regarding the induced noise theory. Another test for those who run a long cable from the switch to the streamer, though this will cost about $25. Try running the long cable to a Netgear MiniSwitch located as close as possible to the streamer, with the shortest possible (shielded?) cable from the MiniSwitch to the streamer, minimizing any RFI pickup, and hopefully, the MiniSwitch will isolate the output from any noise on the input. My big rig's network connections are implemented by a Wi-Fi to ethernet adapter connected to a MiniSwitch and then very short cables to the Aurender server and the Bluesound Vault that I use for ripping and streaming. (The Aurender does not support Presto). |
This is curious, optical reportedly superior to LAN cable, this my experience as well. So some will say this imagination, others will trust their senses. And then we have reports the transceivers in these optical devices don't all sound alike. Now we also have reports managed audiophile switches provide superior sound via decreasing network traffic. This all very curious, networks have impact on sound quality, networks have no impact on sound quality, take your pick. I suspect this thread could carry on and on with no conclusive evidence on either side, this thread will not provide the final word. |
If noise, picked up by non-shielded Cat5 cables is the problem, and from responses it seems that is might well be the issue, would that argue that a Wi-Fi (and thus decoupled) connection would work best? I cannot personally comment on this as I rarely listen to streaming sources on my big rig (I hate to say reference system) and it does not support Wi-Fi anyway, and my 2nd system has only Wi-Fi capability. My wife is a wonderful supporter of my high end journey (she supported my upgrade from a K-01xs to the xd) but would probably be critical of a 30 foot cable draped around the room from my WAP/Switch to the Bluesound node - but I might try it one day when she is out at the gym as I have a Cat5 cable building kit. The actual transfer of the bits seems unlikely to be the issue as the highest bit rate for streaming would appear to be 18.423 Mbps (2*192k*24*2) (two channels*sample rate*bit depth*2 for the TCP and other overhead) and the Cat5 standard is for 100Mbps.
|
In most networks you are receiving all of the data and it is bit perfect. And if your service is using TCP, not IP, then it is for sure bit perfect. But that is not the big issue, noise is the big issue. If CAT 6 offered perfect shielding, then there wouldn’t be CAT 8. My system sounded great with a 30’ BJC cable, until I replaced it with optical. You don’t notice the noise until it’s gone, and thus begins your cable journey. |
There are many internet protocols. TCP/IP - which is the protocol used by services such as Qobuz and Tidal - deliver bit perfect data to your streamer. It is as simple as that. I’m not sure why you use so many words to claim something different.
That would suggest a problem with the network. As everyone knows, the stream is fed into a buffer and many minutes of music can be sent, verified as bit perfect accurate, and stored in the buffer in a matter of seconds. Literally. So even a pretty wonky network is capable of delivering bit-perfect data to your streamer pretty much every single time.
What’s your point? A CD player with a broken laser won’t work. A turntable with a fried motor won’t work. A car with no gasoline won’t work. Broken things don’t work. |
I'll try to make my claim a bit clearer. The most important point about digital is that when done properly, extra information is encoded so that errors can be detected and corrected. The original digital content is preserved no matter how many times it is copied or transmitted, provided the bit error rate does not exceed the maximum correction capability. What do I mean by done properly? I mean that sufficient extra information is encoded to cover all likely error rates. In computer memory, where error rates are low, it is common to provide a capability to detect two bit errors per word, and to detect and correct all single bit errors. Much higher error rates were envisaged during the design of Compact Disks, where scratches, fingerprints and other damage had to be taken into account. The brilliant Reed-Solomon encoding scheme allows up to 4,000 consecutive bit errors to be detected and corrected. Many people claim to hear differences when streaming music, which are put down to differences in the digital domain. If digital transmission is bit-perfect, differences can only be in the digital to analogue conversion, or in the analogue domain. Admittedly, digital devices may inject analogue noise which affects the analogue domain. Is digital always bit perfect? Definitely not if I2S is used - I2S does no error checking or correction whatsoever. Ethernet does check for errors, but on its own does not require packets to be corrected. And when used in streaming mode, neither does USB. By the way, TCP is not "Standard" Internet Protocol, it is one of two widely used protocols that run over Internet Protocol, the other being User Datagram Protocol, which was designed to support streaming and does not guarantee bit-perfect delivery. For some reason people hear internet and think TCP/IP when they could just as easily think UDP/IP. There are higher-level Internet Protocols such as File Transfer Protocol (FTP) which was modified to run over TCP/IP and returns a bit-perfect file transfer or an error state. For every packet sent, TCP requires the receiver to send a return message to acknowledge receipt of the packet, and to give the number of the next packet it expects. The sender can tell when packets go missing, and resend them. All this can take several seconds and if the packets are being consumed as a stream, lead to dropouts which one might expect to be audible if not totally obvious. TCP is not bit-prefect if, for example, the network goes down halfway through a stream. It cannot possibly be.
|
This post makes no sense. Who cares how data packets are sent, who cares how usb transmits data. Every cable can sound different or in the case of fiber, no (noise) at all. If you think only analog cables make a difference, you are missing out. You don’t think cable types (copper, silver, fiber) can sound different? You don’t think better terminations make a difference? Forget about how the bits get from the source to your dac, go out and try different cables in your system to see if they make a positive sound quality difference over the cheap Walmart patch cord. When comparing cables, Don’t stop at the cheap Blue Jeans cables, these are low quality cables, get some better cables, the best you can afford and compare them to 1 another. |
I don’t speak from huge experience but you may know from my previous posts here, following much research many seemingly dumb questions asked, I have taken a deep dive into the world of Streaming, finally settling on the Lumin X1. My direct experience since has been interesting, first I had to overcome the issue of connection my router is in a different part of the home from my Lumin so I had to use the TP Link powerline which to its credit worked first time and provided a stable Ethernet connection. I had a Cat cable not sure if it was a 5 or 6. I think Cat 6 but it was fine to get the Lumin streaming. Whilst I didn't at first notice any significant noise, I changed after a while to a CAT 8 cable, not for speed or bandwidth, more for noise rejection. My own research had prompted me to try. Cat6: Typically, unshielded or UTP (Unshielded Twisted Pair), though Cat6a may be shielded. Cat8: Always fully shielded (usually S/FTP – Shielded Foiled Twisted Pair). My intention was in one change to reduce or eliminate the possibility of crosstalk and EMI The result was notable not in the way I had expected. It was more about the move more towards a blacker background that’s how I describe the reduction in noise. It made me speculate that its not about the bits it’s about the removing the interference and maybe crosstalk in non-shielded. My thoughts moved to perhaps trying the Lumin’s Optical in Via SFP & Optical Fibre input. This intrigued me but I knew it could involve some difficult threading of 20 metres of Optical Fibre back to my router. I tried short CAT8 cable into a Ethernet to Optical Converter then using a short a High quality/purity optical fiber cable to the Lumin. The logic being complete isolation from noise and the vagaries of ethernet cables. I have listened to a good few hours using the optical solution and the gains are obvious and positive. I note how music just appears in the sound stage from total quiet, its eerie sometimes but never anything but impressive. I cannot comment as to the Ethernet vs Optical sound differences except to say noise rejection/isolation definitely gave the optical connection a clear edge. As to the sound vs analogue. The only comparison I have made recently is the best Royal Scam stream I could find vs the Acoustic Sound UHQR 45rpm Vinyl played via a much-modified Linn LP12 Sondek. I can confirm that it wasn’t really close. The vinyl completely destroyed the streamed version. So, I am not naive to think that is it Vinyl beats Streaming, I know from other streams that it depends on the quality of the stream vs the quality of the analogue media and the capability of both sets of reproduction hardware but the limited experience has taught me that in this the age of digital that my record player can and does still utterly engage me. That said the Lumin X1 has opened up a whole new world and way of listening. It can sound astonishingly great and often does. I now know I have different ways to listen to an appreciate music and that’s the big win here for me. So the ethernet cable discussion doesn’t really come down to bits, for me it’s more about noise specifically crosstalk and EMI. I hope sharing my experience so far helps. |
I was having issues with a consistent WiFi connection so I went with an Ethernet cable from my router to my Innuos Zen MK3 streamer. I’ve had a great experience with Blue Jeans Cable. This time was no different. I ordered a cat 6a cable made to the length I needed. It came with the test report so I knew it was tested. It sounds great. No issues dropping the connection. I didn’t try another cable. Why would I. I go with what works and don't worry about FOMO. |
I agree with what @panzrwagn just wrote above as I was also in that field before, but with all that was said, how can one hear a change in the way music is presented? As some of the posters have written, measurements vs subjective is a debatable topic. I for one is a measurement guy but after I have gotten to the level of my gear which can discern differences in musical tone/Prat, I for now is a believer of the subjective point of view. I believe more solidly of changes in cable on the analog side, I.E., speaker and interconnect cables, phono cable and even power cables. The cable itself presents a L/R/C network at given frequencies, so Yeah, it does. The fanboys in AudioScience don't believe it, but hey, that's their take. But in ethernet? Hmm, that's a take. However, when I change the Cat6e cable from my Cisco switch to the Eversolo, there was a change (i can't pinpoint, but there was) in how the overall performance of the music. Was it better or worse, I don't know. I just put back the old one as the evaluation cable was $$$. So, in the end, is all about synergy, which one in the chain makes the most impact and does it steer you to your goal.
|
Post removed |
Post removed |
@richardbrand Switched Ethernet typically does not use CSMA/CD (Carrier Sense Multiple Access with Collision Detection) for its primary operation. While CSMA/CD is a fundamental part of Ethernet technology and was essential for early Ethernet networks using hubs, it is obsolete in modern switched Ethernet environments. TCP/IP guarantees bit perfect delivery. Packet sequencing, checksum and other header data answer the remaining questions about dropped, deformed or other anomalous packet behavior. When i was first introduced to TCP/iP in the late 1980s I was overwhelmed at everything the protocol did compared to competing non-routeable protocols like NetBEUI and IPX, but it became very clrar very shortly that TCP/IP was the future. When Microsoft made its big push into networking, it threw tons of money into free training for Microsoft Certified Systems Engineers. And the class that separated those who would make it and those who couldn't? TCP/IP. I took the week long class in LA - MS flew me from Seattle, housed, and fed me on their dime - with the provisions that if you failed, you wouldn't get reimbursed until you passed. Highly motivational. We had over 20 people in that class and about half failed the exam on their first try. It was a tough class, their toughest, and luckily I passed and became MCSE #410. There are now tens if not hundreds of thousand MCSEs. A few years later Cisco Systems created the Cisco Certified Network Engineer, a curriculum so challenging that one CCNE i knew said "Next time I'll do something easy, like medical school." He wasn't kidding. So I went into Systems Architecture instead, and the CCNEs essentially worked for me. I knew the network architecture and dealt with big picture stuff , budgets, and management, shielding the CCNEs so the could concentrate on building and operating a 5-9s global infrastructure with multiple Enterprise-class data centers. But boil it all down, and Switched/Routed Ethernet and TCP/IP is at the heart of networking as we know it today. I still like getting my hands dirty, I pull my own cable, terminate all my own connectors, and am even a certified fiber splicer. And I am very confident about what networking can and cannot add or subtract to sound quality. So I'll say it again, whatever SQ differences people think they hear, it has nothing to do with anything happening at Layer 1 Physical, Layer 2 DataLink, or Layer 3 Network Layer 4 Transport, Layer 5 Session, Layer 6 Presentatio or Layer 7 Application. Or the condensed and simplified 4-Layer model. It is all happening above that. The entire DAC process rides above all the networking, and the analog output simply isn't even in the same domain. |
Is there a sonic difference between Cat5 and CAT6 cables? Probably, but whether or not the average man can hear the difference, probably not. If all things construction are the same and the copper inside is identical, the change would be really really small. Heck, I’m not sure even my dog could hear the difference and he’s a lot younger than I am. |
Interesting thread…no science here but my experience is Ethernet cables can both make or not make an audible difference. I feel it depends on many different variables. Modem/router and their quality and power supplies, switch, optical isolation, Lan filters, power quality/conditioning, streamer quality and more. It seems to me it’s all about removing line pollution/noise. If you have a revealing system and have done an excellent job cleaning up these variables the cable may not make a noticeable difference. If not, then the cable quality and it’s shielding should make a notable SQ difference. I have a pretty revealing system and have cleaned up the above variables. I have tried several different low/mid level ethernet cables and have never heard a SQ difference. Now for those with super high revealing expensive systems with very high end cables improvement may be gained.… I don’t have experience at that level. I have made a few changes and ordered 2 different pairs of higher end cables to try one more time to see if improvement can be heard. Note: I have heard very noticeable differences in improved SQ with all other cable types especially upgrades to USB and IC’s. |
It’s the analog signal that carries the digital signal (voltage fluctuations) over the copper Ethernet cable. |
Post removed |
Last post, honest. To add to this, I live in an area where power and Internet is spotty. One or the other or both can go out. I use Roon for streaming. I have a light in my office which turns on when the Internet is in failover mode to my alternate provider so I can literally watch the light and tell if I’m online or not. The failover process however takes about 20 seconds to recognize that my primary is down before it switches over. 20 seconds. I’ve been happily listening to music while this has happened, and sometimes movies, without a single interruption. That’s how buffering works. It pre-fetches the stream before your DAC or TV is ready for it and deals with the missing packets and broken connections in the background. Cable quality be damned. The same happens when I’m driving. I go in and out of cell service often. So long as the song has started playing I never notice. A much better investment is using a low noise wall power adapter from iFi to prevent the switch mode noise from polluting your AC. I have my switch and streamer (a Raspberry Pi 5) on them. |
So, doing a little research on streaming, according to Gemini, they primarily use TCP, not UDP. As I suspected, UDP is best used for live streaming, in cases where you would rather have the audio in real time than perfect. Consider a video call. Can you wait 10 seconds to hear the others in the meeting? Then use TCP. On the other hand if you’d rather suffer packet losses and be able to carry on a conversation, use UDP. In an audio streamer the point is moot anyway as you still get bit perfect transmission from your cable modem to your streamer. Assuming UDP or TCP. The de-ionized, cryogenic, thrice blessed cable you use for the last 2 meters won’t change a single bit. Besides in a bad Wifi environment, any packet losses are going to happen long before your home. What does matter is the quality of the buffering in the streamer, and how well the clock on the DAC is able to get data when it wants it without a conflict with the input stream. |
Post removed |
This is crazy. Only the quality of the coax coming into your home affects the sound. You need to try 3-4 different Internet providers and ask them which brand of coax cable they use to make an informed opinion. OK, that's a joke. What's real is my blog on protecting your network from lightning surges is now online. Enjoy. |
It isn't clear what your claim is here. Qobuz uses TCP/IP - that's standard Internet Protocol. There's nothing unusual about it. It delivers bit-perfect data to your streamer. Whatever shortcomings you might detect with audio streaming, you can be sure the data you're getting from sources such as Qobuz and Tidal are - literally - bit perfect. |