So, here we go again, another thread about bunch of people applying pseudoscience audiophile terms to Ethernet. Nope. Ethernet does not work that way. Ethernet, along with the TCP/IP stack are several layers of error detection and in some layers error correction. If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.
So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard.
but fiber for super short runs like 5ft is crazy waste of money.
|
And, final point, Ethernet is a layer 2 protocol. The type of cable does not change this, as the cable is layer 1, regardless if it is fiber or copper, or barbwire (yes, you can run Ethernet over barbwire).
|
So, here we go again, another thread about bunch of people applying pseudoscience audiophile terms to Ethernet. Nope. Ethernet does not work that way. Ethernet, along with the TCP/IP stack are several layers of error detection and in some layers error correction. If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.
So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard.
but fiber for super short runs like 5ft is crazy waste of money.
Are you saying that bits of music are going to be retransmitted in a stream if an error occurs. I doubt it. I believe a BROADCAST protocol is used instead of the REQUEST/RESPONSE I think you are alluding to. Yes, I program this stuff.
The reason to use Fibre in audio is not for transmission length specifically but for Fibre's ability to stop analog noise from traversing the cable and getting into your DAC. It is very easy to test and more importantly to HEAR the difference.
What I hear with Fibre over Ethernet is improved clarity, especially when using my Benchmark gear, AHB2 + LA4.
|
Thank you, although still unclear how are you have cured bidirectional Ethernet connection with a server. Unfortunately isn't two way communication integral to the process?
A router without Wi-Fi means you should be using a switch if needed. Not really practical though.
|
Well, certainly there is bidirectionality on ethernet between router and server, router needs to know server there. The difference is information from music player (Roon in my case) doesn't follow that path, it goes out second ethernet port directly to FMC (in my case) could be streamer or renderer for someone else. Without the second ethernet port information from music player has to go back through the ethernet cable connecting to router or switch.
Isn't a router without wifi a switch, never heard of a router without wifi.
|
@yyzsantabarbara yeah, no. Read up on what you are typing before you type is my suggestion. If you program this “stuff”, you really should know more than what your post implies, which is 0.
look at the cable itself.
@sns you have never heard of it because it is not your area of expertise, or even foundational knowledge… largest manufacturer of networking equipment in the world and its landing page for routers :
|
@fredrik222
Did you forget to answer to my question of how streaming is done? Here is your statement.
If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.
|
@yyzsantabarbara I certainly did not, here was my answer:
"@yyzsantabarbara yeah, no. Read up on what you are typing before you type is my suggestion. If you program this “stuff”, you really should know more than what your post implies, which is 0."
You don't know what you are talking about. There is no broadcast protocols in streaming.
|
sns, thank you again for your answer.
OK so 2 ethernet ports is what you use. I guess my problem is, a server generally only has one Ethernet port. My nucleus has only a Single ethernet port.
What do you physically connect your ethernet cables to relating to server.
Thank you
|
@jumia just because you have 2 ethernet ports, doesn't change the protocols involved. It's still bidirectional, and it's still error detection and correction involved.
Go with what is proven, and not what someone else is trying to tell you will work better.
|
@fredrik222 So you are saying that dropped packets are resent in streaming? I do not think so. That is what I am referring to by BROADCAST. Maybe 1 level up from the TCP level you started EXPERTING on.
|
The fact that all the data packets arrive in the proper order and number isn't the key thing here. Right?
Isn't the real issue the quality and speed of the clocking that occurs within a switch? The noise is certainly an issue and also is worthy of attention.
And another key issue is the bit rate through the ports. Audiophile Grade switches I believe better control the ports. Basic switches leave the ports wide open Vs. Higher grade switches for sound are scaled down to a much lower Data rate and by doing so it reduces noise. Not sure why but it sort of makes sense.
But key Is the clocking which when done well favorably impacts jitter and improve sound obviously. Basic stuff I guess.
|
Is there one device that addresses everything from the internet line entering the house, to the transport that feeds into the DAC?
|
That goes against the grain of humanity. Utopia is what it is you describe and that simply is taboo
For whatever reason, evil challenges efforts to explain things so they are understood. Genius is the ability to explain things so they can be understood and successfully dispel interfering demons. Always good that someone explaining something truly understands the subject as well as possessing the ability to clearly communicate. To have both is a strong indicator that the Angels of Genius are involved.
|
Router connects to server via AQ Vodka ethernet cable, server out connects to first in line FMC via AQ Vodka ethernet cable.
@fredrik222 Obvious listening not your cup of tea, how you getting along over at audiophilestyle forum?
|
So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard.
but fiber for super short runs like 5ft is crazy waste of money.
100% agree. And I work in the IT Industry. I have all standard power supplies in my rig except for my Power Amplifier (1500VA Toroidal/55,000uF of filtering). From the house Demark to my DSL Modem/Router, maybe a 50ft. of RG59 Coax followed by another 40ft. of cheap, simple Amazon Basic shielded RJ-45 going to a cheap Netgear "Switch/Router" and it's Wal-Wart. I run 10AWG stranded AC wire inside Armoured Conduit from the Breaker Panel to the Stereo Rig. I have no/hash/hum/grunge noise in my system even when I put my ear to the Tweeter/Midrange of my Cornwall IV's.
So am I one of the "few" of lucky ones ? From the posts on this forum, I must be.
Not having to waste my money on Ethernet Regen's, Electrical to Optical adapters, SFP modules, overpriced RJ45 switches/routers, and crazy analog power supplies in my computer chain gives me more money to spend on SACD's, legal digital downloads, and CD's. My Streamer is a Bluesound Node 2i and it's stock Power Supply as is my P.o.S. Apple M1 Mac Mini (bought it only because I've gone through 2 Win10 based PC's).
Hater's may go ahead and Hate...😂.
|
@yyzsantabarbara lol, can’t you humor us and explain how a compressed, and in most cases digitally signed or encrypted signal is broadcasted and lost packets are not retransmitted. Can’t wait for the laughs!
@sns and you, you think that your optical cable and FMC somehow can modify the payload, which is where the music resides during transmission. Again, this fmc and optical cable somehow figured out how to break encryption, flac decoding and pcm in real-time and then modifies it to sound better. I have a few bridges for you, just send me all the money you and your children will ever make up front.
I listen plenty, don’t worry about me.
|
|
@jumia the summary of this thread is, either you believe the impossible, or you teach yourself about the realities of streaming and networking, and spend your money elsewhere.
|
So, with all these streaming devices, designers with white papers, a multitude of individuals hearing the benefits of these devices. I guess we're all deluded dupes of snake oil salesmen trying to drain us of our hard earned money.
Afraid that ain't going nowhere at this site, ASR is the place for absolutes. In the meantime, we're all having fun experimenting with streaming topologies, experiential learning is our bag, pronouncements from high above not!
|
@sns absolutely. What it would take to actually make a difference is that you modify the payload. I put every thing you said against the trillion of bank transactions every minute happening globally. Because if FMC actually had a impact and could change the payload, people would be stealing money with the technology.
you don’t understand the technology, that is very obvious, and that is why you can fool yourself in believing it. It is not the same as a speaker cable, interconnect, or even a power cable. It is infinite more complex system with built in safe guards against what you are trying to achieve. The entire protocol set is built to withstand your efforts, and you think you can do anything to impact it. It is laughable.
Like I said, if your premise is correct, trillions of bank transactions are at risk. You really think so?
or do you think a few hundred, maybe even thousands, audiophiles have confirmation bias?
|
This is my last post on this thread because I seem to be conversing with an EXPERT and there is no point in telling an EXPERT anything new.
I discovered this thing called GOOGLE and in 10 seconds a lot of info on packet loss on music streaming came up. Here is one that looks interesting. Though I have not tried it.
Activities like gaming and voice chat usually do not need much raw bandwidth, but they need prompt and reliable responses. These programs also do not usually resend information if it fails to get there, so if packets get lost in transmission, they are gone for good, which can also have a significant impact.
I wrote about the audible effects of packet loss on my home network about 6 months ago on this site. It happened when I had my ROON CORE PC behind a PowerLine network. The bandwidth of the PowerLine was not sufficient to handle the George Harrision's ALL THINGS MUST PASS album in h-res. I forgot the song but one song where he whistles caused the music to get distorted on my system.
When I moved the ROON CORE to the other side of the PowerLine network (to my normal Ethernet) the distortion goes away. This problem was reproduceable 100% of the time at an exact timestamp on the music. Now if streaming was not loosing packets then I would not have had the distortion.
This discussion was a slight divergence on whether to buy expensive cabling for streaming.
|
|
@yyzsantabarbara man up now. You don’t know what you are talking about, it is as simple as that. But don’t take my word for it, ROON says so. At least admit it.
|
We have decades of experience building audio streaming protocols around UDP, and it has generally been our first choice, but we also know that both TCP and UDP, when implemented properly, are suitable for high-bandwidth, high-quality media streaming, so it was worth undertaking an exploration of “the other side” to see if there was actually a reason to consider switching.
After a series of experiments and prototypes, and a detailed exploration of both approaches, we found that we were able to extract more performance and reliability from TCP, so we took it to the next phase and started experimenting with TCP in our alpha environment a couple of months ago.
UDP is what I was referring to as BROADCAST. I forgot the term but network BROADCAST messages in software are usually done via UDP. This type of message delivery is not guaranteed and can lose packets. So it looks like ROON was using UDP and switched to TCP in June 2017. I was wrong thinking they still used UDP. However, that is just for ROON.
The test I described previously shows me that ROON does not do a perfect stream today when something is limiting them on the network. The distortion I heard on a repeatable manner tells me that even with TCP something is going on that is giving a less than perfect stream to the DAC.
|
@yyzsantabarbara oh wow. You are special! Can’t even admit you have no idea what your are talking about after your vendor of choice throws it in your face.
UDP is not broadcast. It is a stateless L3 protocol. And no, it is not just Roon. You still don’t get it, if you lose a packer when you send a compressed stream, you can’t uncompressed that part of the stream at all. In addition, DRM requires at least digitally signed music, so, the entire song must be received in its entirety for it to work for downloads, and larger chucks of the stream that is digitally signed. The only thing you have proven is that your really have no clue, which I don’t blame you for, it is infinite more complex than a speaker cable, except that you keep saying you know something about it, which you absolutely do not.
from Wikipedia “ The Internet Protocol Version 4 (IPv4), which is the primary networking protocol in use today on the Internet and all networks connected to it, supports broadcast, but the broadcast domain is the broadcasting host's subnet, which is typically small; there is no way to do an Internet-wide broadcast. ”
but hey, you “program this stuff”.
|
This thread has become a waste of time. There are some really good answers included here but some of the tangents really disappointing.
In summary it’s all about the noise passing through the ethernet cable and dealing with it. Network switches help by not adding noise, maybe canceling out some of it, and offer clocking benefits. Enough said
|
@jumia No clocking benefits, if noise is entering your streamer/DAC through Ethernet, you have some serious other issues.
so the take away is that you should not waste your money. Like I have pointed out and proven, the likes @sns and @yyzsantabarbara have no clue about how networking works.
|
A router and a switch are two different components of a network. The router is actually a computer that assigns the IP address to a Mac Address (network card) so that multiple MAC addresses can use the connection at the same time. The switch is a different component that reads the packets destination and sends them to the correct endpoint.
WIFI is a separate component that uses radio frequencies instead of hard wire to transmit and receive ethernet packets. As WIFI is now so prominent it’s built in but you can still purchase routers without WIFI.
https://www.amazon.com/MikroTik-Gigabit-Ethernet-Router-RB760iGS/dp/B07F7HDRKX/ref=sr_1_5?keywords=Non+Wireless+Router&qid=1660763397&sr=8-5
Routers can do a lot of cool things like separate groups of users to share / hide resources from each other for instance creating a departmental printer that can only be used by assigned users or limiting access to the payroll computer only to the payroll department.
Everyone should look at the routers admin pages to see what can be accomplished BUT DON’T MAKE CHANGES UNLESS YOU KNOW WHAT YOU ARE DOING AS IT’S EASY TO DOWN THE WHOLE NETWORK WITH A SINGLE SETTING!!!
|
So maybe a router that is Wi-Fi free should be used to connect all the audio stuff and you can then connect a router with a Wi-Fi daisychained to the first router, because everyone needs Wi-Fi.
Does this seem like a really good idea?
To me the Wi-Fi free router looks like a switch. Maybe connect an audiophile Grade switch directly to the modem and then connect a router to the switch for all those non-audiophile related item. And then connect all the audio equipment stuff to the first switch that is connected to the modem. Does this solve anything?
Of course excluding gear from a router may impair security concern issues.
|
For us generalists and/or audiophiles not expert in all the technicalities of streaming we have to rely on the designers of streaming equipment. @fredrik222 proposes himself as the expert above all experts, simply ignores designers of the steaming audio equipment audiophiles use to good effect. Many of us have used general service or streaming equipment not designed with audiophile in mind, we've heard improvements in sound quality with specialty equipment, he dismisses our perceptions as faulty.
For the novice, you can go with ones and zeros or you can go with trust in your senses. The one thing the objectivist can never answer is why we hear things they can't measure,
|
@sns here is the thing, I am guaranteed the foremost expert on networking on this site. I don’t know a lot about everything, but networking is the one thing I do know, love and have made my life and career off.
Therefore, like I said, confirmation bias is a real thing, and what you are proposing, where you could modify, in your favor, the payload, in real time of encrypted and digitally signed protocols, is a joke. Trillions of bank transactions every single day happen securely just because you cannot do what you think you hear. Money talks, and billions, if not hundreds of billions of dollars move every day on the basis that what you say you hear, cannot under any circumstance happen, ever.
those are the facts.
|
@jumia so, I would skip the “audiophile” switches, and go with a enterprise switch. You can find cheap Cisco, Juniper, or other enterprise grade switches on eBay.
“Audiophile” switches that I have seen actually have no real networking specs, just terms that doesn’t apply to networking at all.
|
@fredrik222
You may be a networking expert, which I respect unconditionally, but is there any possibility in your way of thinking that an analog waveform representing a secure digital financial transaction succesfully completes with added noise? Is there any possibility that a streamed song sounds different to the user if there is added noise on the ethernet feed? Is there any advantage in your way of thinking to limit the ethernet feed to 100mbps rather than “top speed”?
|
I think you’re talking two different things. there is the physical network topology segmented into layers then there is the electrical noise associated within the wire separate from the ethernet packets. Fiber not being metal is impervious to external electrical noise but does need power to perform the conversion to light so it could actually be noisier than a cable depending upon the power supply used to drive it.
|
Here is a wiki article on packet loss. An explanation for my degraded ROON audio signal on that George Harrison song (the whistling part), when my ROON Core was behind a lower bandwidth PowerLine network is explained below.
The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messaging. Packet loss in a TCP connection is also used to avoid congestion and thus produces an intentionally reduced throughput for the connection.
I am not going to belabor the BROADCAST message type I brought up into the conversation. It is at a level higher in the OSI stack than is relevant for audio streaming. So my mistake on bringing it up in this audio discussion. I assumed that audio streams were UDP BROADCAST messages.
However, the crux of the point I was making was that network packets are being dropped in audio streaming. Contrary to what this self-proclaimed EXPERT is saying. The Wiki article indicates that even under the TCP protocol, packets can be dropped (intentionally).
My reproduceable test with the George Harrison song shows me how to mangle a song on ROON 100% of the time. This is an example of network congestion causing poor audio quality in streaming.
I believe the EXPERT was making fun of the people on here with functioning ears and also potentially more expensive network cabling and routers et al, than the EXPERT themselves use.
|
@yyzsantabarbara here you go again… you just don’t know what you are talking about. Broadcast is not at a higher level than TCP or UDP (L4), broadcasts happen at L3, a lower level, and is used among other things for ARP.
and for sure TCP can and will reduce throughput, but not by dropping packets like you say, rather it reduces what is called the window size. The window size is basically how much data can be transfer before the ACK is sent. TCP never intentionally drops packets, and what you are quoting doesn’t even say that.
what I have been saying, and continue to say, is that your hearing is up against trillions of secure and undisrupted banking transactions daily. The entire system is built to prevent what you say you can hear. You may think that is mocking, but I find it insanely arrogant to not at all understand networking, like yourself, and say you can hear a difference, which would invalidate everything the Internet able to provide today.
|
"here is the thing, I am guaranteed the foremost expert on networking on this site."
Who guaranteed this?
|
@ghasley it is very possible for noise interfere with Ethernet, for sure. The point is, Ethernet is built to withstand it, and that’s why I said a safe bet for a Ethernet run without special conduits, etc. is 100 ft for residential applications. See below the max distance which in some cases is dependent on the speed, however, as a general statement, no benefit to deliberately slow down.
going back interference, the protocol Ethernet have error checking, each frame transmitted includes a checksum to make sure nothing corrupted (changed) during transmission, see below. And this is just one layer. Every layer have these checksums, and the actual application layers deal with compression and digitally signed content (DRM). So if you in anyway, modify the payload, all of these layers will fail all their checks, and it will be discarded and retransmitted. In reality, as soon as one layer detects an issue it is discarded and never goes further.
now, can noise travel via the Ethernet cable into the device itself and cause issues, sure, but that would mean a very poorly network card implementation in the device.
https://www.tripplite.com/products/ethernet-cable-types?utm_term=&utm_campaign=a.Cables+-+Panels,+Jacks+%26+Hardware&utm_source=adwords&utm_medium=ppc&hsa_src=g&hsa_ad=522769106538&hsa_tgt=dsa-1274206709011&hsa_mt=&hsa_ver=3&hsa_acc=4932208510&hsa_kw=&hsa_grp=121359314526&hsa_cam=696012424&hsa_net=adwords&gclid=Cj0KCQjwxveXBhDDARIsAI0Q0x1eE6NPdYOyoq_munQUKOqbWS7kYPopMyKZdsy4k7xHq-qWBnGZPWEaAvijEALw_wcB
https://en.wikipedia.org/wiki/Frame_check_sequence
|
@ddafoe i did. Show me another person here that knows more and I will readily admit so, however, out of the thousands of posts on this topic, my conclusion is firm.
|
@fredrik222
Thank you for the thoughtful reply. What you explain clearly in layman’s terms is appreciated. There are alot here on Audiogon who may be proficient at what we are proficient at while enjoying the audio hobby which is admittedly not our day job.
With that said, there is still alot that we collectively don’t fully understand when it comes to optimal sound quality over ethernet. Obviously we are only dealing with “the last few feet”, much like we do with power delivery, and no two home systems/rooms/environments are identical. How much noise are we trying to reduce/eliminate and how much noise do we accidentally introduce to the digital chain?
When it comes to ethernet cables in general, ethernet switches and noise, it shouldn’t make a material difference, said my right brain for many years. In fact, even if it made a material difference was it always a positive or a negative difference and if so/not, why?
I heard a positive difference when I inserted the Ether Regen into my chain. I heard a further positive improvement when I inserted Audioquest ethernet cables in place of those provided by my IT expert. While he may not be at your level, I’ve never had a financial transaction fail to successfully complete with those cables but I clearly heard a positive difference. Now, with my Network Acoustics switch, further sonic improvements were clearly heard. Same goes for the Network Acoustics Muon ethernet cable and Muon filter. Even though you may not believe it could possibly make such a positive difference, could I respectfully ask that you suspend disbelief for a moment and help me understand why it would/could?
Could it be the difference between the requirement for a steady stream vs the obvious advantages associated with simply arriving at the identical sum on both ends of a financial transaction? For instance, if the stream had a 20ms silent lag per second, that wouldnt affect a financial transaction but it likely would with streamed music. I don’t deny that its comparing apples to oranges but I know what I am hearing is vastly improved over an already highly satisfactory musical presentation. The conundrum for most here is that the logical side ouf our brain agrees completely with you. How could any of this make a difference but it does to those who have experimented.
|
@ghasley there you are wrong. Optimal audio quality over a IP network is fully understood by people like me. Do you again believe the banking is comprised daily? Or do you think super hi res simulcast concerts don’t know what they are doing? Look at Ravenna for instance.
The only potential issue is that noise from a short run Ethernet screws up a horribly implemented networking card, and if you remove that noise you could notice a difference. That premise means your super high end streamers use crap components, and that something like Etherregen removes noise. Well, noise is measurable and it doesn’t remove any noise at all. While I am sure that lots of manufacturers use bad components, but even todays bad components, are very good at handling bad noise environments.
|
How could any of this make a difference but it does to those who have experimented.
OTOH, that is not true for everyone. I have tried a number of these things with results being so subtle as to question whether there is really a difference. It's not that I summarily dismiss the possibility that this stuff can make a sonic difference, but, at least in my room with my equipment, none of this stuff so far has made an easily identifiable change or improvement.
|
Everyone is talking about noise which has merit, but what about clocking and jitter. Seems this is the most important thing relating to clarity no one talks about. faster and more precise clocking chips which seem to have Great impact on sonic performance. Dacs do their own reclockin but when what they get is in better shape it really helps I guess.
So does anybody know anything about clocking? And also Basic network switches allow the data gate to remain open at a constant rate, ie 100 mbs. Versus an audio file switch which better controls for the lower dataflow needs which is closer to 5 to 10 Mbs, which limits the transfer of noise I guess. Not sure how this exactly happens.
|
@jumia
You are correct, better clocking and jitter control are equally as important. Once again, its one of those things in the hobby that once you hear it, or better stated, once you "don't hear" the negative effects of noise/clocking/jitter is when there are some rather obvious aha moments.
These debates don't really change the thinking of either "camp". Those who have experienced positive effects are considered converts or ill-informed (depending on who is doing the considering). Those who are certain there is nothing to be gained from the effort, gain nothing by not going through the effort. Hey, maybe there is nothing to solve in their system. I do, respectfully, disagree with @fredrik222 because I have experienced the positive effects of certain cables, switches, etc and I have also experienced no effect from some while others actually adversely impact the quality of the sound. It doesn't make anyone right or wrong, it does however make you think a little about how so many rational people can be on opposite sides of topic.
@fredrik222 is right, maybe "my budget" system required some assistance whereas his system is fully fleshed out. Who knows? It would help us all get better performance if people like @fredrik222 would list his gear. I dont typically list mine because it is always changing slightly and I dont want to embarrass myself.
|
My my my. Does one jump into the hornets nest on their first post?
Concerning the "expert", I very much have doubts about their expertise. When you have been around true experts, you notice things. Clear, concise, few necessary references, talk in pros and cons, specifics, etc. I see some of that, but not a lot. Experts rarely arbitrarily say they are the best. They let their words speak for themselves.
Audio over an IP network needs to be broken down into at least 3 types. Real-time audio such as VOIP, conferencing, screen sharing, even in large real time studio applications. Compressed, streamed, and buffered music. Uncompressed, streamed and buffered music.
Different protocols are used for real time audio versus streamed and buffered. With real time audio, packets can be permanently lost. This is acceptable in the protocol as latency is more important than anything.
With streamed and buffered audio, which is what streaming services would fall into, lost packets will be re-transmitted with the net result being all packets, except very rare circumstances, will be delivered to the receiving end. I can't speak for the internals off all the apps/Win/OSX programs out there, but I have seen comparisons showing streamed and CD were the same. I would expect those streaming services in conjunction with their receiving programs use a variety of error correction and re-transmit techniques to minimize overall bandwidth where possible. With compressed, and I don't mean FLAC, the service does have the option of dropping information to reduce bandwidth.
Do IP networks drop packets to manage bandwidth? Absolutely. That does not mean they are never delivered though. That just means that particular sent packet was not delivered. It can be resent till it gets through.
It is guaranteed that the protocol between your local server and end-point is using a fully recoverable protocol, i.e. not total packet loss? If the product is using a standard protocol like DLNA and approved you can be sure of how it behaves. I am sure our expert can chime in on that. If proprietary, no comment.
UDP has no guaranteed delivery mechanism. TCP does. If you are using a TCP protocol, there is inherent functions built in to guarantee delivery no matter what the application does. UDP does not guarantee that. TCP allow setting up secure connections. UDP does not. You can make your own conclusions about paid streaming services and use (obviously TCP). UDP does support broadcast messaging, but normally only used for discovery.
We know that TCP is used by all major streaming services, and that pretty much guarantees in most cases all packets arriving, with application layer taking care of the rest using buffering. What is happening on your local network? Could it be UDP? Maybe. I do know in my own network, I have pretty no losses, so it really does not matter to me.
|
Almost forget what this was about. Ethernet ports are transformer isolated. They won't pass low frequency noise. They can pass high frequency noise, but its a transformer. It will reject most common mode noise. How hard can it be to isolate that part of the circuit from the DAC and analog? Seems every piece of electronic test equipment has an Ethernet port today. They don't seem worried. Someone mentioned jitter. I know this crowd is anti Audioscience, but tests are tests emotions aside. Jitter shows up as distortion. Tests I have read have been laptops and basic router/switches into DACs. I don't seen any added distortion from ethernet.
I see a lot of expensive Cat-6/7 cables. Those are shielded. The shields are connected at both ends. That does sound like a recipe for a ground loop that did not exist before.
|
@theaudiomaniac so, you called me out. What is wrong in any of my posts?
to your posts, I would add while UDP does not provide reliability at the transport layer, it leaves that to the higher level protocols. Which is huge headache, and probably why Roon ultimately switched to TCP.
|
Or they switched because they were not providing high level correction of lost packets, realized it was an issue in some networks, and went the TCP route to fix it since most home networks today have more than enough bandwidth unlike when they developed their product.I don't know the answer. I don't think you do either. Roon networking is for local connectivity, though it does provide management and access for external services. Most do not put a wrapper around UDP to guarantee transport. If you are going to do that, you go TCP. For UDP, any number of feed-forward and error correction schemes are used for media to provide coverage when packets are lost and some minor retransmit schemes have been used where low latency can be maintained, but full guaranteed delivery makes little sense with UDP when TCP exists.
If you felt called out, perhaps consider not making absolute statements that are incorrect nor holding yourself up as absolute.
|
You are both very knowledgeable and I'm grateful those standards mentioned aren't my decision to implement. The OP asked if there were solutions to improve noise, clocking, jitter, etc and were they beneficial. Some Audiogon members report improvements, others not so much. Who is right, maybe everyone. Each system is different, each environment is different.
The OP is an adult and can choose to check these out or not.
|
