jabbr

I am saying: 1) Using a modern Ethernet network, the eye-pattern ensures that the rejection of noise is in fact more than adequate for audiophile purposes 2) There are transmission layers above Ethernet, e.g. the IP layer for which there has been virtually no discussion: "jitter" at these layers certainly causes audible effects, most obviously "pops" and dropouts, but more subtle audible effects have only been scantly investigated. The packet delays or "jitter" at the IP level is > 1,000,000 times that of the underlying Ethernet layer i.e. in the millisecond to 100s of millisecond range and most certainly audible yeah Ravenna etc works to minimize this nonetheless the packet delay variation or packet jitter (network jitter) remains vastly higher by orders of magnitude than the ethernet clock jitter etc. This may be an easy to understand link: https://www.nextiva.com/blog/network-jitter.html

https://petapixel.com/2024/09/24/terramaster-f8-ssd-plus-nas-review-tiny-fast-quiet-and-impressive/ https://www.amazon.com/TERRAMASTER-F8-SSD-Plus-NAS/dp/B0D9HWLDX5?th=1

To each their own, just saying that the networked approach has its own adherents and the product being discussed isn't as crazy as the B-52s 😛 Also at the speed of light, controlling the music sourced from a server in your living room, or alternatively in my basement is irrelevant in terms of the human experience (I'm not living in either Elon Musk's spaceship or Jeff Bezos' house)

Look, in your own private Idaho based listening room, you can put your PC wherever you want, but I keep the bits for my very very large library in my basement, and access and send it remotely over network. In short there are many ways to as they say skin a Cat

Simple, first a $4K server is cheap as far as servers go, but lets suppose it is a high powered server doing some processing e.g. HQPlayer but could be something else, and has fans, or otherwise one wants to separate this computer from the audio area which is intended to be electrically quiet ... ethernet and specifically fiberoptic ethernet which 100% blocks common mode noise (fancy ground loops), so yes you need a device to accept the fiberoptic input and one which has been designed to be electrically quiet for the audio area, and this box sends the bits to the $32k DAC ... your real question? Why doesn't the $32K dac have a fiberoptic ethernet input? I have no idea but if you want to add a fiberoptic ethernet input to an arbitrary DAC that has a USB input you need a device. These devices range from idk $300 up to the device being discussed here. Do you need it? Do you need a $32K DAC? Easy, if you don't care about this you don't need to do it, nor consider it.

For folks reading, this is end to end "jitter" not clock jitter, the component of the total jitter due to the clock is maybe 10% and most of it is due to the rest of the electronics -- you can't stick a femtosecond clock where a 10 femtosecond clock was and expend a 100 picosecond electrical circuit to improve, you have to design the entire circuit to be 10 femtoseconds ... that we could ever *hear* these differences.

Exactly!!! who is claiming the eye pattern is a good measure for what we hear? I'm saying this: fiber eliminates common mode noise, and the eye pattern of 10G (which is a measure of both jitter and differential mode noise) is measured to be very low. There is absolutely no reason to believe that a tigther Ethernet eye pattern is any sort of measure of what we hear. You can work on optimizing everything else.

well ha ha *you* aren't throwing out scientific sounding explanations for what you are hearing. I agree with you and frankly that's why I chose to use fiber which we know doesn't transmit common mode noise, and why I chose to use 10G or faster where I know *someone* has measured jitter and differential mode noise. As I've said, I can't hear a difference between 10G and 100G so really whatever the jitter,noise amounts are its below my threshold. There are *far* more things that I can hear such as filters,modulators,amplifiers, room correction, speakers etc. Now ... I *am* using my network to do computing so this isn't at all a waste for me...

The fundamental issue is that when you hear a SQ difference after making a change, you are ascribing that to something technical without establishing the link between your hearing and the technical terms you are using. This isn’t just “logic”. What you hear is what you hear. Your explanations however are not substantiated —

add for some data from 2001!! https://grouper.ieee.org/groups/802/3/ae/public/oct01/bhatt_1_1001.pdf you can see that the eye pattern minimum in the center is >1 UI

Quibble, can you point to the specific place where you derive these numbers because they are at least an order or magnitude greater than what I derive ie where do you see 40 ps as maximal allowable in 10GbE? eg https://www.ieee802.org/3/ch/public/mar19/souvignier_3ch_01a_0319.pdf

The most obvious conclusion is that you prefer some degree of common mode noise. Prove me wrong, no with hand waving, rather with simple observable facts.

Testing for network packet corruption and delays: The forum is often obsessed with ethernet clock jitter and its entirely theoretical effects on SQ at the DAC, but there are layers and layers of firmware and software than effect the network and can more easily relate to SQ: I use iPerf3 to test my network connections. The concept of "packet jitter" or packet delay variation is real and vastly more likely to have sonic/audible effects. A congested network may cause packet collisions, packet retries etc and ultimtely dropouts. If you imagine a DSD signal over a 100m ethernet link, DSD 512: Reaches 22.6 MHz and is a substantial proportion of the entire bandwidth and certainly the possibilities for packet collision/congestion etc are real. At 1GbE there is 10x bandwidth but add in multichannel and say DSD1024 and congestion becomes real. At 10GbE the network isn't stressed at all and at 100GbE the packets are just infrequent blips. There is virtually no discussion regarding the possible effects of packet timing on SQ In any case folks should test their links

Noise can cause more problems than this, but ok! I assert that in a modern, functioning, network, this is due to common mode noise and not phase noise nor differential mode noise. How would you distinguish between the three? Measurments or picking which engineered solution has better SQ? It could be either but how do you know that some degree of common mode noise or jitter or background noise isn't sonically pleasing?

There was a famous youtube video floating around where a guy was using his oscilloscope and was seeing spikes on the screen and tracked it down to a SMPS plugged into his workbench.

There is no doubt in my mind that really cheap consumer grade network switches affect audio quality ... I have heard it myself which is what prompted me on the fiberoptic journey 10 years ago. 1) really cheap SMPS pollute the power supply, they send spikes into the 60Hz AC that end up in your equipment -- this is easily demonstrated -- isolate your audio area from the main power, I use *hefty* transformers e.g. 25-70 lbs 2) cheap Ethernet also sends common mode noise into your audio equipment -- fiber eliminates common mode noise that leaves the perma debate on: 3) phase noise and differential mode noise (voltage noise) -- 10GbE removes this but argumably there are audiphile network switches that likely remove this (if they would publish measurements) but the point about needing to isolate your audio from the spikey SMPS power supplies remains, its essential

to be clear, the software mimics the effects of phase noise at a *DAC* clock, not a network clock. Its 100% fiction arguments made with pure speculation and technical marketing, but pure fiction, that Ethernet "jitter" (which essentially doesn't exist) that there is ever a relationship between Ethernet clock phase error and DAC phase error: 1) this has never once been shown with actual measurements 2) even if it were shown for 1GbE it wouldn't apply to 10GbE because the 10GbE spec tests against transmitted electrical effects.

I guess AES67 is far less often implemented and tested than pain old Ethernet. There are well established companies that make Ethernet testing equipment which implement the "stressed receiver" testing protocols at very high speeds. Now lets ask some questions higher up on the stack: 1) can Ethernet packets get corrupted? Yes! 2) What happens: -- IP packets are transmitted as Ethernet packets, when the protocol is TCP/IP, a packet that is detected to be corrupted is resent. 3) AES67 isn't TCP/IP rather essentially replaced TCP with RTP so ... the way to debug this would be to do packet analysis on the AES67 stream Of course there may be imperfections in the network data transmission ... everyone has seen this ... but erm the fix isn't a fancy clock or wrapping your cables in playdough or whatever .... second point ... at the DSD packet level, yes you can flip bits without hearing anything necessarily but because of the *underlying* network stack ultimately at the Ethernet packet level this doesn't happen unknown, so the packet would get resent and that might cause a dropout which is grossly audible ... third point, the relationship between the PCM or DSD clock, to the underlying Ethernet clock, and back to the DAC clock *is so unrelated* that "improving" the network clock is really irrelevant to SQ ... but its not an issue because the network has to reject jitter.

Replying separately because different issues: 1) I strongly recommend making the spaghetti boxes as simple as possible because PSUs can interact etc and plugging zillions of boxes creates undecipherable interactions. My view is that folks really don't need to worry about the Ethernet network, and rather should spend their energy cleaning up/optimizing the rest of the audio system. 2) photoelectric conversion noise is thrown out as a reason not to use fiberoptic but the argument doesn't take into account that the *entire* photoconversion process is included in the end-to-end measurements. That's the reason that the Ethernet standard as of 2000 has been end-to-end, not looking at the noise of each widget. Both fiberoptic and copper Ethernet are required to have defined maximum end-to-end phase and differential mode noise -- the spec doesn't measure common mode noise. So blah blah blah about fancy clocks or chips or whether the PCB uses traces made out of palladium carefully hand painted by ------------- is irrelevant. The specification is for end-to-end testing.

This topic is complicated because, for example, single mode fiber has one line in each direction whereas multimode and copper have multiple lines and copper has vertical/voltage encoding so the "budgets" for different type of noise can be distributed in different directions but at the end of the day they both have to hit the same eye pattern at the receiver. That includes everything from the transmitter to receiver including electronics at both ends. If anyone wants to think that 1 or 10ps of Ethernet jitter is audible, then go with 100GbE (I can't hear any difference but maybe I have crappy ears.) and if a 10 fs clock is still too jittery then there are 200GbE,400GbE ... seriously this becomes a thought experiment.

This is a dense topic because the specification requires end-to-end testing. It has to do with UI i.e. a function of the link speed and the UI for 100Gbe is 1/10 for 10Gbe. ok so the UI for 10GbE is (rounding) 100 ps. this is a good intro: https://download.tek.com/document/Understanding-and-Characterizing-Timing-Jitter_55W_16146_6.pdf so... https://www.ieee802.org/3/av/public/2008_09/3av_0809_kozaki_1.pdf https://grouper.ieee.org/groups/802/3/ba/public/jan09/petrilla_01_0109.pdf So, ok lets assume 1-2ps for total jitter at 10GbE (and !!! ~100-200fs at 100GbE) and thats for all the components in the link ... the clock vendors typically allow 80-90% of the jitter/noise budget to the electronics so say 200-400 fs for the clock budget

Yeah! Let's do an experiment to see whether Ethernet noise affects SQ at the DAC output. Ok? Is everyone on board? How might we do this (we need this to be measurable)? Any takers? How about this: Lets use a device that modulates an Ethernet signal so that we can inject precise amounts of both jitter, ground plane, and power line noise into the Ethernet signal. Let's use different amounts of noise and see what happens at the DAC output. Does this sound like a good test? Well folks, that's what the Ethernet committee came up with in 1998-1999 and thats essentially what the "stressed receiver test" is. Not for audio, but with every Ethernet signal, to be compliant at 10GbE+ the noise is injected into the signal and the receiver is require to, within limits, lock onto and reject that noise, so assuming an audio link, the injected noise isn't passed along to the DAC. There's no change in the DAC signal and no one has ever show that there is. Not "shown" with white papers that spread FUD, rather never shown electrically. SQ changes are due to (3)

You should test your network and see what your specific error rate actually is, and then fix it if you can. You might have faulty parts.

Typically each port in a switch is independent and both sides of a connection need to run at the same rate. Thats a property of Ethernet. When there is a, say 10GbE connection into a switch and a say 2.5 GbE connection out, then there will be a buffer but there are protocos used to communicate rates etc. All part of Ethernet. A classic 10/1 GbE PCIe card are the Intel x502/810 etc, Mellanox also makes PCIe cards. The old ConnectX-3 cards ran hotter than Intel. AMD/Xilinx also makes nice cards that used to be used in stock trading applications. I've been using ARM devices for awhile in audio endpoints.

Is English your natural language? I've tried to say this so many ways... i've provided many references over the years and I'm not saying anyone should ever take what I say at face value, indeed this thread was started to allow people to post their practical solutions.