I can start posting educational papers and video’s to proof me right but as it looks there’s a strong resistance to accept any feedback to could help improve Roon.
where I was hoping to start a technical dialog with pears I’m now in the camp of the non believers that have to be proving wrong.
I’m definitely no Einstein, Madam Curie or Eddington. The link I’m making is that they were launched at and humiliated by colleagues for their being wrong.
I can only say that they had the drive to stay with it and luckily for humanity they did so.
In this case we are talking about audio software. In other words don’t look back and carry on.
Don’t give up, post the educational papers and links to the videos, this should be a space in which we can all learn something new. The laws of physics are just that laws, which in most cases are built on established theory and practice and don’t reflect any of the new and esoteric thinking.
Who knows what wonders could be achieved by adopting radically new thinking, could there be new methods of transmitting digital signals by using various viscous fluids for instance that would completely isolate them from outside electro-magnetic interference?
Or, maybe we should be open to trying to replicate the “basic” but powerful systems that aid sharks and conger eels in locating prey as a method of transmission of digital pathways; if we liberate ourselves from hidebound established thinking, who knows what can be achieved!
I for one would love the idea of having a mega revealing multi fluid based system in my listening room, a whole wall of organic resonance based excited gels, pulsing and throbbing in time with the backbeat, bulging back in forth in 3D as the melody lines chase each other across the wall, writhing and undulating akin to a lava lamp as I sit there bathed in hypnotic lighting effects on a sensory stimulating body fitting lounger.
Seriously, not only that, but every company making audiophile cables would have been taken over by three-letter agencies long time ago. Just imagine how much better Lacrosse satellites would work with some AQ cables inside!!! Or something.
It’s really quite amusing to see how much some people want to believe that a guy peddling orgone accumulators is the one true authority on the existence of orgones, and every scientist or engineer on the planet is an incompetent fool…
Without diving deep into the low level details, this problem is not new: On one side, a synchronous producer (produces data at a constant rate), on the other side a synchronous consumer (consumes data at a constant rate) and in the middle an asynchronous channel (delivers data, usually, on a best efforf basis). The solution: Use of buffers at the receiving side.
Buffers of what size? Large enough to avoid empty buffer situations and short enough to keep latency low.
Of course, we need a reasonably reliable channel (network), enough bandwidth, etc. But this is another story.
An Audirvana versus Roon thread is always a bit pointless as it comes down to purely personal preferences. Roon is a much more mature app with greater functionality. Audirvana sticks more to the traditional digital audio player route eschewing some of the functionality (multiroom, detailed data etc) that you get with Roon. As regards sound quality the only thing that matters is what the user perceives he prefers. I do not doubt the significant number of Audirvana users that say they prefer Audirvana to Roon do hear a difference which to them is preferable, why they hear a difference is not important, the only thing that does matter is that to them it sounds better.
For me, if there was no Audirvana would I be happy with Roon…yes, absolutely. Why do I prefer Audirvana? My personal preference for the UI of Audirvana. The default smaller font size and scalable (via slider) graphics sizes means I can see more music/information on the screen which in turn results in less scrolling (example same window size screenshots of Roon and Audirvana Studio showing local albums and local tracks). This for me is important, for others no doubt meaningless and they focus on other things which are important to them.
I am just thankful that we have several options from which to select a personal preference.
But for a most of all because Audirvana runs as a “server” on Raspberry PI 4
And it works great!
Unfortunately Roon still NO… and I don’t know if doesn’t want to or doesn’t know how?
I see that you’re still wishing for Roon Server running on an RPi4. It won’t happen, and not because Roon Labs don’t want to do it or that the developers don’t know how to do it, it’s simply because Roon Server makes demands that an RPi4 (or RPi5) simply can’t meet. It’s not a straightforward digital player like Audirvana.
The definitive view of Roon Labs on making Roon Server available on other platforms was given here:
Until the digital data is processed by the DAC timing is irrelevant because it’s simply data, not music, which is buffered by the DAC, then processed. That said, I’m not sure what you mean by unwrapping the ethernet packet in the bridge, so perhaps you could offer some clarification.
I don’t doubt that they hear what they believe, either. And I would even agree that it does not matter - but only up to the point where they proffer nonsensical technical explanations. Surely at this stage one may point out the flaws.
Not sure if my reply will lead to insight. I presume it will just be rejected as false but ….here goes.
when you transport music in a ethernet frame its information is protected ( CRC ) .
As soon as you unwrap that Ethernet frame you end up with serial data ( music)
That data is created in the bridge and send to the DAC to be converted into an analog wave.
As soon as you have unwrapped the ethernet frame and create your serial data there’s no protection (CRC) . To identify the information in that serial data stream we need a clock. At Fixed moments in time your clock will pick a sample and decide if that sample is a 1 or a 0 Standard there is a clock in your bridge and a clock in your streamer that function independent from each other
Your DAC will look and sample the incoming serial data using its own clock. These time related voltage samples will be used and stored in the DAC buffer. But garbage in is garbage out.
the buffer is just a storage to make sure that there’s a continuous flow of data and not to overcome jitter of the incoming clock
The world of clocks is not perfect and jitter and smearing does take place.
that means if timing in the bride fluctuates there is fluctuation in time entering the DAC. The DAC will therefore sometimes detect a 0 for a 1 or vice versa.
Same goes for smearing if the puls is not sharp anymore it can lead to a false Decision being 1 or 0 in the DAC
How to overcome this it to make sure that your serial data will leave your bridge with perfect timing. Even better is to have a very precise external clock feeding your bridge and your DAC making sure that there are no differences between them.
I was very skeptical about this timing at first but I was also constantly frustrated why I didn’t hear that same wide soundstage of that same song and recording in my home system compared to the more higher known brands that passed my way. Mind you I use a rasberry Pi as bridge so I can play with it and build it out… I started with buying stuff from Ian Canada that I could easily add to my Pi ( reclocking ) and the impact was impressive . Then I learned about the importance of clocks and low jitter ( short term jitter not long term jitter) i found a few in Denmark that cost me 800euro but I wanted to know if it made any sense. The impact was huge. I’ve got that openness and clarity in sound that I was looking for for so long.
Later talking with Grimm audio and others they confirmed my educational journey.
Therefore when I read that timing is nonsens we are to far apart to come to an agreement.
Sorry, but nothing you wrote here makes any technical sense. Well, it probably makes sense for crooks selling useless 800 Euro boxes that do nothing, but not in any practical sense.
CRC has nothing to do with clocks. Entire transmission chain from the bridge to DAC is digital, and it does not matter whether there’s a DAC, a cash machine, or a teledildonics adapter on the other end. Short of something being broken, even with an ancient and suboptimal S/PDIF cable it will be weeks of continuous playback before you get a single flipped bit (and that’s not due to any jitter). With a more modern setup, USB sends data in packets anyway. There is no jitter.
For some reason Denmark seems to be some kind of a hot spot for snake oil extraction, but if anything they have said selling their expensive reclockers were even remotely true, Internet, computers, and really most of the modern civilization would have fallen apart ages ago.
And this is why these discussions never end well. One side asks for some reproducible proof that there even is some difference to begin with, while the other side goes on an on that “the guy who sold me my orgone accumulator said that orgones are absolutely vital for my health. Surely a guy selling orgone accumulators would not ever be even a tiniest little bit dishonest about how useful orgone accumulators are! Unpossible!”
No, we‘ve still got a stream of 24 byte data words, divided into blocks, frames, and subframes carrying not just audio data only - start with more detailed info on Wikipedia.
If that happens, your problem will be glaringly audible non musical glitches, rather than changes in soundstage and other audiophile auditory impressions.
Now, if we’re using the legacy AES/SPDIF/I2S one way transmission protocol, the DAC’s clock constantly needs to adapt to the streamer’s, thereby possibly introducing jitter artifacts and thus, worsening auditory impressions as described by audiophile jargon.
But if we’re using a state of the art two way transmission protocol via Ethernet or USB, the DAC now controls the speed of the incoming data stream from over/underrunning a buffer, to then be able to maximally suppress jitter artifacts during D/A conversion according to the precision of its internal clock only.
All this has zero to do with the clock timing accuracy of Ethernet or USB transmission.
You still need something like phase locked loops in the respective units, and external wiring, internal electronic devices and physical PCB layout will introduce their own problems - nothing’s perfect, better to keep it simple!
That is why I hesitated to write down to share what I know, learned and heard.
I started this post as positive constructive feedback to see if we can improve Roon, me being a happy customer.
However, From the start I find myself in the defensive corner.
what I really find interesting is that it never started with accepting my statement and a simple respond back that it however couldn’t be reproduced.
It directly moved to the statement that there’s no technical proof and yes indeed I allowed it to happen I’m pulled in deeper into a discussion.
Over time the topic Audirvane vs Roon I’ve started moved into a discussion over nonsense about timing and me defending it.
this will not lead to anything. It’s all so negative and to be honest it pushes me down in how I feel about Roon as a customer.
I don’t know the technical ins and outs of Roon and I hope that the negative pushback on what I brought in is not caused by limitations of Roon. ( we can’t do better)
In the mean time I will invest further into what you call snake oil solutions and Enjoy my music
I stop responding to comments on the post I started.
But what is there to improve, at least in this particular regard?
You know what they say about extraordinary claims requiring extraordinary evidence. The claim you are making is quite extraordinary as it contradicts all the science and engineering used to design the entire digital music infrastructure (and much more). Seems reasonable to ask for some kind of proof that there is a difference that is not purely psychological.
And indeed there isn’t one…
As I recall, you were the one who brought up the (indeed, complete nonsense) timing argument.
These threads never do.
There are no limitations in either Roon or Audirvana in regards to bitpefect playback (DSP implementations can obviously be different). For that very reason, bitperfect playback from either system sounds exactly the same.
That is definitely your prerogative. And your money. But, to use another well-known saying, “you are entitled to your own opinions, but not your own facts.”