I use two Cisco switches connected optically to reduce digital noise in the Cat6 cable. One switch receives input data, which is linked to the other switch via an optical cable, while the second switch provides a clean output to the device. Any business-grade Cisco switch with optical connection will work, and I can definitely notice the difference on my smart TV. For example, the picture quality is much better.
Theoretically you should avoid an ethernet cable with a metal connector (which ironically excludes a ton of âaudiophileâ nonsense cables)
Otherwise, no fancy cable is going to help your SQ whatsoever. If the cable is functional, youâre fine.
The demands for streaming audio + providing the âviewsâ for client devices are tiny. If youâre running a gigabit network which I mean, 99% of people likely are, itâs got more than enough overhead for any audio nonsense you can think of. I sling around huge #s of channels with AES67 on gigabit cables (like 64+ in some cases). Donât worry about it.
2 Likes
People hear all kinds of things when it comes to audio reproduction. They will often not find a technical explanation for what they hear in their head.
2 Likes
For short undamaged Ethernet cables the only thing that can effect transmission of data packets sufficiently to cause uncorrected corruption of data bits are dirty plugs and sockets, and the only cleaning technique you need to bother with is disconnecting and reconnecting the cable several times.
Contrary to the opinions stated on that cables are just cables and whether the connector is wire or optical, there is plenty of ongoing research on uncorrected data bit corruption for safety critical systems, financial systems, document storage systems etc. The longer the cable/fibre the more likely corruption will occur, reinterpretation of bits really should not matter in music systems, but when human life or money is involved itâs a different story.Whether such corruption will be audible is a different question!
This thread is about Ethernet cables - a domain where cables are definitely just cables.
4 Likes
@4651282 Iâve debated whether to reply to this, but I believe I owe it to a fellow audiophile to do so. In short, no, that cable has no sonic signature, and changing one functioning cable for another is not an upgrade in audible terms.
@Wade_Oram is 100% correct.
However, all bets are off regarding the brainâs perception of what it hears. One may hear a difference, but itâs really the brain that is creating that difference, not the cable or network.
2 Likes
In TCP/IP over ethernet, there are several layers of error detection.
First the Ethernet Frame has an FCS (Frame check seqence) at the tail of each frame. This works like a kind of checksum of the entire contents of the frame. If this frame check fails, then the entrire frame is dropped and it is never seen by the TCP/IP stack software.
Then there is the IP packet header checksum. This allows the TCP/IP software stack to check the header only of the IP packet (the payload of the ethernet frame). Again, if the check fails, then the packet is dropped and not forwarded on to the rest of the TCP/IP stack.
The payload of the IP packet, is the TCP packet. This contains its own checksum and again, if the checksum check fails, then the TCP packet is dropped.
If all of these checks pass, the packet contents are then passed to the application (which may or may not do itâs own additional checking). Most, if not all, audio streaming protocols do not bother because of the complexity of designing an application protocol that would work with such detected errors and the generally inconsequential costs of not detecting them (a pop on the audio due to an incorrect sample may be annoying but is does no harm and there is no cost associated with it).
When a TCP packet is dropped, as a result of any of the above three checks, the TCP stack on the receiver does not send a âpacket receivedâ acknowledgement (obviously). Because, this is not sent, after a very short time interval, the sender will stop sending new packets and go back to the packet that was not acknowledged and resend everything from there. This all happens so quick that an occaisional dropped (and then resent) packet will go completely unnoticed. Only when it happens very regularly (in the case of a cable or hardware fault) will it cause a problem.
OK. So thatâs the basic mechanism. However, none of the various checks are perfect. Considereing the Ethernet Frame Check alone, the chance of a single bit error in the ethernet frame getting undetected is 1 in 2^32 (about 1 in 4 billion). Since each frame carries approximately 1400 bytes (ignoring jumbo frames) of data (or about 175 32 bit stereo samples), and there is a 1 in 4 billion chance of an error going undetected then even if every frame had a single bit error in it (which they donât - errors on well configured networks are very, very low), then, it would, even at a 768kHz PCM sample rate, take 5 and a half days before an erroneous sample got through to the application and thus got forwarded to the DAC. In fact, since the digital transmission over ethernet is actually very reliable and there are other checks involved (IP header checksum and TCP packet checksum) as well which work to reduce undetected error rates even further, it is statistically likely to be decades (or even centuries and millenia) before an incorrect sample got through the error checking at all layers and arrived at the DAC.
I donât know about you, but Iâm not going to hang around that amount of time listening for an incorrect sample that may even then be inaudible (if it is only a low order bit, even with 16 bit samples, it is unlikely anyone would notice the extremely transient error. High order bits are of course a different matter).
So yes. Etherenet with TCP/IP on top of it can not guarantee perfect data delivery but in practise, it is so close to being perfect that it is not worth worrying about.
Edit: I confused the size (and nature) of the Ethernet FCS and the TCP packet checksum so my discussion of the rate at which an undetected error would occur was wrong for the TCP checksumming but was correct for the Ethernet Frame Check. I have thus reworded that paragraph to refer to ethernet frames rather than TCP packets.
9 Likes
The reason the cables and switches provably make no difference is in how streaming audio protocols work and how they leverage TCP/IP (the protocol used for the Internet) to ensure bit-perfect delivery. The below is a little simplified for ease of reading, but ostensibly how it works.
TCP, Transmission Control Protocol, is designed to deliver all packets intact - itâs a reliable protocol, which means the receiver acknowledges the receipt of every error-free packet. If there are bit errors in transmission, the switching, routing or endpoints detect that using the error detection mechanism (CRC) built into every packet. When packets are dropped or donât arrive, the receiving end does not acknowledge receipt of that packet so the transmitting end resends the packet. If the packet is still not acknowledged after a period of time (in ms) the send retransmits again, and this carries on until the packet is delivered. This is how all reliable traffic works on the Internet, and it works 100% of the time, otherwise we couldnât have online banking, for example. TCP guarantees reliable delivery - but not necessarily timely delivery - retransmissions take time.
The streaming protocol focuses on the timely portion. It does this by keeping the buffers in the receiver from becoming empty, by requesting sufficient data from the sender to ensure the player, which is emptying the buffers, does not empty the buffer faster than theyâre filled. A 192/32 stream only needs 12 Mbps of goodput (the actual reliably delivered data) to work perfectly, so any 100 Mbps Ethernet switch will handle this easily. But rather than request the data as packets, the receiver requests the data in big chunks, i.e. lots of packets at a time and puts the data into the buffer on the streamer. Once the buffer reaches a low water market (not empty), more data is needed, which is also requested by the receiver. Because itâs the receiver controlling this, data is always available when itâs needed by the player. There are lots of built-in timers, as well as protocol decisions on how much to buffer that are specific to the protocol, but basically they all work like this. The obvious solution is to request the entire song, put it in memory and play it once itâs received, but that may be inefficient use of resources, so itâs usually chunked up a bit.
This use of TCP and buffers means packet drops and jitter donât exist for the player portion of the streamer as it just accesses the local buffers - which are just memory/RAM. With sufficient buffers and sufficient network throughput even a terrible network will sound perfect. A good network cannot sound more perfect by definition.
In a faulty network, where packet drop is really huge (or a WiFi connection that is congested or very low throughput), itâs possible that TCP simply cannot deliver enough traffic to keep the buffers full - this would cause clicks if the packet drop is chronic but not catastrophic (little bits of silence or jumps in the music depending on how the player handles errors) which would be blatantly obvious or the stream would fail if the packet drop is catastrophic and the music stops. It wouldnât manifest as a sound quality change as either the bits are there or they arenât, and the player is just reading from the local buffers.
Thereâs a lot more complexity under the hood - but the key is Ethernet is a very old protocol and TCP/IP is nearly as old (40+ years old). All of that complexity has been optimized completely in modern switches and routers. All one is paying for there is port density, features, HW and SW support and brand names - not packet delivery which is the same for all of them - or the product is faulty.
Hope that helps - you donât need to upgrade the cable, it wonât make any difference at all.
4 Likes
@Wade_Oram
Thank you for you clear explication, but are you sure that RAAT is sent in TCP?
I have never done a wireshark-trace on RAAT, so I cannot confirm it, but I would think that RAAT is sent out in UDP, not TCP, as retransmissions are too slow for audio, I would think.
Kind regards, Frank.
I donât know that TCP is used for RAAT - like you I have never captured any packet data to find out. However I would be extremely surprised, if not astounded, if it was not.
TCP is more than capable of delivering audio reliably with all packets arriving in the correct order. TCP is used by the online streaming services and it is used by ARC. There is no reason to believe that it is not also used by RAAT.
UDP, by contrast, does not guarantee delivery and it does not guarantee packet delivery order. This would be disastrous with, for example, a mediocre Wi-Fi link.
Delivery time through the network stack may be a little slower (latency) but the times involved are tiny - ms or less. Only on unreliable transports where retransmissions occasionally occur does this latency become more significant (multiple ms) and, as has been pointed out above, that is easily compensated for using sample buffers in the end equipment.
TCP is used to support the vast majority of application layer protocols many with much higher demands on timely delivery than audio.
By contrast, UDP is used in applications that donât care about packet delivery reliability (dropped packets) and ordering or in applications, like tunnelling, where a higher layer protocol looks after delivery ordering and retransmission. In the case of tunnelling as used by many VPNs the higher layer is often ⌠TCP.
Contrary to what many believe, audio, even extreme hi-res audio is not an application that puts much strain on networking protocols given a reliable transport layer.
2 Likes
Yes RAAT uses TCP. When first launched they used UDP but later switched to TCP as it was more reliable.
5 Likes
1 Like
Here is an article on it back in 2017
3 Likes
@CrystalGipsy
Thank you for this article. Now I am sure that RAAT is in TCP, and the reason why Roon switched to TCP.
@Wade_Oram
You were right, RAAT is apparently in TCP and not UDP.
Kind regards, Frank.
Hereâs the build 234 notice that explains the change from UDP to TCP.
1 Like
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.