Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
213
It’s in dispute because you’re using flawed logic. If I told you that experts recommend feeding babies milk instead of gravel, would you conclude that gravel is in critically short supply?
It’s an interesting phenomenon, to be sure. Perhaps they don’t understand that they don’t understand? But why the drive to convince others of their beliefs?
Unfortunately, people who actually understand how things work are in short supply, and usually busy with other things. I imagine they don’t have time to do a full tutorial on these subjects.
I get the same thing when my phone is too close to my tube amp. In the early days of computer audio I used to hear my hard drive spinning as the music was playing. I recently had to give up my ethernet over power setup because my amp was picking up interference from the transceivers. But what we’re hearing is RF interference affecting the analog part of the signal. It doesn’t affect the digital transmission at all. I think that’s what people are arguing about.
Long time since I did any electronic courses but I have got 40 years working in the Telecoms industry , so I can say for sure its the weather, you will also find your calls on your home line are clearer.
Phil, copper twisted pair with multiple demarcation boxes full of water and corrosion ? Geez I even gave that up several years ago. I don’t miss it in the slightest
But they don’t do they. They’re both software interfaces for digital music playback in a bit perfect way. They don’t sound different because it’s impossible for them to
To clarify, Roon Core is running on an Intel NUC. Roon Remote is running on a Mac. The DragonFly USB DAC is plugged into the Mac. As Roon recommends, there is still value in running Core separate from Remote (not using the same PC for both). Still, I think your suggestion applies to the Remote as well (in that both run on a PC).
To which I respond: this is the hardware I have, and Roon supports it. Whether it is optimal or not, I am stuck with it for now, so I am interested in sharing my optimization tips for people running the same scenarios.
You can also spout PSU noise nonsense all you like, but there’s also zero evidence whatsoever that any of this noise makes its way through to the analogue outputs of a digital device.
The DragonFly USB DAC is powered by the USB port. This means the analog outs are potentially affected by PS noise. Whether or not there is evidence, it can be heard and that is what matters.
BTW, the sound also improved when the DragonFly was used in a MacBook Pro laptop, when the laptop was unplugged and running on battery only. No, I didn’t take a double-blind test to prove it, and the effect was slight such that I only unplugged the laptop when I was critically listening.
Again, I’m just putting this out there for others to potentially benefit from. Sorry it ruffles so many people’s feathers. Roon is a listening product, Roon is used by music lovers, and audiophiles, and we are entitled to share our tips, even if we have not passed a certified a double blind test for them. If this renders it invalid to some people, that’s fine. But they shouldn’t start an inquisition. This is not religion. We hear what we hear.
There is more to take into account for example
—
To briefly summarize this long story about the influence of network switches on clock jitter: our measurements have shown that especially phase noise decreases with a decent switch that does not transmit much (common mode) low-frequency noise to the streamer. We see in our measurements a direct relationship between low-frequency noise from the network port and phase noise on the clock.
—
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
223
If you’re trying to fix it, why it can be heard is what really matters.
Unfortunately, with human audio perception, it’s more like we think we hear what we think we hear.
It is a public forum and everyone’s welcome to share their experience, views and knowledge. Thanks for sharing yours. By posting them you do invite scrutiny, welcome or not. It’s not unfair, if it were how would you resolve contradictory claims and advice? It’s not ruffled feathers.
But hearing isn’t reliable, particularly the processor. Everyone’s experience is different so without reference to the science/engineering it becomes very like religion.
It’s a binary question. The answer is yes, or the answer is no…
James_I
(The truth is out there but not necessarily here)
228
Aha… What Roon recommends is Roon Bridge as an endpoint, not Roon Remote with a GUI that uses a lot of processing power and the like. True you are not exposing the DragonFly to what the core is doing, but you are not doing much better by exposing the DragonFly to what the Remote is doing. The idea is that the device connected to the DAC be a relatively calm, electrically quiet device that just takes the PCM stream from the LAN adapter to the USB port. The paradigm Roon Bridge device is headless, not one running Roon’s demanding GUI.
I hear you. This isn’t intended to be a witch hunt about you not having optimal gear if you don’t have it. But do keep in mind you can use a Pi which can cost almost nothing and it will eliminate the theoretical concerns about having your DAC connected to a machine that has significant processing on it. Also, yes Roon supports it, but they don’t recommend it.
Yes my posts were consistent with this. I’m not saying the core encoded the sound of my iphone into the PCM stream. It just RF’d up to the DAC. You’d get a much more virulent response from me if someone were to argue it actually affected the digital stream itself.
I certainly thought it was because it’s pretty hilarious. I don’t know about any science behind sound waves and warm or cold air, humid air etc., but the idea that a warm wire changes the PCM stream is, I hope, pure sarcasm. That’s not to say that potentially telecom gear is affected by weather. But to translate that to electrons sounding better is, I certainly hope, a joke.
Exactly. This course of inquiry is what stopped humans from sacrificing virgins to volcanoes. Otherwise every confluence of events equals cause and effect.
You want to live in an echo chamber?
I do suggest this doesn’t need to get nasty. But yeah, it’s important to call out when someone isn’t thinking logically or scientifically. Maybe you can trust your ears to a certain point. But there still needs to be scientific basis, not pure superstition, for something to be established: How can the shaman talk to the physicist?
Audiophile “grey literature” with the method, data and results behind a paywall. Using kit they’d acquired for the task in a workshop environment. It’s far from an authoritative study. The conclusion wasn’t exactly confidently stated.
A Possible Conclusion
Does a switch affect the clock in a streamer or dac? Yes: 100%. We have now demonstrated that, we may hope.
Roon bridge endpoints are not updated with every Roon update (just look at the release notes). Roon Ready endpoints can’t be updated by Roon, period. The manufacturer of the endpoint would have to release a firmware update that updates Roon (and I’ve yet to see this happen with the two RR devices I have used). Roon also can’t update endpoints that are AirPlay, Chormecast, etc.
1 Like
Bill_Janssen
(Wigwam wool socks now on asymmetrical isolation feet!)
231
Well, that’s not clear. Roon could be running an interpreter of some kind in their SDK on the endpoint, then downloading a program to it that runs in the interpreter’s environment. Well-understood tech. But I don’t know if that’s how Roon Ready endpoints work.
I guess it is possible in the same sense spontaneous human combustion is possible, but if anything, it would require that Roonlabs maintain code for each Roon Ready device, with every possible combination of manufacturer’s firmware. Or that every Roon Ready device runs on a CPU fast enough, and with environment flexible enough, to support in-place rebuilding of the Roon portion of the software. Somehow sounds pretty doubtful
Besides, SDK is a development kit you don’t run it on the end-user device.
