Music Server Set-up Considerations

[Puma Cat]

A member in another forum posted a comment about digital-based "streaming" systems. The initial, comment, "quoted" below, was around using an Ethernet switch to send digital music files from an "upstream" music server computer downstream to a network bridge, streamer, DAC, or streamer/DAC set-up in the main audio rack, and some of points were accurate, but additionally, some were not. Thought the gang might find his comments and some additional info I posted in response to his original post to be useful with respect to setting up a networked music server-type digital audio system. Cheers, gents.

Originally Posted by Name Withheld

A difficult question: Looking for another streamer. I am struggling for a long time. It did get my interest when going to an audio show from Silent Angel. Silent Angel was very well known by their audiophilic switches, which they started with the Silent Angel Bonn I use, combined with a lineair forester power supply. Nowadays their newest versions have a better build, and are also equipped with an input for external clocks and this matter makes a lot of sense. What is the issue? The internet is a collection of all servers which creates all kind of timing errors: called jitter. As we all know: jitter is hearable and is the major enemy in audio streaming. How much jitter are we talking about? To measure that the internet site speedtest.nl is used Speedtest.nl -. The amount of jitter varies a bit, at the moment this picture was taken, jitter was 0,700 ms. Doing nothing with that jitter still leaves an output of 0.700 ms, even when a great streamer is used.

Because we all are connected to internet servers, we all face the same issue, the input signal from outside the house contains jitter

What are possible solutions for that?

Number one: is using a USB connection from the streamer to the dac. A toslink, or coax are ones and zero's and the difference with USB is that the latter one sends data packages and information which will later be translated in a jitter free digital signal. How effective is this? And moreover, the streamer has also an internal clock, which introduces again some timing errors.

Secondly what Silent angel does: it has a separate clock input from all streamers and switches which makes the ethernet connection free from all timing errors. My thing is that you have to stick with their hardware. All motherboards, switches etcetera don't have such an external clock input which makes the more hobby DIY self build unusable. But what I prefer is the less is more method: they use a separate Roon core and Roon streamer. I like to go for a shorter way, hooking directly a dac to the Roon server, in which the switch and the Roon core are external clocked. There are computer boards that can be clocked external, but they are not powerful enough for a Roon core, or they are far away out of my budget.

Finally: are there other suggestions: There are more brands with an external clock input, so that also would be a nice option.

Okay, so, a coupla things....foundational points.

1) The "signal" from a digitally-encoded music file is not a series of 0's and 1's. The only thing that is "digital" is the encoding of the music file, itself. The "signal" sent from the music server to the Ethernet switch and then downstream to a network bridge, streamer and/or DAC, etc. is an analog square wave voltage, typically with 0V representing a "0" in the digital "file" and +2V representing a "1". And, with respect to "jitter" there are different types of jitter. The one you've referred to above is likely "deterministic" jitter but there is also random jitter, and importantly for reproduction of digitally-encoded music, threshold jitter. Threshold jitter is important because it results in timing errors, which our brains are exquisitely sensitive to when listening to digitally-encoded music. We can hear timing errors in the picosecond time-domain, which is why our digital music devices require femtoclocks.

The impact of some of these noise factors looks like this:


This drawing shows the impact of jitter on the "timing" of the music signal.


Another key noise factor that is audible is phase noise, which looks like this, and can result timing errors, which as mentioned above, we are very, very sensitive to when linsteing to music.


Moreover, all metal-conductor (copper, silver, etc) based digital cables, including Ethernet and USB, are susceptible in carrying these noise factors, and well as low-and high-source impedance leakage current. In particular, the high-source impedance leakage current is problematical because it results in the threshold jitter referenced above. You can read about the influence of high-source impedance leakage and threshold jitter in a white paper by EtherREGEN designer and professional Ethernet engineer, John Swenson, here: https://shorturl.at/l0146

A very effective way to mitigate the impact of leakage current and threshold jitter is to send the file data via LC/LC optical fiber from the music server, Ethernet switch, etc. to the downstream (in the audio rack, that is) network bridge, streamer, and/or streamer/DAC. The advantage of optical fiber, is because the data is encoded as light signals, by definition, it can't carry low-and high-source impedance leakage current (though it can still have phase noise from any crap, upstream clocks in generic digital devices e.g. routers, switches, generic FMCs, etc.)

In addition the various types of jitter and phase noise, digital cables, including Ethernet, USB, S/PDIF, etc also carry common-mode noise, so you have to manage that as well.



Reference for impact of Common-mode Noise for audio applications: https://community.element14.com/lear...o-applications

So, once the music file data is sent from the "upstream" music server computer, e.g. via optical fiber, downstream to the network bridge or stream in or near the main audio rack, you want to mitigate common-mode noise using the appropriately-designed Ethernet and USB cables.

This should help to clarify some key points. Cheers.