GUSTARD DAC-R26 Balanced Decoder R2R+1Bit Dual Native Decoding Music Bridge

[BShaw]

Depends on if they're being transmitted asynchronously or not

Over LAN 1 bit, a nanosecond wait, then a 0 bit will be interpreted as the same signal as 1 bit, two nanoseconds wait, then a 0 bit.
For audio over USB those would be two different signals.

Edit:
No, to answer your second question, it's not the bits that are changing. If the computer sends 1011, it's very likely the DAC gets 1011 BUT let's consider waveforms not only have amplitude (the data value) but frequency (the timing) as well. If I send 1011 and then 1100 with two nanoseconds inbetween them, that's not same signal as 1011 and 1100 with one nanosecond between them. The wave with the 2 nanosecond gap has half the frequency as the one nanosecond gap.

This is not an issue for LAN because the audio is decoded internally using the DAC's clock, unlike USB which has the timing info in the transmitted signal. This is why we need DDCs for USB but not for LAN, DDCs collect all the bytes sent over USB in a buffer and then reclocks them using the internal clock, making it no longer dependent on the USB clock.

Summary:
-Audio over USB has a timing component in the signal being transmitted.
-Jitter can stretch or shorten audio waveforms over USB by altering that timing component.
-Audio over LAN does not have a timing component, the DAC generates the timing of the waveform using its internal clock.
-Since the LAN signal doesn't have any timing, Ethernet jitter doesn't affect timing of the audio.
-In both USB and LAN, the actual value of the bits arrive at the DAC the same (with a small possibility of bit loss on USB)

In conclusion anything that affects the timing that bits arrive over LAN (like jitter) should not affect the end audio signal. Anything that affects the internal circuitry of the DAC (like noise basically anywhere, on the ground, on the clock, on the output, etc) will affect the end audio signal. Extra packets arriving at the DAC from things like multicast should not affect the audio signal unless somehow these additional packets lead to previously mentioned noise that does affect the signal.

That was excellent gammi, very clearly explained, thank you.

 

[gammi]

A very simplified way to think of it is this:
-Imagine transferring a file over USB. If you copy music.mp3 to a flash drive, it's the same file whether it took 1 minute or 15 to copy.
-Now imagine "playing" the file over USB. It's now a waveform and unlike files, waveforms have timing. If all the same bits arrive but at different times, it's now different audio.

Very roughly put, audio over LAN is like sending an audio file whereas audio over USB is like playing the audio waveform.

Thus any jitter/noise streaming over LAN doesn't affect the data that gets to the DAC. BUT if that noise propagates into the internals of the DAC, it affects the DAC recreating the audio waveform. FMCs work by isolating the DAC from any router/PC noise, and it makes sense why that would be an improvement.

 

[Dandoudou]

Depends on if they're being transmitted asynchronously or not

Over LAN 1 bit, a nanosecond wait, then a 0 bit will be interpreted as the same signal as 1 bit, two nanoseconds wait, then a 0 bit.
For audio over USB those would be two different signals.

Edit:
No, to answer your second question, it's not the bits that are changing. If the computer sends 1011, it's very likely the DAC gets 1011 BUT let's consider waveforms not only have amplitude (the data value) but frequency (the timing) as well. If I send 1011 and then 1100 with two nanoseconds inbetween them, that's not same signal as 1011 and 1100 with one nanosecond between them. The wave with the 2 nanosecond gap has half the frequency as the one nanosecond gap.

This is not an issue for LAN because the audio is decoded internally using the DAC's clock, unlike USB which has the timing info in the transmitted signal. This is why we need DDCs for USB but not for LAN, DDCs collect all the bytes sent over USB in a buffer and then reclocks them using the internal clock, making it no longer dependent on the USB clock.

Summary:
-Audio over USB has a timing component in the signal being transmitted.
-Jitter can stretch or shorten audio waveforms over USB by altering that timing component.
-Audio over LAN does not have a timing component, the DAC generates the timing of the waveform using its internal clock.
-Since the LAN signal doesn't have any timing, Ethernet jitter doesn't affect timing of the audio.
-In both USB and LAN, the actual value of the bits arrive at the DAC the same (with a small possibility of bit loss on USB)

In conclusion anything that affects the timing that bits arrive over LAN (like jitter) should not affect the end audio signal. Anything that affects the internal circuitry of the DAC (like noise basically anywhere, on the ground, on the clock, on the output, etc) will affect the end audio signal. Extra packets arriving at the DAC from things like multicast should not affect the audio signal unless somehow these additional packets lead to previously mentioned noise that does affect the signal.

Factually, there are many wrong things in what you said.
I will only enumerate a few:
- The USB transfer does not have timing in the signal being transmitted. The clock of the DAC controls the timing of the USB packets that are transmitted and buffered.
- Over USB, the DATA is not an audio signal, and is not transferred to the DAC in a waveform, but in packets of binary DATA.
- Over the LAN, the sound is also transferred as binary DATA by Ethernet packets. The transfer can be synchronous or asynchronous, depending on the streaming protocol being used. In the case of an asynchronous protocol, the clock of the Ethernet network module of the endpoint (the streamer) is the master.
- Unlike a USB transfer, which is a direct transfer between two devices controlled by a single clock, on the LAN, the packets pass through a multitude of devices: router, switches, eventually FMCs… and each of them has its own clocks that synchronize the streamed packets. They produce jitter in the LAN transmission.
- The DATA in USB transmission contains a rendered sound that arrives to the DAC in the form of USB packets. In LAN transmission, the sound needs to be rendered first. That's the job of the streamer, and it precedes the DAC.
- Upstream jitter is difficult to eliminate completely. In the best case, it is reduced when the sound is clocked, after being rendered. The better the clock, the lower the jitter.
- If the streamer is connected to the DAC by coaxial or I2S, the DDC of the streamer clocks the sound. If it is connected by USB, it's the clock of the DAC that clocks it.

EDIT
You may be confusing coaxial connection with USB connection, when you are saying that there's a timing component in the audio that is transferred through USB… Through USB, the sound is not transferred neither in the form of PCM or DSD, but as USB packets of binary DATA.

 

[gammi]

Factually, there are many wrong things in what you said.
I will only enumerate a few:
- The USB transfer does not have timing in the signal being transmitted. The clock of the DAC controls the timing of the USB packets that are transmitted and buffered.
- Over USB, the DATA is not an audio signal, and is not transferred to the DAC in a waveform, but in packets of binary DATA.
- Over the LAN, the sound is also transferred as binary DATA by Ethernet packets. The transfer can be synchronous or asynchronous, depending on the streaming protocol being used. In the case of an asynchronous protocol, the clock of the endpoint (the streamer) is the master.
- Unlike a USB transfer, which is a direct transfer between two devices controlled by a single clock, on the LAN, the packets pass through a multitude of devices: router, switches, eventually FMCs… and each of them has its own clocks that synchronize the streamed packets. They produce jitter in the LAN transmission.
- The DATA in USB transmission contains a rendered sound that arrives to the DAC in the form of USB packets. In LAN transmission, the sound needs to be rendered first. That's the job of the streamer, and it precedes the DAC.
- Upstream jitter is difficult to eliminate completely. In the best case, it is reduced when the streamer renders the sound and clocks it.

1) "The DAC controls the timing of the USB packets". Ok, so you agree with me the USB transfer has a timing element to it.
2) I only called it a waveform in my rough analogy which was not meant to be taken literally. But if we want to get semantic, what's being transmitted over USB is a waveform since it has amplitude(the bits) and frequency (timing)
3) Yes, it is called "asynchronous" in that case but that's a bad name since it still is synchronized with the DAC clocks. Asynchronous in USB terms just means not synchronized to the host but it is still synchronous in the the sense that it's synchronized to the client's (DAC's) clocks. LAN doesn't have this synchronization, the streamer doesn't care how long packets take to arrive. And when I say it's not synchronous, I mean in the sense that timing doesn't affect the interpretation of the packets. I'm not referring to the clock rate that determines how fast packets are sent.
4) Who cares if the packets pass through a hundred devices and have seconds worth of jitter if jitter doesn't affect LAN audio because LAN audio doesn't care about timing like USB does? This is the core of my point.
5)Man come on, you're so close to the point here. The streamer renders the audio inside the DAC's case, AFTER the PC and router! Thus the timing of the rendered signal cannot be corrupted by jitter in the router or PC like it can be with USB which renders BEFORE all that. How can the router corrupt the rendered music if it isn't rendered until it's in the DAC? LAN packets are not corruptible, rendered audio signals are. Again, this is my point.
6)As said before, I agree jitter is present in both USB and LAN, what I said was that jitter doesn't affect LAN because jitter affects timing and the packets being sent over LAN don't care about timing.

That's all I have to say, I've hit my quota for internet semantics for the week.

 

[Dandoudou]

I don't have time to argue, and to correct the mistaken statements in this new input, after correcting only partially the one that preceded it.

That's all I have to say, I've hit my quota for internet semantics for the week.

Since you edited your post to add this sentence, after I posted my answer, I'll ask a question.

Why people report on this thread, and elsewhere, an improved sound, after upgrading their streaming setup with a better switch, a better model of FMCs or better SFP modules?
Food for thought…

 

[Jake2]

- Unlike a USB transfer, which is a direct transfer between two devices controlled by a single clock, on the LAN, the packets pass through a multitude of devices: router, switches, eventually FMCs… and each of them has its own clocks that synchronize the streamed packets. They produce jitter in the LAN transmission.
- Upstream jitter is difficult to eliminate completely. In the best case, it is reduced when the sound is clocked, after being rendered. The better the clock, the lower the jitter.

@Dandoudou as you know I'm in no way sceptical of the fact that upstream network changes can have very audible effects, goodness I've experienced enough of em.

I've previously heard the upstream jitter point you made also made by a number of credible sources - incl John Swenson in his EtherRegen white paper and Hans Beekhuyzen on his switches jitter vid.

However I've yet to hear a satisfactory - to me - fully articulated explanation of how upstream 'jitter' arising from the processing of various upstream devices can be transmitted to (or manifest at) the endpoint, provided the integrity of the packets - with the amplitude and timing data contained therein - remains intact. It may well be a limitation of my comprehension of what can be a technical topic.

I asked the question of Hans in the YT comments but got no response. Can you explain this to me. Genuine question as I'm still trying to build a sufficiently detailed mental model of an ethernet chain that properly explains what I hear.

A hot off the press example of a non-subtle switch related audio change I'd love to be able to explain by a clear mental model: I've been experimenting with a bunch of A5 sheets of fo.Q vibration damping material. Very effective on the chassis of my power and pre amps, the R26 and my OCK-2, oh and on top of my speakers. Seriously impressive increases in focus, refinement and dynamics.. everything tightens up, whilst in the case of the digital components, everything becomes more palpable. Those fo.Q guys know their shizzle.

So believe it or not, untill 5 mins ago I'd never gotten around to trying a sheet on my SW-8 switch. Damn. Jana Horn's vocals on On the Window in the Dream became that much sweeter, more full bodied and palpable, the music had a more effortless flow whilst the soundstage is more expansive. Bass lines are more weighty too. My power amp is not getting it's second fo.Q sheet back, it's that effective on the SW-8 switch, I'm actually gobsmacked.

To clarify I'm talking about the effect of vibration damping a switch that is directly connected to my R26. Not subtle at all.

 

[gammi]

Since you edited your post to add this sentence, after I posted my answer, I'll ask a question.

Why people report on this thread, and elsewhere, an improved sound, after upgrading their streaming setup with a better switch, a better model of FMCs or better SFP modules?
Food for thought…

That was in my original post, I didn't edit that in and I already commented on people hearing an improvement. I don't think we as an audio community have any scientific explanation for why some of these things improve the sound or at least are perceived as doing so.

I think Jake2's answer is where we'll have to leave it, simply one of those things we don't have an answer for, maybe placebo, maybe not and there's some electrical phenomenon we haven't considered.

Doesn't necessarily mean it's wrong, it could either be wrong or we just don't have an explanation yet. If there's some unknown way jitter on the data line is propagating into the the DAC circuitry then yes, it could have an effect. But just like Jake2, I have yet to see anyone give a logical answer for how that happens. We do have an explanation for your FMC question though, the second FMC has an electrical connection to the DAC, not an optical one. Noise can propagate from the second FMC to the DAC.

If someone could explain how removing multicast packets and other router related non-music packets on the LAN improves the sound, I would appreciate that. That's still an outstanding question for me, maybe I'm missing something. Would think those packets just get dropped and never get past the streamer circuitry.

 

[camrector]

I don't think we as an audio community have any scientific explanation for why some of these things improve the sound or at least are perceived as doing so.

Of course we do. People don’t like the answer though and continue to believe in mysticism and marketing.

 

[DeckHiFi]

Has anyone compared the Holo Red/external streamer with Gustard R26 vs a Singxer SU-6 with the R26? I wonder if the lan input is really needed to get the full benefits of people liking the I2S.

 

[Dandoudou]

That was in my original post, I didn't edit that in and I already commented on people hearing an improvement. I don't think we as an audio community have any scientific explanation for why some of these things improve the sound or at least are perceived as doing so.

Yes, you did. Never mind…

@Dandoudou as you know I'm in no way sceptical of the fact that upstream network changes can have very audible effects, goodness I've experienced enough of em.

I've previously heard the upstream jitter point you made also made by a number of credible sources - incl John Swenson in his EtherRegen white paper and Hans Beekhuyzen on his switches jitter vid.

However I've yet to hear a satisfactory - to me - fully articulated explanation of how upstream 'jitter' arising from the processing of various upstream devices can be transmitted to (or manifest at) the endpoint, provided the integrity of the packets - with the amplitude and timing data contained therein - remains intact. It may well be a limitation of my comprehension of what can be a technical topic.

I asked the question of Hans in the YT comments but got no response. Can you explain this to me. Genuine question as I'm still trying to build a sufficiently detailed mental model of an ethernet chain that properly explains what I hear.

I'm not a network engineer. I'll tell you how I understand it, after reading, testing, and discussing this topic with other people for a while.

When you stream DATA, it is transferred by Ethernet packets from a server to an endpoint. On their way, the packets pass through switches, and eventually the router. At each step, there are error correction checks… Each time there is an error, it is corrected, and in the end a bit-perfect transfer of the DATA from the server to the endpoint occurs.
If you stream a file, of a photo for instance, the endpoint will receive the precisely same file. The streaming starts, and ends, and the file has been transferred.
The higher the efficiency of the synchronization clocks of the devices along the streaming path, the lower the jitter of the Ethernet packets.
Of course, jitter does not matter for a photo or another kind of file.

But when you stream audio or video, it's a continuous flux of DATA that does not stop, as long as you continue to listen or to watch.
The clocks of the kind of routers that we have, and the switches for office appliances, are not efficient enough to synchronize and to error correct such continuous flux of Ethernet packets, while keeping jitter low.
The router is particularly problematic regarding jitter, because its clocks handle simultaneously the synchronization and error correction of other fluxes: of all the devices at your home that stream on the network or are connected to the internet. (TV decoder, phones, tablets, computers, printers…) It's not a constant jitter. It evolves, and changes, with the activity of other devices on the network at your home.
The same thing applies to the clocks of the standard FMCs. But through these devices the DATA is not only streamed, a conversion of the Ethernet packets to optical and back to electrical is also processed. These conversions are jittery (In another context, Toslink is often the less performing input of a DAC for this same reason.)

Unless you optimize your whole streaming setup, as I tend to do with mine by improving it continuously, a simple way to reduce a lot of jitter is to put a good switch just before the endpoint to better synchronize the Ethernet packets before they are transferred to it.

 

[camrector]

Since you edited your post to add this sentence, after I posted my answer, I'll ask a question.

Why people report on this thread, and elsewhere, an improved sound, after upgrading their streaming setup with a better switch, a better model of FMCs or better SFP modules?
Food for thought…

Because.
1. Noise is lowered
2. there minds tell them to after they spent a bunch of money.
3. intermodulation and clocking artifacts produce harmonic distortion that people find pleasing

The higher the efficiency of the synchronization clocks of the devices along the streaming path, the lower the jitter of the Ethernet packets.

This is not true.
Jitter in a network is from latency. It’s not affecting the packets.

 

[gammi]

Of course we do. People don’t like the answer though and continue to believe in mysticism and marketing.

I think we're saying the same thing, our current logical explanation says jitter over LAN should not affect the sound.
I'm just saying it's possible there is some as of yet unknown effect at play here. Like we can't know what we don't know. Ya know?

So until someone proves otherwise using proper engineering reasoning or at the very least repeated back to back blind testing instead of just "sounds better to me" I will continue to believe jitter doesn't affect streaming over LAN. Comparing with our ears is so inconsistent, some days I swear my system sounds better like I upgraded something when nothing has even been touched.

I'm not a network engineer. I'll tell you how I understand it, after reading, testing, and discussing this topic with other people for a while.

[...]

Unless you optimize your whole streaming setup, as I tend to do with mine by improving it continuously, a simple way to reduce a lot of jitter is to put a good switch just before the endpoint to better synchronize the Ethernet packets before they are transferred to it.

You are once again explaining how jitter is introduced over LAN and not why it affects the sound. Nobody disagrees that LAN has jitter, anything with a clock has jitter, we disagree that it affects the sound like it does over USB.

 

[camrector]

I think we're saying the same thing, our current logical explanation says jitter over LAN should not affect the sound.
I'm just saying it's possible there is some as of yet unknown effect at play here. Like we can't know what we don't know. Ya know?

So until someone proves otherwise using proper engineering reasoning or at the very least repeated back to back blind testing instead of just "sounds better to me" I will continue to believe jitter doesn't affect streaming over LAN. Comparing with our ears is so inconsistent, some days I swear my system sounds better like I upgraded something when nothing has even been touched.


You are once again explaining how jitter is introduced over LAN and not why it affects the sound. Nobody disagrees that LAN has jitter, anything with a clock has jitter, we disagree that it affects the sound like it does over USB.

Oh agreed.
My post above explains why a difference is heard especially with external clocks and DDCs. The science, math and research is there to back it up. Yet show some one this and your called names, insulted, and banned for forums.
It’s important to remember that even Headfi here has to kowtow to these companies so you’re threading dangerous water speaking the truth lol.

 

[Dandoudou]

You are once again explaining how jitter is introduced over LAN and not why it affects the sound. Nobody disagrees that LAN has jitter, anything with a clock has jitter, we disagree that it affects the sound like it does over USB.

For the USB port, you developed a theory that entirely relies on misunderstanding, and wrong assumptions.
But on what do you base your opinion regarding the jitter on the LAN?

 

[gammi]

For the USB port, you developed a theory that entirely relies on misunderstanding, and wrong assumptions.
But on what do you base your opinion regarding the jitter on the LAN?

I wrote probably 500-1000 words detailing jitter on LAN vs USB on the previous two pages. If you believe what I said to be wrong, that's fine and we disagree, but I'm not going to repeat it.

Edit: I thought up a good test for LAN jitter resistance. Literally unplug the LAN while you're streaming and be amazed that it continues playing just fine for a bit. Now try that with USB... If LAN can withstand being unplugged for a few seconds then certainly it doesn't care about the microseconds of latency that jitter introduces.

Here is my version of EMI shields.
3 layers - 2 copper and 1 amorphous metal.
Great results - more tranparent sound and detailed timbre.

Just catching up with this, very cool and I'm thinking of doing this myself (lots of electronics in my room). One thought, since the shield is grounded to the same ground as the DAC internals, would it possibly be better to ground externally to a separate ground? It's probably a very small effect but I wonder if the EMF getting sinked to the internal ground could introduce noise on the ground. Like you've basically connected a giant copper EMF/noise "lightning rod" to your DAC's ground and all EMF is going into your ground.