Do I really need an " Audio Grade Network Switch "?

*Debating making popcorn*

no

*Returning for page 2 la

@cakyol If I am the un-informed.. maybe I am uneducated and my English is not good but I wander what these specs are for then.. 

ITU-T Rec. G.8261

ITU-T Rec. G.8262

ITU-T Rec. G.8264 

ITU-T G.8264 Ethernet Synchronization Message Channel (ESMC) protocol data unit rec, which defines a background or heart-beat message to provide a continuous indication of the clock quality level

IEEE 802.x

IEEE 1588 v1,, v1.1, v1.2, v2, SyncE and Ethernet symbol clock

G.8262/Y.1362

IEEE 802.3ay and newer revisions

At no point I said that Ethernet is synchronous or asynchronous because it depends on the flavor, and it is not relevant. 

Most Ethernet flavors have framing bits, that establish both the start of the frame and that prime the bit timing recovery circuitry of the receivers. The only one that comes to mind now that does not is Ethernet over RS-232, using UART to transfer data and  leveraging SLIP to transfer IP packets over a serial interface instead of Ethernet interface but that was many many years ago.

Quote from the spec explanation "Ethernet between a MCU and PHY typically uses the MII bus, which is synchronous interface. It even has two clocks, one for transmitting data, and one recovered for receiving data. The RMII combines the clocks into one which means the PHY has to have a data FIFO to tolerate clock differences between devices." 

These clocks are also used in the training, quote from the spec "The operation of the maxwait_timer requires that the PHY complete the startup sequence from states PMA_Training_Init_M or PMA_Training_Init_S to PMA_Fine_Adjust in less than 2000mS to avoid link_status being changed to FAIL by the link monitor state machine"

So, does Ethernet have a clock "line"? Yes at the PHY MII level, no at the medium, as it is embedded in the data. Is this synchronous or asynchronous? It depends on the definition. The clock must and will be recovered at the receiving end to receive the data symbols correctly.

Maybe we are talking about different things? and I failing to communicate correctly?

At the end, claiming that an ethernet switch can make any difference on how a streamer decodes into music is just not true, because by the time data bits get to the streamer processor they have been in multiple buffers, transformed and refclked outside of the Ethernet domain.

The timing information for a digital music stream is encoded into the data. The exact timing and rate at which packets are transferred makes no difference unless so many packets are dropped that the playing device's input buffer is drained. The only hardware clock that might affect the music is the one that the DAC uses.

I think we are all making the same point and my English is not good enough and I got too technical.

All I wanted to say was that even the little timing information provided by RMII could not be used for anything else than to ensure the RX processes the the data symbols correctly.

Thus claiming that an "audiophile" switch can enhance how the encoder/decoder process data is non-sense because the only refclk reference the encoder/decoder has it is in its bus.

Need to get ready to work, good night to the USA.

@astolfor 

The interface between a PHY device and the CPU are *INTERNAL* to the design of the device.  Once the signals reach the PHY and are emitted to the Ethernet wire, there is no clocking involved.  You are looking at BOARD LEVEL HARDWARE design (RMII bus).

This has nothing to do with how the signals on the Ethernet wire travel.