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.