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?
Per usual arguments (from the above link), theory and measurements vs subjective listening. I've tried many ethernet cables and lengths over the years and I hear differences with certain cables. So am I to believe the science or trust my senses. The measurement crowd will say my senses are not to be trusted, expectation bias clouding my senses. Usual retort is sometimes science hasn't yet formulated the right questions to ask, in other words fails to devise measurement protocol to account for what we hear. And then we go around and around ad nauseam.
In the end, on this one I go with trusting my senses. As for sound differences, I've only experienced issues with tonal balance (highs attenuated), this probably has to do with improper or excessive shielding. The only other change has to do with resolution/transparency, I've found silver content to be important for digital cables, the higher the silver content the better. Anyone reporting changes in something like timbre is imagining things.
In the final analysis, both sides free to present their arguments, up to the individual to choose who to believe.
I don't pretend to understand the science. I was running an entry level Ethernet cable from my router to my streamer (about a 12' run) and just for fun decided to get a very high quality and much more expensive cable. I got a noticeable improvement in the sound. More smooth and pleasing sound. To me it was worth the cost of the premium cable so I kept it and it's still in the system. Just my 2c
Once, one of those I-trust-my-ears guys was going on about how he didn’t like the sound of fibre Ethernet cables:
He claimed they sounded "glassy".
Glassy as in... fibre? Fiber? Fiberglass?? You can’t make that up.
@retiredaudioguy to answer your question, no, you are not missing anything - any components, cables, tweaks, etc. in the Ethernet chain (that is, everything upstream of the network streamer) have zero bearing on sound quality; because, as you correctly stated, the TCP protocol itself is error-free.
So error-free, as a matter of fact, that your streamed music travelled thousands of miles from Qobuz or Tidal servers, through countless data farms from which twee audiophile accoutrements are conspicuously absent, yet arrived at your home thoroughly unscathed and without a single bit out of place.
It is still advisable to use SFP (fiber) for the last run of cable into the streamer, to ensure proper galvanic isolation of the audio system.
At the risk, of course, of making it sound "glassy"! 😂🤣🤣
The signals over cat5 are transmitted using the TCP protocol
They don’t have to be! There is another Internet Protocol called User Datagram Protocol (UDP) which like TCP runs on Internet Protocol (IP). UDP is often used for streaming where it is more important to keep something flowing than to ensure accuracy. Note that TCP cannot guarantee how long it will take to get a correct packet to its destination. Think about that!
So TCP/IP is perfect for file transfers, and is the reason that software transmitted over the internet retains the exactly the same number of bugs at each end, provided you are prepared to wait!
Moving down the chain, Ethernet is a low-level protocol that by itself guarantees neither delivery nor timing, which is unsurprising because it does not guarantee delivery of any data packet at all. In effect it just throws packets into the air and hopes that the right receiver catches them.
Ethernet is a development of the Aloha radio network built for data communication between the Hawiian islands before the advent of satellites and undersea cables. It is an example of Carrier-sense multiple access with collision detection (CSMA/CD). Multiple Access means there is no central controller, any device can blast the airwaves with data packets. To avoid two devices obliterating each other’s packet, each device must make sure the airwaves are clear before transmitting (Carrier-sense).
But this alone is not enough. Two devices on distant islands can each sense that the airwaves are free, and transmit simultaneously with the result that the signal is scrambled in between. Two conditions must be satisfied to correct for this.
Firstly, after transmitting, each device must also listen to ensure the airwaves are still clear. If not, there has definitely been a collision (collision detection) and the device must wait a randomised time before trying again. This randomised time is initially 0 or 1 periods, but if another collision is detected, the number of possible wait periods is doubled and so on in exponential progression.
The second condition is that every message must be long enough to ensure collisions are detected even by the most separated, furthest flung islands.
There is no way of knowing if the intended receiver is even on-air unless a higher-level protocol like TCP/IP is used on top of Ethernet.
So do audio protocols always use TCP/IP? A big no.
I2S for example was designed in 1957 to allow two chips on a board to pass 2-channel 16-bit PCM data. It has no, that is zilch, error detection let alone error correction.
How about USB then? While USB can carry TCP/IP it has a special mode for streaming. Remember, streaming requires a near constant stream of packets. So in streaming mode, USB does not implement re-transmission of faulty packets.
Unlike Ethernet, USB does have a central controller, which polls every connected device to see if it wants to transmit. As I understand it, there can only be one root USB controller per box which polls every device.
Qobuz claims to use TCP/IP but to do this with streaming content, the Qobuz app(lication) must itself implement the computer code for acknowledging packet receipt, waiting doe missing packets and assembling the received packets back into the correct order. Qobuz must therefore have an app installed on the last digital device in your chain to ensure accuracy. Even then, it cannot guarantee timing across the mess of the Internet in order to avoid dropouts.
There is a properly engineered networking stack called the Open Systems Interconnect (OSI) which defines seven protocol layers. The Internet on the other hand has grown like topsy and only has four layers. Most of its ’standards’ are just Requests for Comment (RFC).
My point is actually stronger than TCP being error free, it is that the submission of the buffered data to the DAC chips is totally isolated from the nature of the patch cords. The data is stored in a RAM buffer and is fed to the DAC circuits by a clock in the DAC, so I am a loss as to what is causing people to hear sonic differences.
I just did an experiment, I started PRESTO streaming through my entry level Bluesound device which is wired to my LAN. After playing the stream for a few minutes - I pulled the LAN cable from the Bluesound node. The music continued for perhaps 20 seconds. The streamer is buffering about 20 seconds worth of bits, I tested that it is the streamer by repeating the exercise but pulled the TOSLink, there was an almost immediate cessation of music.
Streamers usually use UDP which does not have error correction, so a really bad patch cord could cause data errors.
That's a pretty broad statement and not all streaming services work the same. Netflix, for example, is a different scenario than Qobuz or Tidal.
In the case of the audio-oriented services such as Qobuz and Tidal - they use TCP/IP and you are getting bit-perfect data delivered to your streamer's input.
... streaming requires a near constant stream of packets ...
Oh no, not at all, at least not when we're talking about the limited bandwidth needed for audio. On my network, my streamer will load minutes worth of hi-res music into its buffer in a matter of seconds. That is easy to test.
"I don't pretend to understand the science." Perhaps the understatement and flag banner of this century.
Whatever differences people are hearing have nothing whatsoever to do with what happens at the transport layers. They are trying to.apply analog issues and parameters in the digital domain, a complete non-sequitur.
TCP/IP guarantees bit perfect delivery 100% of the time. All 'streaming' done withe TCP/IP is buffered multiple times b
They are trying to.apply analog issues and parameters in the digital domain, a complete non-sequitur.
Completely agree!
TCP/IP guarantees bit perfect delivery 100% of the time. All 'streaming' done withe TCP/IP is buffered multiple times
TCP/IP can only guarantee 100% bit-perfect transmission after the full transmission has completed. Qobuz seems to implement a sort of "running" TCP/IP which is bit-perfect for the completed packets already received, but who knows what the internet will regurgitate in the future?
Ethernet cables can make a difference in high-end audio systems, but not due to digital data loss — it’s about electrical noise.
📡 Why Digital Bits Still Matter (But Aren’t the Problem)
Ethernet uses packet-based transmission. If a packet is corrupted, it’s re-sent — so you still get perfect data.
Timing (jitter) is not carried through Ethernet like in SPDIF or AES. Your streamer/DAC reclocks the signal.
Therefore, sound quality differences are usually not from bit errors or timing, but from noise entering sensitive gear via Ethernet shielding or ground planes.
Qobuz seems to implement a sort of "running" TCP/IP which is bit-perfect for the completed packets already received, but who knows what the internet will regurgitate in the future?
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.
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.
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.
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.
It’s the analog signal that carries the digital signal (voltage fluctuations) over the copper Ethernet cable.
Yes the data is transmitted accurately. However, we’re streaming music, not moving text documents over network. So in our systems the Ethernet cable is a digital cable. Just like any other cable - quality of the conductor, dielectric, shielding, connectors, etc. Everything matters for the quality of the signal received and processed by the component that’s fed by that cable.
Your system will reproduce music just fine with a cheap cable as long as it works. You don’t need to spend a ton in Ethernet cables.
If you have a revealing system you are very familiar with, you will hear differences between Ethernet cables. I hear it in my system.
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.
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.
@richardbrandSwitched 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.
@jea48 I depended on Fluke gear for years and even did some consulting on the original LanMeter. We even suggested "If it works, it's a Fluke" for an advertising slogan, but Marketing wasn't amused. I still think it was a lost opportunity.
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.
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 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.
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.
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.
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.
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.
... By the way, TCP is not "Standard" Internet Protocol, it is one of two widely used protocols ...
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.
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 ...
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.
TCP is not bit-prefect if, for example, the network goes down halfway through a stream.
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.
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.
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.
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.
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).
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:
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.
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.
Instead of retreating to the same old refrains, try to find explanations for why individuals hear differences with a multitude of audio streaming devices.
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.
Galvanic isolation in quality streaming components is virtually a given these days, certainly there are generic streaming components lacking this, and I do agree this needs to be addressed.
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.
Just checked the web and this is the 18,456th forum thread about this topic with 352,789 responses not including this one
somewhere around the 15th thread everything that could possibly said about this topic had already been said multiple times
hard to believe you all are debating it for the 18,457th time.
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
If digital signal is an on or off signal (0/1), and transmission is bit perfect, how can noise (random intensity fluctuations on a continuous scale) enter a cable? Either transmission is bit perfect, then no possibility for any noise. Or it is not bit perfect with resultant noise.
You must have a verified phone number and physical address in order to post in the Audiogon Forums. Please return to Audiogon.com and complete this step. If you have any questions please contact Support.
