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

No you do not.

Also, for the un-informed, there is NO such thing as ethernet clocking. It is an ASYNCHRONOUS stream.

An el-cheapo switch like this will more than be enough:

It is also known as the "self learning bridge", plug & play, no configuration required. As long as you buy devices which are TRUE to the 802.3 and 802.11 standards, there will be no problems whatsoever. Cables will not matter diddly s..t either, AS LONG AS they are spec’ed to the standards.

Spend your money on a proper streamer and/or a DAC instead.

What is important however is NOT to place their SMPS wall warts next to sensitive analog electronics, like MC phono preamps.

It's been said previously but I don't mind re-iterating -

There is no such thing as an "audio grade" network switch... go ahead and try finding any OEM network component supplier who would even think of marketing an 8P8C/RJ45 connector as "audio grade". I've tried, they don't exist, these audio accessory companies are just clever with their marketing, apparently most "audiophiles" lap up whatever their favorite audio review rag touts.

*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.