Many of us love using Roon’s powerful DSP engine, especially for features like convolution for room correction, parametric EQs, and upsampling to high DSD or PCM rates. However, these features are CPU-intensive and can push the limits of even capable Roon Cores, leading to audible clicks, stuttering, or dropouts during playback.
The Proposal: A Playback Stability Buffer
I’d like to propose a new feature: a “Playback Stability Buffer.”
The core idea is to allow users to dedicate more system RAM to pre-process and buffer the fully rendered audio stream before playback begins. This would trade plentiful memory for CPU headroom, creating a cushion that prevents real-time processing spikes from interrupting the audio. It would make Roon’s most demanding features more stable and accessible to users on a wider range of Core hardware.
Suggested UI and Implementation
This feature could be elegantly integrated directly into the DSP Settings page for any zone.
Clicking on it would open a detailed settings panel, clearly explaining the function and its trade-offs.
Key aspects of the implementation would be:
Clear Options: Offer simple presets (Default, Stable, Extended) that cover most use cases, plus a Custom option for advanced users.
Explain the Trade-Off: The UI must clearly state that a larger buffer will increase RAM usage and add a delay when starting or skipping tracks.
Visual Feedback: To make it even better, the “Now Playing” seek bar could have a secondary, lighter-colored bar showing the amount of audio buffered ahead of the playhead. This would provide instant, intuitive feedback.
This feature would be a game-changer for power users, allowing us to push the DSP engine to its full potential without compromising on playback stability.
What does the community think? Would this be a useful addition for your setups?
Disclosure: This post was generated with the assistance of Google’s Gemini.
Which is why Roon will display processing speed in the Signal Path when DSP is applied.
Indeed, additional buffer would not solve the issue, since it is processing, not memory, that maxes out. That is, the processor can’t perform the task in real time. So, buffer size becomes irrelevant because, eventually, the buffer, whatever size, will run out because processing can’t keep up with playback in real time.
Moreover, please do not use AI to generate content, as it isn’t permitted in the community guidelines.
Remember, this is a space for sharing your ideas. We allow tools and apps to assist with translation, punctuation, improving clarity and sentence structure, etc., but long-form AI-generated content is discouraged. Community is for meeting and forming friendships with other people, not large language models.
Too much of your post is generative AI, and consequently, inaccurate.
“your solution” would really just move the problem somewhere else: when choosing to play an album, user would have to wait for X amount of time before hearing anything while Roon will have to render the audio stream completely before delivering it to the client.
I haven’t proposed any solution, but you have, and you describe what will happen with it. If the CPU cannot cope in real time, no amount of buffering will help.
The solution is simple: use an appropriately specified computer for library size, number of zones, and DSP performed.
As I mentioned earlier, your OP uses inaccurate AI-generated content, so adds little or no value.
Let’s use a simple analogy using water. You have a 100l tank, the buffer, and a fountain pump capable of delivering 300l an hour (the CPU). The buffer is replenished in real time (the audio stream).
To produce a 50cm fountain, the pump must deliver 50l per hour. However, a 5m fountain requires 500l per hour.
Replacing the tank with a bigger one will not help since the pump can only deliver 300l an hour. So, it isn’t possible to run the pump continiously above 300 litres per hour.
You may have loads of cores, but my guess is they are not so powerful, and may not perform as well as an i3 or i7 NUC. Memory is not going to help either. Remember single thread performance is paramount when choosing Roon server hardware.
Appreciate the reply and the analogy. The extra buffer is to avoid choppy audio from time to time. Not all the time. It’s to apply a convolution filter i created for my room, when applied to the DSD audio.
I have two machines that I have tried. I thought I’m the DSP had a feature that allowed parallelization, but I agree the CPU clock / feature matters as well.
Both machines are relatively powerful. One is i9, with 32 cores, clock goes as high as 5Ghz. The other one is an AMD with 64 cores, one socket. Also great clock speed. I can get you the core info in another post (writing from mobile).
My first post was AI rephrased for clarity. I’m a software engineer. Although I haven’t written a DSP, I have worked in relative low level projects (kernel, drivers, database engines, etc). Happy to connect in LinkedIn
I believe I have great hardware specs, Roon should not struggle.
Let me ask, what are the hardware specs for running a convolution filter on DSD128 that had worked fine for the team? Probably that could help me.
Roon already has a buffer for this scenario. Simply pull the network on a streamer, and playback continues for a few tens of seconds. If there’s no processing speed displayed in the signal path and you experience choppy audio, you may want to look at the network or host system if Roon is one of multiple workloads.
You also state in your OP …
This type of DSD is going to be CPU-intensive for the entirety of the track or release, so expect to see processing speed displayed in the signal path.
To avoid problems, the processor will need to perform such an operation with a single thread (this is how Roon works.) A Passmark single thread rating of 2500 or more should handle most DSP.
I moved RoonServer to my laptop when I saw that the desktop didn’t handle the load anyways. The computer is connected through ASIO, I also increased ASIO to 2048 samples (if that matters).
I run Windows. I can also try to change the process affinity to a subset of cores, if that may help.(?) – I can reproduce without anything else active (e.g., no editors, compiler, or anything like that, just roon opened).
Both have single thread performance of around 3000, so CPU is fine for most DSP. If you have a scenario where you get dropouts, share a screenshot of the signal path in Support.
I’ll switch to converting DSD to PCM and then apply the convolution filter. That gives me 3.5x rate instead of 0.7x. 0.7x would require a 90 seconds buffer (ish).
Still wondering if there is any CPU that can actually process this base case scenario of DSD64+convolution filter. If not, or not tested, we should probably disable it.
