Technical and Subjective Differences Between Roon and JRiver Media Center

By request . . .

Please let me know if I made any mistakes or if you need anything else.

1 Like

Probably its own topic but…
Roon Core sends bit perfect audio streams over the network. This can be and has been tested.

Now, I’m not one to believe bits are bits and we’re all hearing the same thing but if you’re using a network bridge / streamer then Core has no influence on the sound (as long as its not under-powered, network is up to the task, etc.). You’re hearing closer to what your digital chain actually sounds like. If one thinks Roon Core sounds flat or dull you can throw HQP into the path and you’ll get that sparkle back. However, you’ll no longer be feeding a bit perfect stream into the DAC. edit: Most digital playback sounds dull and lifeless. Roon exposes this. There are excellent digital playback systems powered by Roon but it requires synergy like any other playback system to get there.

Back to the PS discussion. AirLens, on paper, appears to be the right design to feed it a bit perfect audio stream and it will get this stream up to the DAC with less jitter and noise than many other designs. I’m seriously looking forward to review but this is a tough space to show value. A budget for a streamer starts at about $50 and goes into the low 5 figures. It’s also one of those devices that will show significant diminishing returns.

While a server from PS would be nice I’m happy they decided to drop it (for now?). Influence on sound quality from the server is even less than a digital transport. It’s less about sound quality and everything about the user interaction. User interaction is expensive to “get right”. I like that PS has decided to put their R&D towards enhancing the sound quality of my system. Let other companies worry about how I click “play”.

My $0.02 of course (I have yet to adjust this for inflation).

3 Likes

FWIW, I can stream the same file from my iMac using Roon or JRiver Media Center with my system.

In general (i.e., more often than not), I tend to prefer the tracks when rendered by JRMC over Roon.

Others have reported a similar preference.

It’s been a while since I have paid any attention though, and there have been changes to both the Roon and JRMC software. Maybe I am overdue for some comparative listening?!

(By the way, I bypass all DSP settings each SW offers.)

1 Like

This is a general statement but I’ll use Roon as an example because, depending on your endpoint, you can set this with Roon. I find buffer depth of the stream can influence sound quality in very subtle ways. I have my buffer set to 5ms in Roon on my main system and find it sounds better than higher settings. This is sort of the opposite of “memory play”. I do find systems that support memory playback, that is loading the entire file into memory before playback, to sound good too. Why would this matter? I can only speculate and probably worth its own topic.

The transport can have influence on the sound and, since Roon is the only thing supporting RAAT, comparing RAAT to DLNA (I assume that’s what your JRiver set-up is using?) is more a comparison of two different transports rather than anything Roon Core or JRiver is doing to influence the sound. A design like the Airlens should eliminate (reduce) these differences though. It would be nice to hear from PS on this topic.

Anyway, listen to what sounds good and use a system that makes you want to listen more. That’s the most important for sure.

2 Likes

Great post.

Maybe, but I need some definitions and a better understanding of these distinctions; and you probably need some more details about my system to address/confirm this observation may be relevant.

I hope you will indulge me and educate me with some follow up…

Here are some system details (since I am not an IT systems/network guy I hope the details are somewhat germane):

  1. Both JRMC and Roon core are hosted on my iMac.
  2. I’ll double check later but, again, JRMC and Roon SW settings are set to bypass all DSP-ing of the “output”.
  3. My 1s and 0s are transported from JRMC and Roon over Wi-Fi to my garden-variety ATT modem/router.
  4. From there a combination of Ethernet and optical cables deliver the signal to to the PSA Ethernet Bridge (MK II) card and the DS Sr. DAC.
  5. The digital files share the exact same path from the iMac all the way to the DS DAC.
  6. I will double check, but believe all DSP setting are still defeated w/r/t to each of the software packages.

Given all of the above, is your point still relevant? Do I have two different “transports” at work?

Thanks in advance for your feedback. I have long wondered what might differentiate the perceived performance of JRMC from Roon.

Best regards,

SEE

(PS, I think I am “all DLNA” in my setup. Does that makes sense? Heading to google to understand RAAT vs. DLNA better now.)

(PSS, Just back from the Roon forums…Now I am no smarter knowing that RAAT is the Roon Advanced Audio Transport…still reading up.)

1 Like

I need to get going… can dive into this later if interested. I’ll touch on the differences though…

DLNA works closer to moving files around. That means the renderer needs to be able to decode, and does decode, the file for playback (FLAC, mp3, WAV, etc). The DLNA “system” has no idea if the file being sent across the network is arriving slower or faster than it is being played back. Effectively, think of it as a very nice way of pushing media files around.

RAAT embeds the bitstream into the payload and does understand overruns / underruns of that bitstream into the DAC. The bitstream being PCM or DSD. Core is responsible for extracting the bitstream from the file format (WAV, FLAC, mp3, etc.).

Ultimately, the same bitstream is (should be, in your setup) what hits the DAC(the chip doing the conversion inside the box we commonly call “DAC”) but what is being sent on the wire and the timing, buffering, etc. just ahead of the DAC is very different. That difference may be what you’re hearing which is why I say it’s more a comparison in sound of DLNA vs. RAAT.

2 Likes

Thanks for your time.

One, initial follow up question/clarification…

I don’t have any Roon endpoints (or any other kind of similar devices) between the iMac and the Bridge II/DS DAC. I am assuming that does not matter in terms of the potential difference between RAAT, which is inherent to the Roon Core software and the fact that JRMC uses a DLNA-compliant protocol to allow for network sharing of the digits. Correct…?

Thanks again for your time.

Regards.

Thank you @Elk.

SEE

1 Like

OK, been a while since I did anything with DLNA and me reading up on it again just reinforced my distaste for it. But I digress.

Let’s start with the PS Audio Guide for setting up JRiver…

The key takeaway here is this:
Under AUDIO make mode-ORIGINAL and format-24BIT

This instructs JRiver to push the file to the renderer (the bridge card). This is not what Roon (RAAT) does.

Roon Advanced Audio Transport (RAAT) decodes the file to its native PCM / DSD and sends that bitstream, the raw bitstream, to the Roon Endpoint (audio device).

Now, why my distaste for UPnP/DLNA? Many reasons but in this context there are a dozen ways to send stuff to a renderer. You can send the file, the bitstream, a transcoded bitstream and/or file, etc. It all depends on how it is configured and/or what the renderer supports. To make things worse, what a DNLA Digital Media Renderer must support is different than what a UPnP rederer must support even though the way the server is instructed to push “media” is the same. Danny, COO of Roon Labs goes into this deeper What's wrong with UPnP? - #3 by danny - Audio Gear Talk - Roon Labs Community

But, there is an inherent issue with sending PCM / DSD bitstreams in that the sender needs to know when to send data. Most bitstream based protocols use the sources clock. If the reciever’s clock drifts from sender you can run into overruns or underruns in receiving the bits you need early / late. RAAT solves this by synchronizing the senders clock with the receivers clock (which, in Roon Ready devices, is supposed to be synchronized with the DAC). Roon does’t provide details on exactly how it does this though.

But, let’s get back to your specific configuration.

But not the same network transport / portocol assuming you’ve enabled the Bridge as a Roon Ready endpoint and followed the JRiver set-up per the PS guide I posted above. In these two set-ups what hits the ethernet wire and enters the bridge will be different. However, the PCM should be the same. Why the protocol difference influences what you hear from the resulting “bit-perfect” bitstream at the DAC I can only speculate… maybe later if I get time to write it as this is long enough. But, it does sound different.

You can verify this with the Roon Signal Path but I don’t know anyway to see this level of detail with JRiver. The JRiver docs simply state that mode ORIGINAL is the file. There are other modes which will send the bitstream but those might not be supported on the Bridge card. With RAAT it’s always the bitstream after DSP but before volume adjustment.

3 Likes

Yes, the crux of the matter.

Thanks for the information. It really was informative.

Regards.

2 Likes

There was some chatter on the last D&D podcast saying that the way different software packages open and transmit the file causes differences in the playback sound of delivered bits. I know nothing about the subject though.
Personally I prefer to use Roon no matter of any perceived differences in playback SQ.

1 Like

nice write up @ipeverywhere . Roon team has take great experience at this and has taken much effort to get the best out of their product sound wise. Its pretty incredible that such a small company has so many high end vendors jumping on board. Look at PS Audio. 5 years in the making and they just threw in towel and said just use Roon. Its becoming the Dolby of two channels. If you dont have it, you will be limiting your sales of an already small (High end audio) market.

I’m a huge fan of Roon but I do try to keep it in check :slight_smile:

People forget how long Roon has been around. The core team started building in 2004 and that effort became Soooloos. That was picked up by Meridian 2008. Meridian’s last release was 2017 (IIRC). The Meridian Sooloos group was spun out as Roon Labs around 2014. The first version of Roon was released in late 2015. There has been significant changes to Roon since then and especially when we remember 1.0 had no streaming support (no Tidal no Qobuz), RAAT wasn’t a thing (or at least a completely different protocol), etc. I jumped in with with an early 1.7 release so I missed all the “fun” I hear stories about earlier versions. Why do I know this? I bought a lifetime sub and I don’t drop that kind of coin on cloud software without making sure I have a comfortable understanding of the companies “lifetime”.

Anywhooo… that’s a long journey, experience, industry contacts, lessons learned, on and on that no one can just “pick-up” overnight (which might make Roon Labs an acqusition target but story for another day). I don’t agree with every decision Roon makes or some of the opinions they have that drive their development decisions. But, at the end of the day, they get it more right than wrong.

I do believe it will stay a niche product though. At least until they can get more “social” features into the app. You can be perfectly successful building a product that supports Google Cast, Airplay 2, Spotify Connect, and Tidal Connect. That covers the majority of how people listen. The majority will be comfortable with native apps. It’s more important to get the native apps to play nice with the gear than make it work with Roon natively (RAAT). For the minority that wants to continue curating their own libraries then Roon continues to be a bigger part of that discussion. Within that minority is another minority who cares deeply about sound quality and that’s when “audiophile level” Roon Ready electronics become important.

1 Like

Depends on how much growing pain they want to absorb and how fast. Plus that majority you speak of is not willing to spend another subscription to organize and search for music. Which is what roon is about. Its not about the how it gets to you, but how you discover. Anyone that wants to discover music and start easy with a Nucleus and ipad. Use use airplay to most any device you have. Or if you have roon ready device great. For us fanatics its about how it gets as well.

Their next big move is to portability. Roon app talking to a Core “somewhere” to use roon. Where that somewhere is, cloud or your home, depends on how they implement. Cloud costs money for them to host. Cost would have to go up substantially for them. Plus you still need that sort of vpn tunnel back to your library. Upload library to cloud could be option, again cost you more for storage. If I was to build it I would make a Roon VPN plug in or add on somehow. Runs as part of the core. Have to authorize a device somehow to control and become an endpoint. That’s where it gets interesting. How many different endpoints do you support. Not sure I want my phone DACs as endpoint. Might as well just do tidal remote. Its a complicated mess when you look at the logistics they have to solve (as you can see I am in IT and I do this solutioning for a living). Good luck to them and I know they have said this is one of their top priorities.

I actually have thought of doing some sort of firewall/VPN solution from home to work and bring my matrix DAC there with my Focal Cans. Would be a blast, but the noise would bother others and I am always in a meeting anyways…so I did not pursue.

I would like to see this come to fruition. I am inclined to think the sheer scale of the internet of things and the ever decreasing cost of moving and storing data (along with the ever increasing speed at which data can be moved) will allow for this to be a must-have feature sooner, rather than later.

Fingers crossed…

It would take me weeks to send my library to cloud. We deal with this with our data at work, and we have 10GB pipes. The would presume buy a block on AWS, buy some compute for the Cores, then what about someone if they use DSP…there goes the compute up. In the cloud you pay as you go. Some plans you pay nothing to put up but pay a ton to bring down. You have AI that moves data around to slower storage if not accessed in a while. Its not just a pure pump and dump unless you pay for that. Takes time too. If they go pure core in cloud it will be small steps my guess. Tidal/Qobuz only, not local library. But you get the search and roon organization. DB stored in cloud. Probably no DSP and not sure how you would connect local end point to the cloud? needs something in the middle. maybe re-coded remote app that acts as a bridge. Making my own head spin. No wonder why its taking so long. Glad its no my project.

1 Like

I am a bit ignorant when it comes to these matters…I was thinking something along the lines of accessing my home computer and/or NAS devices remotely.

I don’t do the cloud for storing personal digital content. I think it’s the Boomer in me.

:wink:

1 Like

When extreme weather took out our internet but not power for two weeks last year, I was glad to have my music and video collection on my home server. I do use the Plexamp app though to stream music from my house to my car, when not using a USB stick in the car.

Bandcamp works for me for discovering new music. And Qobuz, Tidal and Juno keep sending me regular updates on new material as do some DSD sources like NativeDSD and Octave.

Regarding technical matters, if one has bought into a DirectStream DAC, with its own upsampling and filtering processes, does it make sense to do any sort of signal processing in a software like Roon or JRiver?

And do I understand correctly that one needs to be extra careful with JRiver to make sure that DSD source files are not reprocessed into PCM? That does not seem audiophile to me.

Can’t getting music files to a PS Audio DAC be simpler, despite their not having their own app? I know this thread name only mentions Roon and JRiver. But how do they compare with the likes of Euphony Stylus or Audirvana when it comes to sound… not app features.

Perfectly relevant regarding sorting out how this type of software works and can sound different; and I hope folks that have some experience and knowledge chime in…