[sajunky]

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.

Perfect. You are truly a network engineer and it is seen through all details. I have similar network exposure, I do confirm, everything is 100% correct. The same with USB.

This is agreed from my side that both Ethernet and USB deliver audio datastream asynchronously. Asynchronous means that a receiver use its own clock to control a timing of receiving data, there is no added jitter; there is no need for audio reclocking. It is like loading data from a hard drive (no matter how complicated it is on the transmission line).

There is important point of understanding that clock accuracy becomes important in the place where a continuous audio data stream is created. So by example, a network end point (streamer) or USB sink after receiving asynchronous data convert it to the I2S, S/PDIF (or AES/EBU).

Now is a question. So why (assuming there is a perfect galvanic isolation on a network connection and asynchronous delivery), clocking on the dirty side of network matters? It doesn't need to be synchronised with audio clock, but low jitter clock is beneficial, it is confirmed by many. Also using special protocols matters.

The only explanation is in a burst nature of a load on the receiver's power supply. If network frames are small and arrive in regular intervals, a noise spreading through the power supply is reduced.

 

[camrector]

Something we could all do and post results. Ping and Jitter test
https://www.fusionconnect.com/speed-test-plus

 

[Jake2]

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.

I guess one could argue the aluminium case to which the AC ground and other ground leads from the transformers etc are attached already does this - acts as an antenna/lightning rod for EMI/RFI, acknowledging it is only 60% as conductive than copper but there’s a lot greater surface area than the copper used by @St12 in his DIY shielding. Key I guess is both are properly grounded to sink away both noise and any inadvertently shorted AC.

Your general point though re the potential for noise on the ground plane is a really good one, one I’ve gone to town on addressing with very satisfying results. Including adding a separate ground rod for the hifi system via the Puritan Groundmaster (has a HPF for safety so it doesn’t pass AC frequency current to this alternate ground) and adding a Quartz Acoustics grounding box to ‘signal ground’ the R26 via its unused s/pdif output. Both additively quiet the background, improve dynamics and further reduce edginess or digital glare.

I did a mock-up of possible internal shielding a month or so back but didn’t at that time have confidence in my ability to implement without possible shorting with my flimsy copper tape and cardboard mock-up. Kudos to @St12 for just going ahead and doing it so nicely. I’m still waiting for a bunch of copper sheets of various thicknesses from AliX to arrive to give it a proper go. I’ve idly wondered about grounding the copper shielding to something other than the chassis & AC ground (eg another ground box) but felt grounding to AC earth is the prudent and safest course.

Incidentally I’d revise my shielding from my mock-up to cover that vertical circuit board on both sides as @St12 did. And likely add a lid to the ladder section to fully enclose it as he did. It’s really encouraging to hear it brought him the sort of benefits I thought it might! C’mon Aliexpress…

They say a picture is worth a thousand words... how about three! (And a few words).

This is just a mockup, will take out and triple check no conductive contacts to circuitry, add more cardboard insulators where necessary

Mk II - aiming for a one piece template (incl insulating cardboard) I can lift in and out to allow an intial AB. Some tight gaps to squeeze between so need clear line of sight so a fixed lid is a no go for this section initially at least.

Will do a final check tomorrow sans APAs (great for creativity not so much for precise electrical fault finding QA) and have a listen.

Oh and the lid still closes with just a little bit of resistance - result!

 

[gammi]

The only explanation is in a burst nature of a load on the receiver's power supply. If network frames are small and arrive in regular intervals, a noise spreading through the power supply is reduced.

This is the closest to a reasonable explanation I've seen for why varying network load would change the sound, thanks.

One counterpoint however, changes in the network is likely only varying the load on the power supply in the range of 0.1W or so. For a device like the R26 that I assume draws 25W+, a variance in load of 0.1W or even 1W shouldn't have much effect, if at all.

 

[Dandoudou]

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.

You imagined a theory that tends to explain why you get a better sound when you stream to the LAN input on your R26 rather than feeding it through its USB port. But it was based on a misunderstanding of the technical parameters, and on wrong assumptions regarding jitter.

A much better DAC than the R26, such as the Weiss 204, has only a USB input. You use it with an external streamer that is attached to its USB port. How does it fit with your theory?
Another better DAC than the R26, the Teac UD-701N, has a LAN input, and a USB input. Though the LAN input of this model performs greatly, the Teac produces the best sound when it plays local files from a drive that you attach to its USB input. It does not work as you imagined…

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.

What you are saying here has nothing to do with jitter. It's about the buffer size of the streamer. The streamer of the R26 has a relatively small buffer.

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.

1. Noise is not the only factor. You can not get a lower noise than attaching the second FMC directly to the LAN input of the streamer.
2. Believing that people are stupid is… stupid.
3. Don't spam this thread with the clocks. There's a dedicated thread for this topic that was ruined already.

The only explanation is in a burst nature of a load on the receiver's power supply. If network frames are small and arrive in regular intervals, a noise spreading through the power supply is reduced.

This is a very important point.
The lower the CPU load of the Target, the lower the electrical noise transferred to the DAC. This has a huge impact on sound quality.
Better streamers are less noisy than others. Two of my streamers have an I2S output, one has a USB output, and they all beat the built-in streamer of the R26. The reason is that they are extremely silent. They run an excellent audiophile OS, and are configured as Diretta Targets.

Diretta is a streaming technology with which the Target runs on a very low power consumption that does not vary. It is regular without bursts, because most tasks that a streamer usually performs are done upstream by a Host.

https://www.diretta.link/

 

[Jake2]

This is the closest to a reasonable explanation I've seen for why varying network load would change the sound, thanks.

One counterpoint however, changes in the network is likely only varying the load on the power supply in the range of 0.1W or so. For a device like the R26 that I assume draws 25W+, a variance in load of 0.1W or even 1W shouldn't have much effect, if at all.

With respect, I'd suggest the baseline wattage draw one compares to in such a thought experiment shouldn't be the R26 as a whole, it ought to be just the very localised average power demands of the network interface board and the internal renderer board too. But excluding the likely much larger and more remote power draw of at least the R2R ladders, the analogue stage and any heat dissipated by the transformers themselves. Even with a reduced divisor you'd likely still quite reasonably guestimate a tiny %, don't get me wrong, so you might well reasonably repeat the "should have no effect" statement. To which I might respond questioning what testing of the threshold for audibility of ground plane induced noise is this based on? I'd rather just say though I've lost count of the the number of shouldn't matter theoretical propositions that have crashed on the rocks of first hand experience the last year I've gotten back into hifi.

The great thing about Ethernet is it's super easy to test 'shouldn't matter' theories without spending much money at all. Which many of us previously sceptical folk have done.

This is also the most cogent argument I've heard to date, thanks @sajunky. It seems to me to logically consistent with:

i) potential benefits from both software-based optimisation that @Dandoudou mentions that smooth network demands; and

ii) the delivery by better powered or clocked network devices of more cleanly formed electrical square waves making the life of the next device in the chain that much easier - faster signal rise or fall time, more consistent 0/1 threshold triggering resulting in fewer errors meaning fewer packets fail the checksum, less requesting of replacement packets, less buffering whilst waiting, less demands on the recipient power supply resulting in less ground plane variation resulting in less trigger threshold errors. And so on right up to the final conversion to a synchronous stream by the internal streamer/renderer.

The two together would/could deliver the recipient ethernet device with something much closer to a synchronous data stream in other words.

Such benefits could be additive, each such quality network device making the job of the next one easier, each subsequent device producing an even more metronomic/near-synchronous stream than the last.

The above theory might explain why I and others have found stacking switches helps. Even a cheap Netgear before the LHY helps, tightening up the soundstage.

Apologies to new or prospective R26 owners landing here reading all this OT but if I say so myself - interesting - discussion .

 

[sajunky]

This is the closest to a reasonable explanation I've seen for why varying network load would change the sound, thanks.

It will be difficult to find other reason, so if we initially agree on this one, it will be at least some progress in discussion. We can always come back to this point if the other reason is found, at the moment there is none. If we don't, we can end up like in the Masterclock thread, opening a door for trolls who don't bring anything under consideration, just repeat the same stories all over again.

One counterpoint however, changes in the network is likely only varying the load on the power supply in the range of 0.1W or so. For a device like the R26 that I assume draws 25W+, a variance in load of 0.1W or even 1W shouldn't have much effect, if at all.

I don't know for sure how much these load variations on the PSU are important inside a DAC, it could be some other influence which is generally acknowledged. In Gustard there are two transformers equal size, one for digital section the other for analogue, it split total power in two. A receiver is in a digital section and perhaps there is a separate winding for the interface circuit supplying much less power, to provide some galvanic protection. It is done that way, as galvanic protection is the most important for lowering noise levels. In other words, a Gustard's huge PSU is not a counterpoint. Not a huge and I suspect a PSU load is already converted to the other form of noise.

When I came to this conclusion, I didn't mean internals of R26, but much a simpler case of the FMC, WiFi extender or a network switch. Any variations of the PSU load translate to ground loops or conversion to EMI on the power and data connections. It is on a clean side, so is important. For the same reason when recommending WiFi extender I suggest to use a small box pluggable directly to the wall socket, rather than a more sophisticated unit with a power cord.

 

[JackJohnson316]

@Dandoudou & @ericx85 It sounds like you are describing a need to “bridge” a LAN connection across from @ericx85 ‘s windows PC to his A26. Creating a network bridge is recommended by a number of folk over at Audiophilestyle as a way to improve the quality of the network connection between server and streamer. My basic understanding is the computer is actually establishing its own separate 1-1 LAN with the connected device (a much quieter network with only one type of traffic), and then this is bridged to the wider LAN, with the computer acting as a virtual switch.

I tried and failed to setup a network bridge in my Mac Mini M1 to my R26, so I can give you no guidance other than suggesting you Google how to set one up for your Win OS.

@gammi to address ethernet borne noise he could insert optical or other galvanic isolation between the PC and the A26. So one could get the benefit of both the quieter dedicated network and galvanic isolation. In fact, I suspect this may be additional explanation for why wifi bridges sound good to many.

Edit - just realised he has an A26, amended,

For my R26, I had a server with a Jcat Ethernet card that has two inputs or outputs. I used one Ethernet input and the other as an Ethernet output directly to the R26. I was using Euphony Stylus V4 and clicked the option to output to an endpoint device. Worked right away. I personally didn’t hear that it made a difference from just connecting the R26 directly to my router with a switch, but I didn’t have two quality Ethernet cables, only one. I never thought about placing a switch between my streamer and R26, but that does kind of make sense. Regardless I was able to connect my pc server directly to my router and R26 at the same time.

 

[DeckHiFi]

I feel like this is a great video for discussion which goes right after all the audiophile vs science folk thoughts/theories with a lot of these devices. There is truth to differences on what products are doing like how I2S doesn't need to unpack in the same way a USB signal does, jitter numbers between devices, and so much more. What I respect about GoldenSound here is...he isn't necessarily saying any of this is audible. He seems to have some subjective opinions thrown in there too which is fine. But he's open to the concept that this could all be a moot point if it's too low on the noise to be audible. What I would like to know from people here is - do people believe the whole I2S not needing to unpack/the language your Dac uses internally being better than USB/Lan/etc. It's a very interesting topic. Does Jitter really matter? Is I2S just the best way to go into a Dac most of the time even with similar jitter to USB? Or does I2S not matter as much as just the full jitter numbers.

The only thing I don't like about this video is I wish he did follow-up videos to this because this could be the most interesting audiophile topic. He also has the knowledge and testing ability to look into products on a very in-depth scale. He could set up really great tests with average folk and audiophiles to really get to the bottom of is any of this audible. Might not be great for business, but would be great to know the truth.

 

[camrector]

The only thing I don't like about this video is I wish he did follow-up videos to this because this could be the most interesting audiophile topic. He also has the knowledge and testing ability to look into products on a very in-depth scale. He could set up really great tests with average folk and audiophiles to really get to the bottom of is any of this audible. Might not be great for business, but would be great to know the truth.

He came in this thread to dispel some garbage which was nice.

I2S makes sense because the Dac doesn’t have to convert anything so the The idea is that less work = better SQ.
But…..
My older set up was Silent Angel Munich M1T streamer I2S direct to a Pontus 2.
The R26 was ALOT better using its internal streamer and LAN.

 

[gammi]

I feel like this is a great video for discussion which goes right after all the audiophile vs science folk thoughts/theories with a lot of these devices. There is truth to differences on what products are doing like how I2S doesn't need to unpack in the same way a USB signal does, jitter numbers between devices, and so much more. What I respect about GoldenSound here is...he isn't necessarily saying any of this is audible. He seems to have some subjective opinions thrown in there too which is fine. But he's open to the concept that this could all be a moot point if it's too low on the noise to be audible. What I would like to know from people here is - do people believe the whole I2S not needing to unpack/the language your Dac uses internally being better than USB/Lan/etc. It's a very interesting topic. Does Jitter really matter? Is I2S just the best way to go into a Dac most of the time even with similar jitter to USB? Or does I2S not matter as much as just the full jitter numbers.

Notice he discusses how jitter effects every interface, USB/I2S/SPIDF/Optical/AES except LAN, because jitter doesn't affect LAN.

To answer your question, I believe it matters when the DDC does a better job than the DAC.
I would take a DAC with a great USB interface over a DDC with a bad USB interface, the DDC isn't automatically better. It's not the presence of I2S that makes it better, it's whether the internals of the DDC are better than the DAC. I2S doesn't eliminate the need for decoding/unpacking, it simply eliminates the need for the DAC to do it. It's still happening, but inside the DDC.

In his video he shows how the May alone can get lower jitter than any of the DDCs. In that case I would just use the May without a DDC. For other DACs without such high performance, I might use a DDC.

 

[camrector]

Notice he discusses how jitter effects every interface, USB/I2S/SPIDF/Optical/AES except LAN, because jitter doesn't affect LAN.

And notice how everything in the way of signal and dac including a $1000 DDC with the “best” clocks doesn’t compare and sounds subjectively worse than a $150 streamer I2S direct to DAC.

 

[Dandoudou]

Notice he discusses how jitter effects every interface, USB/I2S/SPIDF/Optical/AES except LAN, because jitter doesn't affect LAN.

What LAN means?
It's "Local Audio Network".

When you feed a DAC through the LAN, you send the sound to a streamer that is connected to the DAC either by its USB port or by one of the other ports that you enumerated above. In the second case, you either use the internal DDC of the streamer or an external DDC that you put between the streamer, and the DAC. 90% of the DACs a are used on the LAN this way.
A smaller number of DACs have a built-in streamer, and a RJ45 port to connect it to the LAN. There's no such DAC model in this video, because it is not about LAN and streamers, neither externals nor internals. It's about the inputs of the DAC. That's all.

 

[LarsHP]

What LAN means?
It's "Local Audio Network".
(...)

This was a joke, right?

https://www.cisco.com/c/en/us/products/switches/what-is-a-lan-local-area-network.html

Can the R26/A26 use it's LAN input when the ethernet is plugged directly to the PC? Or does it need to be connected to a router/streamer that's connected to the PC? I did get LAN working by connecting an ethernet to my router, but was curious if I could just make a direct connection to the PC since mine has 2 ethernet ports using 2 different ethernet modems. I have the A26, but this thread is much more active and the dacs are similar aside from being r2r/DS.

If I am not mistaken, you need an Ethernet cable with mirrored pinout in one end when not using a switch. However, whether that is a good idea is another story. It appears from this thread that the Ethernet connection carries noise from the computer through into the DAC. That's why many people here buy fiber media converter switches.

 

[Dandoudou]

If I am not mistaken, you need an Ethernet cable with mirrored pinout in one end when not using a switch. However, whether that is a good idea is another story. It appears from this thread that the Ethernet connection carries noise from the computer through into the DAC. That's why many people here buy fiber media converter switches.

The noise is not only from the computer, but from all the devices that are connected to the LAN and spread electrical noise at high frequencies all over.
However, even without FMCs, the level of this noise is lower than the noise of a direct USB connection of a general purpose computer to a DAC, because all the switches and the router have a galvanic isolation.

But for best results, if you connect the server and the streamer directly, you should put FMCs between them, just like you do when you do not connect them directly.

This was a joke, right?

https://www.cisco.com/c/en/us/products/switches/what-is-a-lan-local-area-network.html