Importance of clocking

@antigrunge2 You said "I don‘t understand InnuOS‘ selling separate reclockers for USB and Ethernet without synchronising Ethernet input, DAC conversion and USB output."

The PhoenixNet operates purely in the ethernet domain to kill RFI noise, it is not there to improve signal timing accuracy so decribing it as a reclocker isn't really accurate (this implies the improvement in sound quality which PhoenixNet users report is down to more accurate clocking and it's not).

You can't synchronise asynchronous (ethernet) and synchronous (DAC); it doesn't make sense.

@nigeltheflash 

I stand by what I hear and am not impressed: why would InnuOS include an expensive Ocxo clock if it has no benefit? And reclocking the Etherregen is very audible. so what is your equipment and reference base for making all your statements?

@antigrunge2 

Well, some reviews claim "The Innuos PhoenixNET will also improve your music playback from the files on the music server itself. Even though that music isn’t being streamed through the PhoenixNET. You heard that right."

Well.... something not even connected somehow improves the sound. OK.

Some digging around revealed that, for example, Ethernet does not do error correction. it does discard corrupt frames though. and TCP will retransmit lost packets. So the switch may be simply buffering frames and then transmitting in sequence on cable with fewer dropped packets. How does it affect the sound? Depends on quality of the streamer. 

@nigeltheflash - Do you mean RFI on the twisted pair or in the space around the unit? Simple shielding or or galvanic isolation would drastically reduce RFI. Not sure about necessity of switch for that purpose since it runs its own CPU and hence makes its own RFI. 

@antigrunge2 Re Innuos, you’d have to ask them but I suggest you first carefully read what they say on their website about the contribution of the clock to the performance of the PhoenixNET. I suspect it’s economies of scale: they needed a clock of some sort (all switches do) and they already have one which they know is both accurate and quiet. Why source a cheaper clock which may also be noisier in RFI terms?

You asked about my equipment. I use Cat 6A shielded cable into a Reiki Audio SuperSwitch into Innuos Pulse Mini with a Zen Mini MkIII power supply which has been moderately pimped to improve its performance. I have used a short (0.5m) Cat 6 unshielded from Pulse to dCS Puccini DAC (with external U-Clock) but am enjoying other short cables here so will swap the Cat 6 out.

@mikhailark On your point about local file playback, Roy Gregory was surprised to find a similar improvement with his Wadax server/streamer (see page 5 herehttps://gy8.eu/review/magnificently-minimalist/5/. I agree with his hypothesis that if there is less RFI going into a server/streamer via the ethernet connection then that will logically affect even local file playback.

Re RFI, I mean both. Yes a switch generates its own RFI but steps can be taken to minimise that generation and the massive reduction a good switch makes to reducing incoming and therefore "net" RFI is clearly audible.

Disclosure: as per my profile, I design and build switches for audio purposes so I have spent loads of time working out what can/does and can’t/doesn’t make a difference to sound quality.

My key point in contributing to this thread is not to argue the merits of various RFI-mitigating approaches (that has been and can be discussed elsewhere). Here I simply wanted to point out the clear difference between clocking in the asynchronous ethernet domain and clocking in the synchronous bitstream domain.