I’m new here. 40 years audiophile. 30 years designing software and hardware for switches, routers, high performance wifi access points.
Open minded guy, I think. I have iso pucks everywhere, nice cables, power regeneration and what have you…. Clearly not Amir’s best buddy. I believe just about anything can affect sound.
In the process of building networking gear that sold for billions of dollars (if you get out of the house, you have used gear I had something to do with, it’s a small world), I learned a thing or two. And yet, I do not understand anything about audiophile Ethernet switches and cables. The issue here is that I can always at least find some theories on why this or why that can be possible. I am completely empty handed, either reading the specs of those devices or putting to work my fertile imagination.
Our community has been fed so much crap about the wonders of digital music since the first CD, some of those promises are just starting to come true. We were blessed with SPDIF, USB, TOSLINK and other atrocities. None of this stuff has a combination of CRC, forward error connection, retransmission or even any sort of link monitoring. I shell out decent cash on all those connections cables because the whole link layer protocol is just a sac of crap. I guess even the high end audio industry is not found on fixing this, it is a product offerings bonanza.
Now enters Ethernet and TCP/IP. Different ball game. I would not blame anyone to be skeptic, see previous point. There’s no point starting an enumeration here, point is that I can find a thousand reasons why there’s zero chances this networking stuff will change the sound.
I’m going to go one notch farther. I have a brillant idea for a product design that can take all the voodoo out of it. It would be a pain to do this, but we could build a system that would compute the SHA-1 digest of all the bits fed to a DAC chip and report whether piece was authentic to the source file. That would be a really fun project. Or it could be done on SPDIF and USB too. I would love to see this done. That would not completely close debates, my bit is sweater than your bit would go on, but that would do it for me.
In the mean time, I will continue to choose Ethernet cables based on color :-0. Oh one last detail. Last time I checked, 1000base T Ethernet does not have a clock. So there is that, it’s a whole new world.
Ethernet Clocking
i had previously reported that adding an Antelope 10m rubidium clock to the Etherregen results in major tightening of soundstage and location of individual instruments. To my great surprise adding filtering on the BNC 75 Ohms connection between clock and Etherregen results in substantial additional benefits. The filter used is a Mini-Circuits BLP-10.7-75+ DCto11MHZ model.
We are only beginning to understand how to maintain clean clocking on digital connections, it is of paramount importance to SQ.
- ...
- 53 posts total
clıcking ? @cakyol |
Except @lmcmalo cant help but chip in. Let’s pass the point where some vendor has a RE-clocking product for a protocol without a clock :-0 Ethernet phy layer is an asynchronous. Very roughly it works like this. Very roughly, it’s complicated in practice. The line goes flat, there’s a gap between packets. Then comes a fixed start sequence, the receiver locks on it and then runs its own clock starting from that point on the negotiated speed. It works fine because it’s very brief. The clock has to be in sync for that 1 packet. Because there’s CRC, errors can be detected. Phy errors are uncommon in normal situations And no one cares, the missing packets get retransmitted by TCP..
|
- 53 posts total