When I was using a different high end software player, I noticed in network view of Task Manager there would be a huge spike in network receiving activity when I started to play a track (my music is on a NAS). After a few seconds, the network activity would stop, presumably because the entire track was downloaded into memory. Using Roon with HQP, I notice consistent network activity throughout the duration of the song. The network graph has a very consistent saw tooth appearance to it with spikes every few seconds. Is it safe to assume that Roon does not download the entire track into memory? If so, why not? Everything I have read (including my own limited tests) has been pretty unanimous that playing from memory is better.
2 Likes
Roon does not play back from memory, but to be fair, if your using it with HQP then you should say HQP does not play back from memory because Roon in this case is just handing the stream off to HQP and not really doing anything.
1 Like
Thank you. I wonder why Roon does not download the complete file into memory? At least make that an option like in Jriver?
Here is what happens with Tidal.
I would be surprised if it does not work pretty much the same off your NAS but obviously the Roon team would need to confirm.
Network activity would also depend on your setup are RoonServer and HQP on the same machine and is your DAC attached to that same machine or are you using an NAA?
HQP and Roon are on the same machine. DAC is also attached to same machine. I also do not use NAA yet.
1 Like
From a SQ perspective you should be more concerned with feeding your DAC directly from the PC on which you’re running HQP than whether or not Roon is preloading an entire track to memory before streaming it to HQP from memory.
Memory play feature are, in principle, about separating playback and loading activity to prevent the loading activity from influencing local audio playback hardware via analog domain interference.
The way to accomplish a truly comprehensive memory play feature is to pre-load the entire playlist before the listening session starts, and then lock it against modifications for the duration of the listening session. This would guarantee that loading/playback never happen at the same time.
The reality is–the popular players all fall short of this, because it’s not acceptable to make the user wait for minutes for the music to start, to limit the length of a listening session, nor to prevent the user from reordering the play queue while they listen. All of the popular implementations we’re aware of are performing loading activity during playback under some circumstances They’ve just done things to shuffle the loading activity around in different ways (for better or worse). These features have always felt a bit misleading/dishonest as a result.
As you’ve noticed in your analysis–Roon opts for steady, consistent loading activity by keeping a fixed-sized memory buffer full on an an ongoing basis. Some other software opts for a more bursty approach, racing to fill a buffer each time the track advances. We prefer the steady way because bursts of high level activity are more likely to result in audible defects (especially the worst kind of audible defect: spinning up a fan) than steady, low-grade activity.
Another important thing to keep in mind: Roon is a multi-zone, multi-control-point media server with a library management system that is many times heavier than the lightweight players that typically implement memory play. It’s really a very different kind of system–so the best way to build, optimize, and configure it is not necessarily going to be the same.
As a media server, Roon performs background work–periodic syncing with our metadata servers and with TIDAL. Audio analysis. Filesystem watching. Metadata identification. And so on. As a multi-zone, multi-user product, someone anywhere in your household could kick off file loading activity at any time because they want to browse the library or kick off playback in a second zone. Unlike with a simple, single-zone music player, it is often impractical to reason about about file loading activity during playback in a system like Roon.
We don’t want to force a compromise between feature-set and sound quality–which is why we built RAAT, why we are continually working with hardware companies to get it implemented in a turnkey way (18 Roon Ready products have been certified in the past 6 months), and why we released Roon Bridge–so users could access RAAT without paying big $$ to a hi-fi manufacturer.
RAAT gives you the tools to isolate the media server from the listening environment, which basically moots the goals of “memory play”. Neither analog domain interference nor fan noise are much of a concern if the media server is in a closet far from the listening room.
See this article for a high-level overview of Roon’s architecture
See this article for an overview of how we believe you can get the best SQ from Roon
See this article for some background on why Roon is based around a powerful Core and how we use it
I’m open to discussion regarding memory play, particularly if someone can explain:
- Exactly how a memory play feature should work in a media server like Roon, both in terms of user experience changes, if any, and in terms of what is going on under the hood, when/how buffering takes place, etc.
- What promises a memory play feature in Roon should make–as I explained above, most other memory play features do not completely separate playback and loading activity. If we simply copy other players, neither would ours.
We are hesitant to make a dishonest feature, and are committed to being open and honest about how our system works to a greater extent than is typical in this space–so whatever commitments we make must be defensible.
19 Likes
Well I am surprised as it seems local files are handled differently fromTidal. See this post from Brian in another thread.
Seems that if you compared playback of a flac file of the same resolution on your NAS with the same track from Tidal you could see if there is any benefit in memory playback or not.
The cache for TIDAL content is stored on the drive that holds the Roon database, not in-memory–think of it like a web browser’s caching of a web page. It’s functionally and underlying implementation is very similar.
The motivation behind the TIDAL caching is twofold:
- Improves Stability when dealing with real-world internet connections
- It makes seeking faster in TIDAL content–seeks suffer a lot when your ping times to the TIDAL CDN start to creep up towards triple digit milliseconds.
Neither of these are real concerns with locally stored content. The purpose of the TIDAL cache was to get things working properly and well–it was never about SQ.
I would hesitate to do any A-B test of TIDAL vs local FLAC without first making sure that the audio bits are identical. This is not impossible if you’re willing to poke around and confirm, but it takes a little bit of doing…it’s just very difficult to be confident that a track on TIDAL is exactly the same as the one you have on CD by looking at the metadata alone.
2 Likes
I’d venture a guess that most of Tidal’s older content is going to emanate from remasters rather than the original CD releases, so it’s probably unlikely that they’ll match in most cases unless one’s collection is recently acquired.
1 Like
couldn’t memory play be a user selectable option (with a slider for setting the amount of memory to reserve for this purpose)? this is how it was in the app I come from
that app used to load tracks accordingly to user’s settings on playback start (delay was a very few seconds only) then… no idea when buffering was taking place again afterwards
I do understand there are many usage scenarios, but there are also some using a music only dedicated computer with plenty of RAM 
does memory play, then, actually make a difference? hard to say but… why not having this option too? 
new Aries’ beta fw just introduced it, claiming it brings dramatic SQ improvement
they say it’s not possible, though, when using it as RAAT
but… you don’t need to make any claim
2 Likes
I know a lot of Roon (+ HQP) users fall into this category.
It would be cool to have this as an option though.
Why’s that, would anything tangible be gained?
Do we know for sure that nothing “tangible” will be gained?
1 Like
Personally I’d rather see development effort directed at enhancements that will without doubt or conjecture deliver tangible value.
You state in the OP that you are sending the stream to HQP. In your case, HQP should be the one doing the play from memory option since that is the software doing the actual playing. Have you requested the same feature from HQP?
I dont disagree with you. Us crazy audiophiles only make up a very small percentage of music lovers out there. However, I have a feeling though that audiophiles are the ones that are most willing to pay $100+/year for Roon. For me, having used all types of (much cheaper) music playback software like Jplay, JRiver, etc, memory playback is an option so I guess at the price point Roon is offered at I would expect these types of basic features.
Actually I did and the developer basically said to ask Roon. Lol. I guess the logic is that its Roon that is receiving the music file and passing it along to HQP for processing.
1 Like
Because the RAAT implementation is already “memory play” – the Aries will not be reading/writing the RAAT content to disk ever.
We know this, because we wrote the code for the Aries and any other Roon Ready device.
Because features aren’t free to build, support, maintain, explain, defend, …
That doesn’t mean we don’t build features–but it does mean that we will insist on “doing it right” and building sound, defensible features.
That makes sense–HQPlayer is not able to re-arrange when file loading activity happens since Roon manages that part.
2 Likes
no rush here: I’m on a lifetime subscription 
and… you already know how I feel the Aries sounds standalone vs as RAAT 
(I’m not saying memory play is what makes the difference)