( >>> ** problem solved - operator error - was playing Qobuz rather then off local files ** <<< )
Is there a simple guide to setup a roon system for bit perfect super high end audio use ? I want roon to not alter the bits AT ALL… So like a lightweight player.
Sorry if this questions has been asked a million times, I just can’t seem to find this. I found a roon FAQ about this but the sound quality is still not sounding right. Ive tried lots of switches and cables and paths. Nothing seems to help.
To get useful advice, we need to know a bit more about your system. To give you an example, here’s mine:
Main router: Ubiquiti EdgeRouter PoE-5, dual WAN connections to Comcast cable modem and AT&T DSL modem Internal ethernet: Cat 6, Actiontec MoCA coax adapters, Netgear GS105 switches WiFi AP: Ubiquiti AmpliFi HD Roon core server: Intel NUC7I5DNHE, 8GB DDR4, 120GB M.2 SATA SSD, 2TB USB SSD for local music, Ubuntu Server 19.10 Headphone system: Raspberry Pi 4B+Pi 2 Design Pi2AES streamer running RopieeeXL+RoonBridge; AES to Schiit Yggdrasil A2 DAC; balanced to Goldpoint switch; balanced to SPL Phonitor XE or Eddie Current Aficionado; multiple headphones from ZMF and Dan Clark Audio. Speaker system 1: Linn Klimax DSM + Klimax Exact 350 speakers. Speaker system 2: Linn Kiko DSM. Control devices: Macbook Pro laptop, iPad, Google Pixel 3 XL Music material: 19967 local FLAC tracks (from 44.1/16 to 192/24 PCM), Qobuz streaming.
Sound quality is excellent on both systems, both in our judgment and that of expert visitors. The Linn system has its own DSP (Space Optimization) but otherwise it’s all straight PCM from sources to DACs. All the digital cabling is good commercial quality, with some fancier ethernet cabling for the main Linn system. I took same care with routing of shielded power cables and XLR digital and analog cables for the headphone system to avoid hum. Otherwise, nothing fancy.
Turn off any DSP processing, volume leveling, and upsampling. And run it in exclusive mode. Roon will be outputting bit perfect to whatever endpoint you have it selected to.
Switches and cables have, at best, a negligible effect on SQ (as you have found out) and, at worst, are complete snake oil, but that’s a topic for another thread.
A provocative statement, but what does it mean?
You don’t like the way Roon sounds or you don’t like the way Roon sounds compared to something else?
A deeper explanation will help other people help you.
The roon setup, even with the DSP off and all the volume and stuff turned off, sounds not as good. In fact, its so much different it can’t be just a cable or config, IMHO. Its like something is changing the data or timing that is fairly invasive.
Of course with most systems these changes might not be audible, but, with this rig ANY change to ANY part of the system is audible.
So I am looking at RAAT. Someone step me thru how a packet goes from the file to the DAC chip. With a lightweight implementation the packet goes from the server ( Melco in this case ) thru the switch to the DAC chip. There is no DSP or any way to do math on the packet. So how does the roon solution run packets thru the system. Step by step if someone would be so kind
As far as the “dirty” side of the network pre optical isolation goes, Router Mikrotik CCR1036-8G-2S+EM, dual link ethernet LAG connection to Arris SB8200 ( Cox 1G service - Broadcom based ) cable modem. SFP+ Direct connect cable ( 10Gbs ) from router to switch. Main switch for the house Netgear m4300-48x with a mikrotik SFP+ module, single mode fiber, duplex, to the “clean” switch that is T1 clocked.
With all the above the Melco + CH Precision app solution sounded STUNNING.
As a point of comparison, we hear no difference on my Linn system between Roon and Linn’s own software. So, one question to ask is whether the software/firmware that translates Roon/RAAT to a synchronous stream going to the DAC(s) in the SGM Extreme may be out of data or buggy.
I am a noob at roon. I assumed it was a lightweight system with a really nice GUI. I am now seeing its a heavyweight solution and it touches packets. Feel free to slap me and make sure to double check me for easy mistakes.
I will be back infront of the system on wens and will more completly explore things on config again.
Is RAAT a encapulation protocol ? So it leaves the data 100% unaltered ? This seems unlikely as it can do DSP and volume.
I have looked thru the KB. I did not find a flow diagram ? Yes I understand that RAAT is the streaming protocol that connects the core to the DAC. Its a seperate issue from processing the packets.
So a byte is read from the file that is either in the core file system or external. This byte of audio data is then presented to the “core” for math. The math can be disabled fully ? no up/down conversion ?, the byte comes out as the same value that went in ? This byte is then held in a buffer to be read out when the synchronous clock requests it from the RAAT protocol based on the DAC timing ? Is there encryption before / after transmission ? Once in the DAC the byte which matches what came from the file is then fed to the DAC for decoding like a normal 16/44.1 ?
Is this basically it ?
I want to be sure that roon can be set to not alter the values of the bytes from the file.
Also all this alters timing jitter. So then RAAT reclocks things based on DAC timing. I can’t find any documents on the RAAT protocol and how it does this ? Is this a published standard ?
Yes it can be setup this way. You already saw the other thread where simple methods to self-control the bit-perfectness are discussed. You can also see what’s going on by taking a look at the Signal Path.
I guess this is intellectual property of Roon Labs LLC.
Note: RAAT is a network protocol. It has to be implemented on the DAC/Streamer/Bridge by the respective device manufacturer. Roon Labs LLC has the Roon Ready certification program to ensure the manufacturers do this in a proper way (Partner Devices Matrix).
Do you even use RAAT between your Core and the DAC? As your system description above feels a bit lacking about the interconnects and protocols in use between the different devices, I’m not sure about this.
Hmmm… I assumed if you hooked a roon ready DAC and a Core together it talked via RAAT ? This seems to be a propriority non-disclosure kinda protocol ?
The simple topology of the system is:
Roon core > SFP+ / optical > switch > Ethernet > roon ready DAC…
Switch has a SFP+ optical to the outside world + Aruba wifi to apps…
This would seem to be what RAAT would be made for ?
I will be in front of the system tomorrow and will now be more fully armed to look thru settings and will report back.
Seems strange that you have such a different “sounding” sound from Roon. I would say that it should be the configuration that is lacking in some way. If you have setup a core and an end-point there shouldn’t be any problems. If Roon says it’s a perfect signal it should be.
I have tried some of the most state of the art SACD-players (and Chord Blu MK-2) connected to my Chord DAVE and I can honestly say Roon sounds just as good.
Roon transmits the PCM bit-perfect over RAAT to the endpoint as long as no processing is enabled. There are posts you can find from years ago where other users have compared the pre and post RAAT transmitted PCM waveforms.
I will verify settings… Its most likely a noobie mistake.
There is still a difference in packet jitter. From what I can figure out about RAAT its bound to effect jitter. Digital straming is a freaky beastie. Everything effects sound in a sometime amazing way even tho it seems impossible technically. Differences in Ethernet cables for asynchronous data transmission for example. This makes ZERO sense as the data is clocked into a buffer in the DAC. My best guess is RF is just traveling all over components and leaking into things. I really don’t know…
Switching to a synchronous transmission method is interesting. It should be best if a good clock is used on the DAC and RAAT derives its clock from the DAC. Im a bit confuzed tho as the physical layer of Ethernet has its own clock so unless those 2 are at least phase locked some jitter would result ? The Melco + Clocked Ethernet switch + CH C1d were clocked from the T1. This locked the physical Ethernet layer phase wise to the data clock. At least that sounded like what it did anyway… hahaha… The setup was jaw dropping, even by high end reviewer standards. The room and the rest of the gear helps.
Im sure you guys are right, its a simple setting. But there are not many settings.
Im going to get to the bottom of this. Ive seen a lot of people with high end systems post it sounds the same, so, I must have something wrong.
For anyone willing to try and who has the right gear, it should be simple to look at the word clocks at the input of the DAC chip for roon VS a lightweight player to really verify its the same. Not the reconstructed waveforms, the actual bytes. Checksum it. Pull a file thru both and checksum the results. With a data analyzer this should be fairly easy and this would be conclusive.
Its not RAAT im thinking about. Its the core. Its the WHOLE end to end system.
So if you collect the word clock bytes in a big file directly from the DAC chip input pin into a file and do the same thing from a lightweight solution these 2 should match bit for bit, right at the DAC input pin. This would validate the entire chain as “bit perfect”. Assuming of course you use the same input file.
All of that tho is completely different then jitter. The roon solution in RAAT is a better choice technically. Synchronous transmission based on the clock of the DAC is a elegant solution… This is done however on a higher layer then the physical ethernet layer clock. So there may be induced jitter based on the physical ethernet clock if the DAC says send a packet, the physical clock of that data has to wait for the physical clock cycle. If these 2 are phased locked tho, this is minimized. So IMHO the Ethernet clock needs to by phased locked to the DAC. But im just guessing mostly there if that effects audio quality.
You still have the entire chain as “bit perfect”. There might be things that are yet to be discovered in what we can call “network audio” but Roon is bit perfect if setup correctly. Asynchronous or not.
