Most effective way to remove jitter

[NewAlkyogre]

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.

 

[Puma Cat]

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/learn/learning-center/the-tech-connection/w/documents/28100/how-to-reduce-common-mode-noise-in-audio-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.

Hope this helps to clarify some key points. Cheers.

 

[NekoAudio]

Received jitter on the digital audio input pretty much only translates into timing errors of the analog output if the digital audio signal jitter (i.e. S/PDIF) carries through to the DAC chip's clock pin. That tends to no longer be an issue with the majority of DAC products today. It was more common a problem when S/PDIF receivers phase lock loop was used to directly drive the DAC chip's clock pin, often with no buffer to speak of. But these days it is usually only used to derive the transmitting clock and recover the digital audio data, which is then buffered and fed to the DAC chip using an internal clock. The edge case is if the data completely underruns or overruns but that is generally not a concern.

The packet-based nature of network communications and the use of relatively very large network buffers means network jitter should not become digital audio signal jitter. If the network buffer runs out, then you'll get an interruption in the music playback. A low amount of buffered network data does not result in the playback being "slowed" to let things catch up, and playback also isn't "sped up" to try and drain a full network buffer.

USB audio uses error detection but does not use error correction or retransmit. So in the (should be very unlikely) case a USB audio data packet was corrupted during transit, that portion of audio will be missing. Roon RAAT, and most modern network audio streaming protocols are using error detection and retransmit (either by design or because of the underlying transport protocols used), and so should be the most reliable.

 

[nicoff]

Received jitter on the digital audio input pretty much only translates into timing errors of the analog output if the digital audio signal jitter (i.e. S/PDIF) carries through to the DAC chip's clock pin. That tends to no longer be an issue with the majority of DAC products today. It was more common a problem when S/PDIF receivers phase lock loop was used to directly drive the DAC chip's clock pin, often with no buffer to speak of. But these days it is usually only used to derive the transmitting clock and recover the digital audio data, which is then buffered and fed to the DAC chip using an internal clock. The edge case is if the data completely underruns or overruns but that is generally not a concern.

The packet-based nature of network communications and the use of relatively very large network buffers means network jitter should not become digital audio signal jitter. If the network buffer runs out, then you'll get an interruption in the music playback. A low amount of buffered network data does not result in the playback being "slowed" to let things catch up, and playback also isn't "sped up" to try and drain a full network buffer.

USB audio uses error detection but does not use error correction or retransmit. So in the (should be very unlikely) case a USB audio data packet was corrupted during transit, that portion of audio will be missing. Roon RAAT, and most modern network audio streaming protocols are using error detection and retransmit (either by design or because of the underlying transport protocols used), and so should be the most reliable.

TL;DR? Jitter is no longer a boogeyman

 

[Lee Scoggins]

Received jitter on the digital audio input pretty much only translates into timing errors of the analog output if the digital audio signal jitter (i.e. S/PDIF) carries through to the DAC chip's clock pin. That tends to no longer be an issue with the majority of DAC products today. It was more common a problem when S/PDIF receivers phase lock loop was used to directly drive the DAC chip's clock pin, often with no buffer to speak of. But these days it is usually only used to derive the transmitting clock and recover the digital audio data, which is then buffered and fed to the DAC chip using an internal clock. The edge case is if the data completely underruns or overruns but that is generally not a concern.

The packet-based nature of network communications and the use of relatively very large network buffers means network jitter should not become digital audio signal jitter. If the network buffer runs out, then you'll get an interruption in the music playback. A low amount of buffered network data does not result in the playback being "slowed" to let things catch up, and playback also isn't "sped up" to try and drain a full network buffer.

USB audio uses error detection but does not use error correction or retransmit. So in the (should be very unlikely) case a USB audio data packet was corrupted during transit, that portion of audio will be missing. Roon RAAT, and most modern network audio streaming protocols are using error detection and retransmit (either by design or because of the underlying transport protocols used), and so should be the most reliable.

It’s not so much about jitter these days, as long as it’s down to single digit picosecond in level, but about noise coming in. That’s why the better ethernet switches like Ansuz and others are so effective.

 

[DSMSB]

The packet data transfer system inherent in the design of Ethernet and similar networking protocols is so jittery by design that you cannot hope for any semblance of playback directly from that data. Its so bad that if you were to somehow connect up the data from an Ethernet receiver directly to a DAC chip without buffering and reclocking there would be tiny busts of playback with silences in between at nearly random intervals. It is up to the receiving computer (renderer, server, etc...) to buffer that data in local memory and stream it out synchronously to the DACs conversion clock. Even the process of transferring data to the actual conversion hardware from the host computer is usually extremely jittery. For example, USB uses a packet protocol that is unbelievably jittery from a DACs point of view. Groups of packets come in quickly from the host computer, then when a local buffer becomes empty enough to fit another burst of packets the USB receiver signals the host computer to send some more data, when the host computer is not too busy with another task it will send anther burst of audio data (this happens with completely unpredictable timings). So even USB data must be held in local memory and re-timed onto an internal synchronous streaming protocol such as I2S in the DAC. Trying to reduce the jitter of any computer data protocol before data is in the DAC box is completely and utterly futile because the basic design of the protocol do not allow any jitter reduction at all...

Noise reduction is a different but related story. Computer hardware tends to generate tons of electrical noise, and that noise can affect the analog signals directly and indirectly (by affecting the conversion process). I have found that any electrically conductive signal path from a computer(of any form, even an embedded renderer) to a DAC always includes enough noise to degrade sound quality at least some, and more often a lot. Even though Ethernet uses transformers to isolate network segments, noise still comes through to the receiving computer. Even a low power embedded renderer in a DAC always generates significant noise itself, just by running the software stack necessary for data reception. USB is even worse because it is a direct electrical path for noise from the computer to the DAC. Basically the only way to get rid of the noise is to use isolation of some sort, preferably an optical isolation. But an optical connection using a protocol such as Ethernet (or isolated USB) just moves the noise source to the proximity of the DAC circuitry again, meaning it is impossible to get rid of the computer generated noise if you use a computer data protocol, full stop. What is required is an audio only data streaming protocol on an optical medium. Such a streaming protocol would ideally use a clock for the physical data transfer layer that is synchronous to the DACs internal conversion clock so that noise and jitter can both be eliminated simultaneously. It should also be easily decoded with low noise hardware so as not to disturb the local electrical environment inside the DAC. That is the only way I know of to eliminate computer generated noise from an audio playback system.

Another possible way to reduce the effect of digitally induced noise in a system is to use balanced analog signaling to reduce the noise present at the point of amplification. Another strategy is to filter out the noise present in the analog signal. However this still does not affect the noise and distortions generated by DAC hardware that is itself sensitive to electrical noise. This is also only a finite reduction of noise due to the finite capabilities of the electrical circuits that transmit and receive analog signals.

 

[NewAlkyogre]

Ty for all replies. The reason I responded so late is because all answers really become technical and complicated for me, and am a bit lost.

What surprised me is that usb isnÂ’t that perfect I thought, and what is important is the amount if noise. Heard that even the light on the button influences audio quality, do little that no one can separate them apart.

Currently I have it this way:

Glas fibre in the house, modem —router—silent angel bonn switch, nuc with roon server, usb connection, dac etcetera

How to improve? Is it s good idea to use USB? Isn’t it the wrong “streamer” and is the usb the right choice, because read above some doubts. I2s and digital coax are also s alternatives.

If this nuc will be replaced, in general what is the best choice, not looking at the price?

- a low current streamer, like a raspberry pi based system, with galvanic seperation snd the right shielding
- an optical fibre streamer, like the sonore optical rendu.
- a high end streamer with great clocks, for instance a lumin, or for my part grimm, melco, eversolo, and what is the preferred output digital connection?
- a high end well designed audio pc with own protocols, like the taiko?

And a second thing, how important is the dac in this story? If the noice is reaching that and the buffering and reclocking is done there. It is the final stage before getting analogue.

 

[NekoAudio]

I guess if price (and existing products) are not a restriction, then theoretically you'd want a dedicated streamer with built-in DAC that uses a fiber (optical) network connection. Assuming the separate internal subsystems are all built with mechanical and electrical isolation, that eliminates multiple potential problems. You don't have an electrically coupled network interface, you have zero interconnect cables running a digital audio signal, the shortest signal paths are used, and all of the clocks involved are synchronized.

You could take it one farther and make it an all-in-one system to eliminate any potential noise or degradation from analog audio cables.

 

[Fer1000]

Recently here in Buenos Aires we have tested an Ethernet noise Insulation by Aadvark with significant improvement. May be you can give it a chance. Find bellow the link and there you can find Dealers in USA and UK.

Aardvark - Ethernet Noise Isolation

 

[W9TR]

I guess if price (and existing products) are not a restriction, then theoretically you'd want a dedicated streamer with built-in DAC that uses a fiber (optical) network connection. Assuming the separate internal subsystems are all built with mechanical and electrical isolation, that eliminates multiple potential problems. You don't have an electrically coupled network interface, you have zero interconnect cables running a digital audio signal, the shortest signal paths are used, and all of the clocks involved are synchronized.

You could take it one farther and make it an all-in-one system to eliminate any potential noise or degradation from analog audio cables.

This is exactly the correct technical solution. Eliminate all the electrical interfaces between home network, streamer, and DAC. Go optical Ethernet directly into a streamer/DAC combo.

The conversion of switched Ethernet audio to S/PDIF, AES/EBU, and asynchronous isochronous audio USB is a trivial D to D format conversion. Putting a bunch of computing crap in a streamer is very popular because it has become a pretty box that can be branded and sold separately from a DAC. There is no real reason for this, except perhaps to provide a unique user experience in terms of a nice display and shiny buttons to press. And a proprietary app experience.

 

[Puma Cat]

I guess if price (and existing products) are not a restriction, then theoretically you'd want a dedicated streamer with built-in DAC that uses a fiber (optical) network connection. Assuming the separate internal subsystems are all built with mechanical and electrical isolation, that eliminates multiple potential problems. You don't have an electrically coupled network interface, you have zero interconnect cables running a digital audio signal, the shortest signal paths are used, and all of the clocks involved are synchronized.

You could take it one farther and make it an all-in-one system to eliminate any potential noise or degradation from analog audio cables.

and...

This is exactly the correct technical solution. Eliminate all the electrical interfaces between home network, streamer, and DAC. Go optical Ethernet directly into a streamer/DAC combo.

And, you gents have very clearly articulated some key foundational reasons why I sold my previous "set-up" and went with a Lumin P1, which provides the "streamer", DAC, and preamp functions for my system. Instead of the really complicated set-up I had before (using my SoTM Network bridge, FMCs, and all sorts of other cables, power supplies, power cables for the power supplies, blah, blah, blah, ay me! ), now in the remote server room, Alita the music server connects to ER with an Ethernet cable, & I simply run one LC/LC optical out of EtherREGEN straight into the back of the P1. Connect the P1 to the Constellation integrated with a single pair of ICs, and...job done!

Nice thing is, it ALWAYS works. Connect up the Altairas, and the system sounds absolutely fabulous.

Or, in the words of Austin Powers, International Man of Mystery: "Yeah, baby, yeah!"

 

[NekoAudio]

And, you gents have very clearly articulated some key foundational reasons why I sold my previous "set-up" and went with a Lumin P1, which provides the "streamer", DAC, and preamp functions for my system.

Yep. Another excellent option is the Devialet Expert Pro.

 

[NewAlkyogre]

Recently here in Buenos Aires we have tested an Ethernet noise Insulation by Aadvark with significant improvement. May be you can give it a chance. Find bellow the link and there you can find Dealers in USA and UK.

Aardvark - Ethernet Noise Isolation

This is what really makes sense. Still haven't tested these ethernet noise insulations.

and...


And, you gents have very clearly articulated some key foundational reasons why I sold my previous "set-up" and went with a Lumin P1, which provides the "streamer", DAC, and preamp functions for my system. Instead of the really complicated set-up I had before (using my SoTM Network bridge, FMCs, and all sorts of other cables, power supplies, power cables for the power supplies, blah, blah, blah, ay me! ), now in the remote server room, Alita the music server connects to ER with an Ethernet cable, & I simply run one LC/LC optical out of EtherREGEN straight into the back of the P1. Connect the P1 to the Constellation integrated with a single pair of ICs, and...job done!

Nice thing is, it ALWAYS works. Connect up the Altairas, and the system sounds absolutely fabulous.

Or, in the words of Austin Powers, International Man of Mystery: "Yeah, baby, yeah!"

This is not the way I like to go, prefer several components, instead of an all in one solution. The reason is that the power usage from one part cannot influence the other build in component by electromagnetic radiation. What I was thinking is a dedicated streamer/pc that uses hardly no power, where the machine can be separately powered by an lps and the streamer can be connected to an external clock.

This is exactly the correct technical solution. Eliminate all the electrical interfaces between home network, streamer, and DAC. Go optical Ethernet directly into a streamer/DAC combo.

The conversion of switched Ethernet audio to S/PDIF, AES/EBU, and asynchronous isochronous audio USB is a trivial D to D format conversion. Putting a bunch of computing crap in a streamer is very popular because it has become a pretty box that can be branded and sold separately from a DAC. There is no real reason for this, except perhaps to provide a unique user experience in terms of a nice display and shiny buttons to press. And a proprietary app experience.

optical input to the dac is impossible for me. The ISP converts glass fiber into a normal ethernet cable. This modem cannot be replaced and moreover, the house has corners, and you cannot bend light cables, because then it breaks.

 

[NekoAudio]

This is not the way I like to go, prefer several components, instead of an all in one solution.... where the machine can be separately powered by an lps and the streamer can be connected to an external clock.

Theory does run into reality. But there are certainly companies and products that do an excellent job getting close.

With respect to an external clock, as I'm sure you're also aware, it matters how the clock is used and how the clock lines are implemented inside the devices you are all running off the external clock. Since the goal is to synchronize all the devices communicating with each other.

optical input to the dac is impossible for me. The ISP converts glass fiber into a normal ethernet cable. This modem cannot be replaced and moreover, the house has corners, and you cannot bend light cables, because then it breaks.

You only really need to electrically decouple the last part. The data itself should arrive without any loss of fidelity.

 

[NewAlkyogre]

Do you have examples of such a system (router/switch) that converts lan back into glass fiber?

 

[jmusica]

There are a few ways to approach this:

1. a streamer or DAC/streamer like the Lumin X1 that have a port for a fiber transceiver, with a network switch with a port for a fiber transceiver (I have SoTM but there are others)

2. copper (i.e. standard ethernet cable) > fiber converters (Blackbox sells them as well as others on Amazon), which will at least get you closer by eliminating most of the copper cable, even if your network switch and streamer/DAC only have standard copper ethernet ports

3. a mix of the above, where one side has a port for a transceiver and the other doesn't, with the optimal scenario being fiber into the streamer

Does it make a difference? Yes, imo it does. And I imagine in the opinion / measurement of vendors who integrate that feature.

 

[wklie]

Do you have examples of such a system (router/switch) that converts lan back into glass fiber?

Any "network switch with SFP" will do that.

As you may expect, I agree with all others suggesting a streamer/DAC with built-in SFP cage. If you really don't want a DAC inside the SFP streamer, we also offer Lumin U2.

For fiber, I suggest Corning from the bottom links here:
LUMIN - Fibre Networking

Internally we use fs.com Corning fiber. (May take more time to ship.)

 

[NewAlkyogre]

Any "network switch with SFP" will do that.

As you may expect, I agree with all others suggesting a streamer/DAC with built-in SFP cage. If you really don't want a DAC inside the SFP streamer, we also offer Lumin U2.

For fiber, I suggest Corning from the bottom links here:
LUMIN - Fibre Networking

Internally we use fs.com Corning fiber. (May take more time to ship.)

Finally I am able to respond, due to the slow page loading last week.

I have to say: especially the U2, I am really impressed how well it is build, and with the SFP input I love it. Hope to have somewhere a listening test for it. Noticed that Melco does have the switches for infrared network cables. The only thing is that with this streamer I will stop playing with Roon, so it can be stream directly instead of via a roon server.

 

[Puma Cat]

Finally I am able to respond, due to the slow page loading last week.

I have to say: especially the U2, I am really impressed how well it is build, and with the SFP input I love it. Hope to have somewhere a listening test for it. Noticed that Melco does have the switches for infrared network cables. The only thing is that with this streamer I will stop playing with Roon, so it can be stream directly instead of via a roon server.

Yeah, the U2 is really an excellent streamer, I've really enjoyed having it in for review. I've been using the review unit with the Corning LC/LC single-mode optical fiber that Peter recommends with a Planet Tech TL-40 single-mode transceiver, and it worked flawlessly the entire time, and sounds...GREAT. Fiber is really the way to go for streaming content from an upstream music server, in my experience. And while it supports using Roon, it sounds better when streaming the same exact file from an attached, external HD using the Lumin app.

And...it also has a proper chassis ground terminal on the rear panel so you can connect it to an Altaira hub.

Also, the bespoke "dedicated-to-audio" direct-coupled USB-A port is excellent, too, I used that direct-coupled USB-A port to connect to a Soulnote D-1N that functioned as the DAC for the review period, the experience using the two together was absolutely marvelous: tonally neutral, with superb clarity, transparency, and resolution, defined, grounded, and taut bass & lower octaves, with very accurate rendition of instrumental and vocal body & timbre, superb imaging and soundstaging, and with its internal LPS, a very quiet & black background with excellent decay and "vapor trail".

Overall, a very natural, organic, engaging, and "relaxed" presentation, as Hans Beehuizen says.

Really, just an excellent product: as you say, absolutely beautifully made and superbly engineered.

The Lumin U2 is my "go-to" recommendation for somone looking for a streamer.

"Job done!", as the Brits say.

 

[audio.bill]

@Puma Cat - Regarding your recommendation of the Lumin U2 for streaming files from an attached external HD, I have a question about how that works. My understanding was that in order to have access to the attached content with full library support you have to run server software like MinimServer, otherwise you only have basic access by the folder structure of the files on the drive. Is that your experience, or are you able to run server software on a networked PC and have it pointing to the attached USB drive as your music library? For a large collection of downloaded music having access limited to the folder structure seems quite primitive. Having the files on a NAS with server software running on a networked PC or on the NAS itself would be the other way to do it, but thought you could shed some light on the issue based on your experience with an attached USB drive on the U2. TIA!