Option to enable RAM memory playback [to avoid caching problems]

I definitely perceive a slight delay too (My analysis suggests that this is a delay while it opens/configures the audio device and possibly pre-rolls a small pad of silence).

For something simple like a 16/44 FLAC, the pre-buffering is very, very fast, and it might be very hard to tell what’s going on. I deliberately chose an expensive DSP use case for that animated GIF I posted (DSD64 -> 44100) so things would be slow enough that you could see how they actually line up in time.

Click that image to see it animate–does that jibe with what you’re seeing? If you play in one of these expensive conversion cases, does it make you wait, or does it play in parallel with decoding like it seems to for me?

Yes, that gif is the same thing as what happens when I play A+.

Yes, here too. That slight delay happens on the first track loaded. I have never had anything take too long to preload, but I am fairly sure that the music starts even while the track is loading, say for a 24/192 file. I would guess this might be determined by or related to how much RAM you allocate in the settings for use in memory play.

@brian What are your thought about improving sound?

@allenbretao Hi- I don’t mean to insult your intelligence or confuse you. I am serious as a heart attack about Music & audio and much of the technical side, for me, has to be supported by evidence.

It is just as important for those who love music to understand the technical side as it just important as those who love the technical side to understand music. This duality brings out true appreciation for the art.

I urge you not to take offense, because I too want great sound, I am just asking questions.

Fair enough Bill, we are on the same side really :smiley:

1 Like

@brian What are your thought about improving sound?

I’m going to start with some background, and my philosophy on this stuff, then get to your point.

In terms of EM/RF noise, computers are noisy things, and in general, not a great thing to have near audio devices. From our perspective, the first class solution will always be to create some separation between the media server and the endpoint. USB is not a great choice for this. Ethernet is much better.

I have a nice DAC here that I use as a headphone amp and sits on my desk ~3ft away from 2 computers. Not going to name names, but it’s in the $1-2k range, and it’s very highly regarded at that price point. It’s plugged into computer A. If I play silence to the DAC from computer A, and scroll my web browser up and down on computer B, I can hear it in my headphones. They aren’t even directly connected.

This is what computer audiophiles are battling and, frankly, no matter what Roon does on computer A, it’s not going to stop that sort of interference from having an effect on SQ.

Computers are also complex, and don’t always emit a constant amount of EM/RF noise. So the idea behind a lot of what Audirvana does is: the more subsystems of the computer that can be disabled, moderated, or avoided, the less potential noise will be emitted. So it helps you turn off spotlight indexing (sysoptimizer), preload tracks into memory so we can stop dealing with the disk/ssd (at least most of the time, when pre-loading isn’t happening), and so forth.

This seems sound to me, and there’s no reason why Roon can’t provide some similar functionality in the future. It’s a nice thing to do, and not a huge effort, and it will make things better for people who drive their playback from a computer.

We come from a background in networked media servers, and we began actively moving away from playing audio from computers in the Sooloos hardware in 2009, because there were huge SQ benefits to be had by moving that way. We needed the benefits of a heavyweight media server, but we also needed the benefits of a lightweight audio renderer. The most elegant and complete solution is to put some separation in between them.

As for memory play specifically. I can see how it might help, since once you’ve pre-loaded, there’s less work going on in the computer (CPU can scale back down if there was DSP being pre-cached, and disk activity reduces significantly).

As an engineer, this feels like an unsatisfying solution. We can impact the noisiness of our computers by tiptoeing around their limitations and applying band-aids like sysoptimizer or memory play, or by hunting for system services to turn off. In the end, even with everything done “right”, there’s still a giant noisy motherboard, cpu, power supply, and gigabytes of RAM sitting there doing something. Almost no matter what, that is going to be noisier than a well-engineered embedded system built by people who understand and care deeply about sound quality.

This is where we are going with RoonSpeakers and why we are working with manufacturers to make networked endpoints a viable option for as many people as possible. This is where we see high-quality computer audio going–server on the computer, and endpoints driven over ethernet. It’s better for SQ, and takes pressure off of server software to be lightweight to the point where browsing functionality and metadata capabilities are sacrificed (a la Audirvana).

9 Likes

@brian I share this perspective too.

I am super excited about this!

Thank you for your lengthy and detailed repsonse. You’re awesome! :smiley:

Yes, thanks Brian!

I tried this tonight and I was not able to repeat your results.

iMac
MacBook Air
Audioengine D1
tracks were intro silence on Korn’s “Follow the Leader”
Grado SR80

Computers very close, 18"

My suspicions lie with the thunderbolt monitor plugged into computer B that sits right above the DAC. It’s backlit by a tube, has a busy USB hub built in that’s carrying the traffic to/from my mouse and keyboard, and has all of that high-frequency displayport junk going on.

That said, I have other DACs here (both cheaper and more expensive) that seem to resist interference better. The Meridian Explorer, even at $300, seems to be good at staying quiet when placed on the same desk, even though in general, it doesn’t sound as good.

Fair enough. There are published resources that discuss USB 3.0 and Thunderbolt high frequency issues

It’s a high value product and the Explorer2 improves the feature set. I look forward to the Exporer2, Tidal, and Roon being apart of the most commonly found set-ups. (Certainly less than a MDMS C series!)

Thank you for your response and let us know what Roon plans on doing.

@brian
But surely your problem is EMF affecting the analogue signal through your headphone cable and has no bearing on the digital side of things ?
When you use other DACs I also assume you leave the main one where it is, and position the “alternative” DAC elsewhere, causing / necessitating a different cable routing - perhaps further away & less sensitive to the EMF…

Could be EMF through the headphone cable, or through the analog stage of the DAC. It’s not a digital domain problem.

1 Like

Like to see memory play integrated into Roon.

This was already discussed here. Sounds like they said it would be an easy add once they switch over to 64 bit.

This is especially beneficial if one has a slow network devices, i.e. like portable wireless hard disk on the go. Memory playback is found in JRiver and can be enabled as an option.

See this comment that I just made in another thread…I’d be interested for your input on the points at the bottom. I’ve never heard memory play brought up in the context of stability before, so that’s interesting at least.

I’m tempted to say that if a storage device can’t deliver media at the required bit-rate, with our already-substantial memory buffering, that it not be quick enough to do the job.

We do take a more drastic approach with TIDAL buffering than we do with local/NAS content–primarily because when TIDAL was new and growing rapidly, their CDN was in awful shape–TIDAL does its more substantial buffering to disk, not memory, because memory buffering is significantly more likely to adversely affect performance/stability.

1 Like

Hi Brian,

In both case JRiver and Roon will playback immediately once I hit the play. JRiver is configured ‘Play files from memory instead of disk(non-zone specific’). The PC is connected via Ethernet and the source is NAS, test file is DSD128, 9 minutes duration. Take a look at the Ethernet performance in Windows Task Manager. In JRiver configured with memory playback, part of the file is copied to the PC in few seconds but the bit-rate jumped to about 700kbps and down to 0kbps. In Roon bit-rate peak around 24kbps to 35kbps across the 9 minutes duration of the track.I think playing back from memory is more fault tolerance against caching problem.

Jplay also exhibits this same “spike” behavior as well.

As an aside, it’s really more about latency than throughput; especially when you are looking at gapless playback issues.

I just moved my library from a WD MyCloud 3TB onto a Firewire 800 direct-attached disc on my 2011 Mac Mini and my occasional gapless playback issues disappeared.

Funny thing is: both my NAS share and the DAS HDD have very similar numbers with Blackmagic Speed Test. But NAS always suffers from greater latency in the initial read request - there’s more protocol overhead and the target has to react to the request, from an operating system standpoint. This is the case even with higher-end NAS devices, in my experience.

I never have these problems with MPD playback, using a mounted NAS share, and it’s my belief that MPD is more aggressive in pre-loading the next track to make gapless playback completely smooth.

So, it’s not that Roon needs more buffering, it’s that it needs to request it earlier in the playback process.