If I were to buy a Roon Ready device that had music file storage on board ( such as the Melco if it ever becomes Roon Ready) but then run the core on a Mac, what journey would the music files take? Would they go from Melco to Mac to Melco or in such an instance, would the core just deal with the heavy work of database control, allowing the music files to only leave the Melco to go to the dac? Could different manufacturers treat the file journey differently?
I am keen to keep the music files away from switches and non-audiophile devices, having heard significant variations sound quality, according to how the data has been treated.
[quote=“en1omb, post:1, topic:9710”]
I am keen to keep the music files away from switches and non-audiophile devices, having heard significant variations sound quality, according to how the data has been treated.
[/quote] If you’ve heard significant differences and they’re indeed not occurring between your ears you should take comfort that Roon’s RAAT protocol is engineered to deliver the best possible outcome: What’s wrong with UPnP?. I’m not suggesting you were listening via UPNP previously but the thread should give you some insights into how Roon does things.
The rule is that the audio path always goes through the Core. It only goes through a Remote or Control if the Zone is connected to that device. Network zones are like Core connections for these purposes.
This is because Roon has runtime features that affect the audio stream, like auto volume control.
The result is that Roon Cores really love being right up close to your music storage. In my case I use an SSD in a Brix.
Hi Rugby, Can u tell me why you believe that the music is best served via Ethernet? I use a laptop as a Core, with a SPDIF direct connection to my DAC, the source is lossless as a result(Exclusive Mode). Or does Ethernet offer more? Just curious.
I would prefer to keep a computer as out of my system as possible but even after reading @danny’s explanation of how RAAT works compared to UPnP, I am concerned that the music file path through the switch will cause it to get chopped up and affect the naturalness of it. I think I will start with a Mac and RoonReady endpoint and go see if the quality works for me or not.
Your music file is getting chopped up no matter what, and a thousand times more often than you think… for example, even on disk, your FLAC files are stored in blocks, not a continuous streams.
Don’t worry about the chunking, instead worry about how they get put back together. There is only 1 proper way: in order and not missing chunks.
The best thing is for the transport to be timing neutral, so that the endpoint playback device with the best clock can play the audio correctly. If done properly, nothing before that device can impact the audio on a timing basis, since it restarts the timing quality equation back to zero (assuming the stream got there in order and not missing anything).
Ethernet improves the situation over WiFi in accomplishing that, and spdif is pre-clocked (although it can be reclocked).
To add to Danny’s point about timing: I saw somebody claim that once jitter has been introduced into a signal it can never be removed. Kinda like the distortion of a pickup on a vinyl record.
But of course this is not true, when you clock things at the end and keep it asynchronous up until then.
Consider this thought experiment: you set up a CD player to play into a DAC device with a 1 GB buffer. You play the entire CD into the buffer, don’t listen to it yet. You power down the CD player, disconnect it from the DAC, put it in a burlap sack with two bricks, row out into the middle of the lake and sink it. You then row back, and play the signal from the buffer. I venture to say that the jitter of the original CD player is no longer present.
The confusion mostly comes from the weird statement from the “bits aren’t just bits”. If those bits you put in the buffer are the bits that were on the CD, no issue… but if the bits in the buffer were mangled due to jitter on your SPDIF signal coming out of the CD Player into your DAC, then your buffer is screwed.
How common is this, really? I know it is possible, but is it common?
Seems to me you would have to have enormous jitter to cause bit errors. Our data streams are measured in Mbps, which means 100s of nanoseconds, but when people report jitter measurements they talk about picoseconds.
I have always understood jitter as being timing errors that cause distortion in the analog output stream when they hit the DAC. I saw a diagram of a trivial DAC that just ramped voltages in response to the incoming values and a timing error caused the ramp to be misplaced – I don’t think you build DACs like that anymore, but according to the SPDIF standard the clock is supposed to come from the source so I can see that kind of effort of jitter, even picosecond jitter.
But I have never seen a discussion of jitter causing bit errors.
“Bits are bits” may be a meaningless statement, but overall digital transmission is extremely reliable, even without error correction.
Do we have any measurements of the statistics of bit errors? Locally from disk, over SPDIF, over USB, over IP?