jabbr

Great! Yeah because although these integrate well with fiberoptic equipment, and I’ve see them in my basement data center, they aren’t fiberoptic and don’t block common mode noise! I’ll say this: 1) when used in 10G+ networks and assuming they are compliant, the system needs to meet the 10G+ standards for noise rejection on the eye pattern. 2) with short hops they are cheaper 3) all that said, the idea that fiberoptic devices generate more noise is pure unadulterated poppycock because all the 10G+ devices need to meet the same strict end-to-end noise standards. These devices have been measured to be not-noisy. The future of ultra high speed networking is fiber to the chip. No noise. But yeah this is a hobby and I get it that folks want to listen for cable differences!

Yeah but folks should be aware that BiDi SFP(+) modules are specific and you can't expect typical SFP(+) modules to work with mono cables. An example of armored LC-LC duplex: https://www.fs.com/products/40385.html?utm_country=9052181&gad_source=1&gclid=EAIaIQobChMIq92sm4m2hgMV3Hd_AB2jdgEiEAAYASAAEgIZrvD_BwE ... fs.com is a great source for pre-terminated cables

FMCs tend to be more cheaply made than switches but at 10G I wouldn't worry about jitter specs. Mikrotik makes a fanless 5 port switch and TP Link also something similar. AOC cables can be hit or miss but SMF, particularly Corning ClearCurve is pretty tough, and outdoor rated cables are tougher. Then use whichever SFP(+) modules work with each end.

I like to have only a fiber enter the balanced power area, so have the first FMC outside the balanced power and the second FMC inside and both not powered by the same PSU so as not to tied them together electrically

Just as all copper wires don’t connect to the same places, nor do all optical fibers: TOSLink and fiberoptic Ethernet are entirely different

The network, now, is truly the computer FWIW, a big reason why NVidia bought Mellanox (and AMD bought Xilinx) is that the NIC does the NVMe-oF processing

So the final conclusion as yet another mid-fi codec...

for CAT 6 you should consult building codes about plenum ratings depending on how you are wiring. For optical I personally like LC-LC singlemode but multimode is fine too. You can measure the home runs and use preterminated cable. I have found that cable can run over both Ethernet cabling as well as increasingly wifi so you may not need new coax It is very common to run a copper ethernet next to fiber. The question is how you want to terminate the copper. The Belden REVConnect termination tool is fantastic but maybe more than you need for a very small install...

Good point. There is a common misconception that objective results mean valid results

I've spent a great deal of time with music professors and high level professional musicians. They aren't concerned about audio equipment so much and can glean the "sound" of a performance from what might be a simple recording played back on a laptop. This includes auditioning things like different bows. Or even getting into a music school where a video or audio is uploaded and then watched on a laptop. For me, there is still something unquantifiable about a playback and a live performance. I think that 99.99% of what we talk about as audiophiles failed to get at this issue i.e. whether cables and widgets and various forms of equipment make any difference. Maybe improved immersive technology, room correction, equipment correction etc will get us closer to "being there" ... and by that I mean getting me back to the memory of "being there" at a Dead Concert or standing yards away from Buddy Guy etc etc

Of course anytime there is an external clocked signal and an internal clock you are crossing an async clock domain and that absolutely needs to be dealt with. As much blah blah blah about network jitter as we hear bandied about there is almost no discussion about how handling external clocked signal should be done. As you have noted the DAC could output a clock signal so the transmitter could take the responsibility of locking onto that but that never happens in practice. In every** Ethernet signal, the receiver has to "recover" the transmitter's clock but same with USB and I2S and this is done via PLL. The newest digital clock chips "clean" up the crystal or any external clock with a PLL. that's how they perform. thats how xx femtosecond jitter is achieved. so yeah you can't push this outside of the DAC if you want the best performance, the DAC inputs **require** good engineering which takes into account external clock domains. Modern (ie >=10Gbe) ethernet receivers are mandated to do this by specification. The best USB receivers are engineered to do this. There's no advantage to external I2S because the external I2S clock is an async domain. That means using a PLL and buffer (if its done right). ** the external signal is coming in at an unknown phase wrt to the receiver's internal clock. The externally clocked signal has to be "close" enough that the external clock and external jitter can be locked onto by the receiver. The receiver then serializes the signal with its own clock and transmits the bits. A USB receiver (or Ethernet) can have the bits clocked out by the actual DAC clock when they are on the same device ... and the exact length of the traces are known so the phase of signals on various parts of the board are precisely known.

Thank you. Fair enough!

This is an assumption which may or may not be true. From a basic POV if I have devices with say 100dB, 110dB, 120dB and 130dB SNR yet reproduce with a 90dB SNR device I wouldn't expect to be able to discriminate. I have no idea whether a 24/96 ADC can determine between a 24/192 vs 256 vs 512 vs 1024 DSD DAC. @Miska has DAC correction software, so surely there are DAC differences. There are different DSD modulators and filters ... can a 24/96 ADC distinguish ... maybe yes, maybe no but I just don't know that nor will I blindly accept the study design. The study presupposes that all you need is a 24/96 DAC.

Sorry I can’t find an analysis of this article due beyond “24/96” should be enough. Lots of assumptions. Same as what you say about whether anything could assuage my concerns.

yeah I’m questioning the assumptions and the study design. What are you saying? Do you understand why I’m questioning this from a technical perspective? My concern has nothing to do with flaws in DBT … I’d be happy if the comparison was done in person/direct listening to the blinded output of the DACs. Im not accepting the premise that a recording of the DAC output itself recorded and played back on my AirPods is an accurate representation of the DAC SQ.