Facts are not measured by how many people believe them, especially when senses (or subjective impressions in general) are the sole arbiter.
Outside the DAC chip or equivalent D2A circuitry, but in many cases inside the DAC box, such as with Roon Ready DACs with Ethernet input.
There’s figure and then there’s really figure. I’d not be surprised if some boxes out there handle interrupts and synchronous output slightly differently on different code paths, given the complexity of the code involved and the difficulties of really testing realtime code. We frequently see “total mayhem” from supposedly well-tested software (Crowdstrike, most recently), so I’d not be so confident that perfect code path equivalence is guaranteed in this space.
We did really figure it out. How could you download and install software or have this conversation if we didn’t? Nobody has to deal with the complexities you mention anymore; all hardware and software is available, tested and working. It doesn’t matter if it’s in separate cases or just one. And what would happen if it did break? It would be an obvious breakdown, like CroudStrike: glitchy or garbled audio, not “lower quality”. Flip a bit or drop a byte and it would be a completely different sample.
Anyway, the OP is not questioning the correctness of the bits. I on the other hand am not questioning the ability of a well engineered DAC to produce identical output given identical bits, regardless of what happened in between.
Did you try it on the same box, with RAAT and Diretta (or whatever nonsense) support, playing exact same source file, with exactly the same lack of any DSP, volume matched, and blind?If no to any one of these, then it’s…a cool story, but absolutely meaningless.
Which is a rather meaningless distinction.
Which still does not, in any way, explain why the data inside DAC buffers would be any different. And that part is rather easy to test.
Sure, it is all digital. It is trivial to make a box that rickrolls you from any specified input. But absent some actual malice (not that I would put it past people who want to sell you something like DIretta) it does not happen. I guess one could also tie DAC’s analog outputs to current draw of the Ethernet controller. but that’s just incompetent design. Which I also would not put pas most high-end audiophile companies, but why would you want to get something designed by incompetent engineers?
Comforting to know that I will always be quickly corrected on the Roon forum, no matter the topic and for years now, by the ever-vigilante keepers of all knowledge who protect us from “actual malice” by companies like Diretta.
BTW their evil software costs all of $100.
Applies to both sides. It’s also the same every time when people claim improvements based on completely nonsensical techno babble and what they think they hear.
Yeah, they have the opportunity to trial some software to see if it does or doesn’t make a difference.
I’m here to see if it’s in the cards to make Roon better.
[Moderated]
And you have the opportunity to provide evidence that RAAT is deficient vs Diretta, but you don’t either.
Timing bugs can have subtle nonfatal consequences. Speaking from decades of experience. But we’ve been at this long enough, you believe what you believe.
… or the internal synchronous bitstream (I2S or something like it) is not timed exactly identically for different code paths or … or … A consumer has little way of knowing whether anything they buy was designed by competent engineers working in a well-managed, healthy environment, and built with quality, non-counterfeit parts.
Diretta’s page provide bits of evidence [Moderated].
Anyway, I hope some Roon devs come around to it. It definitely seems worth it, in the end.
It was put nicely in another thread here somewhere, there’s no Q (quality) knob for designers to turn depending on price point, only experience and a collection of „best practices“. When it’s data, it’s data. Nothing to change or tweak there.
What exactly would you want Roon to do to improve the perceived audio quality associated with RAAT? What specific deficiencies do you believe need to be fixed? Without stating them it’s presumably hard - both for the Roon developers, and the general audience - to know what constitutes “better”. From your posts you seem to be suggesting that Roon listen to systems using alternative protocols and “make it sound like that”, but perhaps I’ve missed your point.
I think it’s more interesting how proponents of the superiority are so allergic to backing up their claims
Quote from https://www.diretta.link/ :
We don’ t say that this method is definitely better than other transmission systems.
I2S is timed by a hardware clock, not by code. The code makes sure the buffers are not over- or under-flowing. If they did, audio would glitch. Also, the only “timing” in digital audio is the bit sequence. Preserve that, and you have perfect timing. I need some concrete examples of how an identical bitstream flowing through a DAC’s I2S bus can produce a different analog output.
A friendly reminder to stay on topic and not criticize others. It is okay to criticize ideas.
I do hear a difference in different software packages but I do not have the equipment or knowledge to test them. I do have experience using D/A convertors in industry for signal control. I would first look at the electrical signal enveloping the digital bit as to how sharp the square wave is and voltage difference bit to bit. The originating software and transfer protocol may have an effect here. There is a threshold on the voltage to determine a 1 or 0. This could lead to further timing issues which although corrected by D/A circuitry could affect the work of the D/A convertor and possibly affect sound. There is a difference between passing data bit perfect and affecting the electronics doing the conversion.
I may be totally off track here but it would be nice for a data engineer at roon to chime in rather than the same roon members syaing “move on”.
Since when, and what could a possible mechanism be for this? AFAIK this is defined by the specs of the physical layer.
Since when have buffers been eliminated from networked equipment such as the device’s NIC, as well as input buffers and clocks eliminated from DACs?
You didn’t read what I said. I said “corrected by D/A circuitry”
Anyway, as I have said previously/elsewhere I use roon for discovery and for serious listening I switch to Lyrion as I hear an improvement. If you are telling me I don’t hear a difference I challenge you to give it a serious try. Lyrion (squeeze) is free.