Read your shared link again, John says ‘USB’!
Drop usb and connect your endpoint to the core with a pure ethernet connection and such problems did not exists.
Read your shared link again, John says ‘USB’!
Sigh. There’s 3 links. As I’ve mentioned at least 3 times in this thread (the same number of times that dropped bits is not relevant), he’s made up custom measurement gear and found these same (high impedance) leakage currents can sail right through ethernet’s little transformers into the DAC.
It starts to become a little repetitive like head banging on a brick wall so I shall stop. I would really recommend discussing this stuff with your DAC designer/s. Their marketing department will tell you their stuff is immune to everything on the planet but if you get a chance to chat to the designers about RF interference and leakage currents, you may find it interesting.
Ok, I give up.
Go on searching for solutions for non existing problems, in the meantime I will enjoy listing to music played flawless without any expensive cleaning gadget through cheap cables and the original power suplies shipped with my devices.
Sigh. I also mentioned at least 3 times (the same number of times I mentioned dropped bits is not relevant) that none of this stuff is required to enjoy the music.
I don’t think anyone is claiming they aren’t enjoying the music - at least that’s what I hope.
Some of us just find these mechanisms interesting to discuss - while we enjoy the music especially these discussions with DAC designers if you get the lucky chance to have these discussions, like I’ve had with a few well known designers.
Maybe not “here” in Roon, but certainly “here” on the internet.
Stereophile tested the $175 Uptone Regen with the $5,750 LampizatOr Lite 7 and glowed over the “not subtle” improvements.
I’m not questioning that evaluation or criticizing the Uptone.
I’m just saying I would not be pleased if I had paid $6k for that DAC.
(And yes, I know this thread is about Ethernet cables and that example was about usb, that’s not the point.)
I’m only talking about potential technical mechanisms (RF and leakage currents).
I’m not asking people to ask their DAC designers about any specific add-on product.
I’m asking people to have the discussion about potential technical mechanisms. And again, don’t have this discussion with their marketing department who will tell you their product is immune to everything on the planet. It should be a discussion with your own DAC designer/s.
Again, potential technical mechanisms (RF interference and leakage currents), not add-on products.
You will get nowhere in talking to DAC designers about add-on products (understandable for obvious reasons). You may learn a lot from them if you stick to discussing the potential technical mechanisms.
No one here is discussing or suggesting expensive products. My switches are all between $20-$40. The 5V Teradak power supply for the switch was $50. The cables are all reasonable Cat 6 UTP from companies like Belden and Fluke tested. I paid nothing for my cables, except for the few S/STP that I ordered to try that component.
If you start attaching the shield of the ground, then that will change the sound because now you’ve removed ground isolation. That’s a whole different issue and should not be used. So barring that, you can use UTP or floating shield design (on both ends). Still, people hear differences between these and various brands. People are buying all these cables that can differ in their electrical characteristics at short lengths (typically less than 2m).
With the Belden bonded stuff I have, I know there is far less variation from a pair to pair and less chance of gaps between the pairs or impedance mismatch. It’s the perfect cable for testing. Yet, even with the short Belden stuff, it still sounds different than the long stuff.
All the long stuff starts to sound the same. It’s the short stuff where things get weird. Now in some people’s rig they may like this change in sound. I can describe the sound or what people may notice, but will refrain from the moment.
After going through 30+ cables and various lengths from different companies (all which I got from free and are tested), my recommendation for cables is to stick with a well made UTP cable and just make sure all the lengths involved are relatively long. Push for 5+ meters and you won’t have to worry. This is why I’m using the big pile on the ground and it sounds perfect. I have no idea how long it.
If your switch is near the audio rig and very close, just coil (within reason and with consideration to the bend radius) the ethernet cable and put it on the ground. It makes no difference. Just keep them long.
Buy any well made Cat6 UTP cable. It’s very cheap stuff.
I did try to figure out at what length the differences started to get less, but haven’t quite nailed it yet. Compare a 1 foot vs. 1 meter vs. 2 meter vs. 5 meter vs. 10 meter. The short ones are the ones that make stuff weird. They all WORK clearly. However, if I had to guess the PHY has to work harder with the shorter cables. I’ve heard similar sentiments from network guys that have nothing to do with audio. They’ve also referenced it messing with the physical.
Nothing expensive suggested. Just generic well made and relatively long.
As a guy that used to run a large data center, the use of short (1 meter) Ethernet cables is very common. 5+ meters? Very uncommon.
We would run optical into the routers in the cages, Then use the shortest cables we could to connect the routers to the switches and then to the compute nodes. You don’t have room for extra cable lengths and it would be untidy.
I have much longer runs in my house.
My cable run from switch to my Atom is over 5m I have other shorter runs from 0.75 to 4m in my cupboard with the Nas, router and Roon core live.
I’m not sure how this relates to @Sean2016’s links, but I’ll also share something unusual I noticed regarding grounding with shielded cables.
If one uses a shielded cable with a ground attached to their network device, then they may notice a change in sound due to the introduction of RF. Typically some HF modulation. This is something people may have experienced that have used shielded and grounded cables.
Here’s something I didn’t expect. With the DGS-108 (which has shielded ports), I kept the cable from switch to BDP-1 UTP. However when I swapped out the 5 foot both ends floating S/STP that was from my iMac to the switch with an equivalent 5 foot S/STP which has its shield connected on both ends, I hear the same HF modulation on the BDP-1 even though its UTP.
So if you modulate the switch’s ground plane with a shielded cable from another device (say a computer), it MAY still affect another device (i.e. your network player/DAC).
I suggest keeping the ground plane of both the switch and the network audio as clean as possible. So no grounding whatsoever on any devices. This is why improving the power supply of the switch or grounding it might be useful and makes a difference in perceived SQ. Keep the ground on the connecting devices as clean as possible.
This makes no sense. You want to ground the switch so it does not pass noise down the line through the Ethernet transformers. You want to use UTP so ground noise is not passed from one switch to another or from the switch to the streamer.
Yes, I’ve seen short cables used all the time and they all work. Even my 1 footer works for RAAT. If I was using it to simply transmit files, I would have never noticed. Zero dropouts.
I haven’t seen any discussions regarding cable length with ethernet on audio forums. It’s always shielding this or that.
Although, I have seen occasionally discussion on networking forums about problems being resolved by going to longer lengths for certain applications. Then there will always be people chiming in saying they are using short stuff and they have zero problems. I’ve occasionally also seen RF specialists talk about this. Something like this:
I’ve been trying to find the link which had a good explanation about this from the RF guy (had nothing to do with audio).
For people who don’t care about cables or don’t hear any difference (perhaps their network players have their network circuitry completely isolated and immune from the audio portions - which is perfect), to those people I would say forget about it. Ignore everything I am saying here.
However, for people whose system does for whatever reason seem to respond to changes in ethernet cables, I’d say try this first. There is far, far less variation in sound between the 3m, 5m and 10m than in comparison to say a 1 feet vs. 1 meter or 2 meter. To those people, try a 1 footer vs. a 10 meter.
I’m sorry I wrote it incorrectly. You’re right. By “not grounding”, I meant to say not use any cables that connect their shields to the ground. So yeah UTP through and through was my intention. You can ground the switch. I think we are in agreement here.
I should also clarify that where the shielded cable and introduction of RF changes the tonality and other sonic aspects like HF response, the whole variance in length with UTP doesn’t sound like that. It sounds almost like jitter, which is crazy. I didn’t even consider this as a potential factor during these past months considering this is an asynchronous system for data transfer. I was focused entirely on shielding and noise leakage etc. I think the manufacturers have also failed looked to look at this aspect or have been unable to find a way to mitigate the problem.
Time and time again we’ve heard customers of various manufacturers say that their playback through RAAT sounds worse than their local playback mechanism, whether the media resides on local attached storage or even via NAS using the same network gear for both RAAT and native mode.
We know with RAAT, unlike most native protocols, that it’s constantly transmitting little by little. Most native systems try to aggressively buffer as much as possible in advance. The ethernet port shouldn’t be anywhere as active as they are with RAAT.
With native systems, even if there is ‘jitter’ in the ethernet domain (which yes I realize is supposed to be asynchronous) it wouldn’t matter as the loading is done quickly. Any pattern of jitter will not matter. With RAAT, those patterns might become visible as it’s constantly in use.
I’d be curious to hear directly from the manufacturers themselves and not any third party. I’m sure they looked at isolating noise and probably did an excellent job. They used ethernet for ground isolation and asynchronous transfer of data. However, for things like RAAT with constant transmissions, did they ever consider whether the pattern of jitter in the incoming data stream via ethernet somehow affect the audio circuitry. Yes, I know there are RAM buffers in place which is filled ahead of time. Yet, there are hundreds of people out there that notice differences based on network tweaks. It might be time to reconsider that assumption and just how immune the system truly is…even in asynchronous data systems.
I’m not an electrical or software engineer, so I know how irritating people must find non EE or software engineers to be commenting on these things. I get it. Trust me, it’s far more frustrating for us normal people to have to try figure out why something doesn’t work or sound the way we would imagine it to be. Sure you can say that all these people are just hearing things. Whatever. As long as the manufacturers are taking a note. That’s all that matters in the end.
Let’s see what John Swenson comes up with in a year. I’m confident jitter will be involved somehow in this by the time it’s all done.
I know I can botch up the explanations of the mechanisms as that isn’t my field. Still, I am fairly confident in my hearing that takes place over months.
If you think jitter is BS, go ahead try this test and be honest: http://www.cranesong.com/jitter_1.html
If you can’t hear and figure out jitter in this extreme case, ignore everything I’ve said. It won’t apply to you.
Probably an ethernet reclocker / decrapifier, just like we had for USB. Life is going in circles. There will be so many ethernet decrapifiers within a year from now that many people start to wonder if ethernet is any good for audio at all it it needs so much “fixing” just like happened to USB. That’s my prediction. Audiophiles have the typical habbit of constantly trying to fix things that ain’t broken. This will never stop, that’s one thing I know for sure.
Actually everything you wrote there has been discussed by John S in the links I posted yesterday and other links further up in the thread.
Not sure if anyone has had a chance to go through them, but do recommend it (if interested).
Things like incoming jitter are more within the DAC designer’s control, than RF interference in every end user’s environment. That’s not to say incoming jitter is 100% eliminated and I already posted several posts from John that show he is looking at clock (phase noise) interactions upstream of the DAC. I won’t re-post the links I already shared much higher up but in short, John’s researching if the phase noise of each clock getting into the DAC can affect SQ and if ‘clock blocking’ before the DAC can improve SQ. He said this research will take at least 6 months and he’s not going to guess or speculate what’s going on in the mean time. So your comments/questions about jitter are definitely aligned with what John said he’s researching.
So even as a mad tinkerer myself, I do draw some limits on how deep I go and I personally think incoming jitter is much more in the control of a DAC designer than RF interference, since end user systems and environments will be SO varied. Especially if we’re talking about jitter over USB and ethernet. So sticking to ethernet cables (and any digital cable/interface that doesn’t feature optical isolation) I personally prioritise trying to follow John’s recommendations on blocking leakage currents (which potentially result in RF pickup and radiation…) over phase noise (jitter) issues - since the latter has mostly (not 100% perfectly eliminated of course) been within the control of the DAC designer.
Fortunately in the links I already shared a few times, John shared a cheap and easy solution for blocking most of the leakage currents from getting into your networked endpoint over unshielded ethernet cables, and therefore into your DAC.
Without question, I mentioned the same a year ago. As ethernet input DAC’s especially become more common, expect to see a shift from USB Regens to LAN Regens. And just like with USB, some will be designed and built by people that know what they’re talking about (addressing real potential technical mechanisms that may affect SQ in some systems) and some will be built by people just trying to jump on the bandwagon.
Here is one that was just posted on Audiostream. There are heaps of in-line filters already on the market, especially for medical applications that have been around for years but this is the first I’ve seen that OPTICALLY isolates gigabit ethernet. It’s like a pair of optical FMC’s inside the one metal box and needing only one 5Vdc PSU. The optical isolation is what mostly interests me as optical isolation truely blocks all current (including the leakage kind) inside one metal box.
But it’s 8x the price of my pair of TP-Link fiber optic converters. I would hope it makes me coffee every morning at that price difference !
In case anyone is fuming at their keyboards reading this stuff, take a big deep breath and I repeat for the 5th time (or 6th?) none of this stuff is important for enjoying the music
It’s just tinkering with your existing system, for relatively little money (in the case of John’s cheap ethernet switch tweak that’s been linked a few times already) to block some more of the bad stuff getting into your DAC, over both ethernet and USB. Whether or not it will result in improved SQ, John is not claiming it will. He only says it MAY and gives the technical mechanisms of how (potentially) and that the extent will vary from system to system (and whether you can even hear the differences…).
RF interference may be a bigger issue than many people consider and conducted RF (airborne can be big issue too, depending on system and environment) is linked closely with leakage currents (see numerous links already provided). Block the leakage currents (as much as possible) in the cables going into the DAC and the effects of conducted RF getting into the DAC reduce. I’ve had agreement with this last part from a few DAC designers but you don’t have to believe me - talk to your own DAC’s designer/s Just don’t ask the DAC company’s marketing department and don’t ask audiophile cable manufacturers… and don’t mention specific add-on products/fixers when chatting to DAC designers unless you get to know them really well, i.e. just stick to potential technical mechanisms.
I completely agree that ultimately it’s the DAC’s job to be immune to all these tweaks. I will be looking at this for my next DAC. I know my current DAC isn’t the best out there, but still, I thought at least the BDP-1 would be immune and thus it wouldn’t matter with regards to the stream to the DAC. We should be more critical of DAC designers rather than trying to improve things with external tweak.
BTW I keep hearing time from time that “audiophiles are trying to fix stuff that isn’t broken”…that’s tone deaf. Nobody here experimenting thinks that anything is broken. It’s about maximizing performance from the gear we have. Ultimately, it should be immune.
On this forum, the majority of us are in agreement in using ethernet for isolation and separating endpoint. Go to other forums and they’ll laugh at you for needing all this ethernet crap. They’ll tell you bits-are-bits and just use USB connection. It’s the DAC’s job to be immune to this noise. As long as bits aren’t dropped, it doesn’t matter. Jitter and incoming noise make no difference. Go to some forums and they’ll tell you all amps and DAC sound the same if they are designed to be transparent.
Everyone has their assumptions and theories. Few have experience.
USB discussion is fine, but there is absolutely no jitter on the network. There cannot be, by definition.
Wikipedia: jitter is the deviation from true periodicity of a presumably periodic signal. But the network protocol stack is not presumably periodic. Packets can arrive at irregular times, out of order, packets can be missing and a retry is requested. The network, and the endpoints, and the drivers, and the software stack, do not make any claim for accurately periodic delivery. No system that cares about timing can depend on the network technology.
If you think that the USB signal should have precise timing, it is up to the network-to-USB converter to create that timing, without dependence on the network timing.
Although I personally don’t think that makes sense either, we use asynchronous USB precisely for the purpose of allowing the DAC to control the clock and not depend on the timing of the USB signal. But that’s a separate conversation.
For the moment I’m just ranting that there is no timing accuracy and hence no jitter in the network.
Just like there isn’t when Fedex delivers my CDs from Amazon.