Streaming vs Physical Media

@stevewharton 

Why do you need upgraded clocks in a network stream when TCP/IP ensures reliable delivery to the streamer - I don't understand ?

The Audiolab 6000 CDT has interesting specs ensuring excellent CD playback:

• The master clock is controlled by a temperature-compensated crystal oscillator.
• the coaxial output is fed from a differential line driver to ensure a flawless digital signal reaches the accompanying DAC.
• The transport is housed in its own, electromagnetically shielded enclosure, and includes a dedicated power supply.

Not bad for the price ... but of course please note what Mojo Audio say about the Jay's Audio CDT. For any of you that have owned a Mojo Audio DAC you should know how reputable his equipment is so he should  know what he's talking about!

I understand that the Jay's Audio CDT impressed him so much he stopped making computer based audio transports. Also be aware that Audio Note in the UK firmly believe the CDT is far better than computer audio streaming.

@jji666 

You comment on audio packets being streamed over TCP/IP perfectly is correct - the IP packets will arrive at their destination in correct order using checksum calculations, it's all part of the robustness of this comms technology.

Noise is not at all relevant during the IP packet sending stage (unless you are getting obvious dropouts), because as I said earlier the IP packets will be in the correct order on arrival to the receiving device.

Noise can only enter the end device (streamer) by physical contact, for example over an Ethernet lead - so maybe a good quality Ethernet lead at the very end is all you need.

If you have an excellent wireless connection - then the only issue is how well  the wireless receiver in the streamer is being shielded from the rest of the electronics. If there are no dropouts over Wi-Fi then all the IP packets will be received in the correct order and therefore there is certainly no need for audiophile switches and leads for obvious reasons.

In summary - IP packets in a good network will always get to their destination in the correct order (i.e. the streamer) - so from a binary perspective connectivity will always be perfect. It's the physical connection only which could introduce noise that you may have to deal with.

Ultimately there is no arguing with the fact that all the 1's and 0's get to the streamer in the right order because of the TCP/IP protocol which is designed to do this.

So what does this mean? This means the music is sent perfectly to the streamer / bridge.

So if the streamer is always getting a perfect binary signal where does it go wrong?

Well the only thing I can think of is that noise is entering the system along with the binary stream. It's noise that's the polluter nothing else can be!

But whatever the outcome - TCP/IP ensures a perfect binary order due to checksumming the stream <-- therefore nothing at all can go wrong at this stage (unless you have a bad network).

@stevewharton 

Nice summary - and I sort of do get where clocking is relevant from within the streamer or from within the CD player - but before that - no - I don't get it.

At the time of streaming say from Qobuz - the transmission of the data from Qobuz is sent in the correct binary order (courtesy of TCP) to the streamer - so if all the information at the streamer is identical to the information from Qobuz then nothing is lost en-route to the streamer whatsoever! The data arrives at the streamer identical to that from Qobuz.

And when the data is being sent to the streamer over IP there is no need at this point to make a perfect analogue waveform, therefore no clocks needed - just a checksum to ensure perfect data delivery.

Clocking from within the streamer fine - but clocking before the streamer on network switches at the data send stage when TCP is involved - sorry I am still lost. But I sit here open minded and  I am happy to be proven wrong ....

I just don't want us gullible audiophiles to be mugged off.