Possible to set Buffer Size to more than 500ms on RoonBridge linux? (SOLVED)

Folks

I’m running Roon Core on a linux box and RoonBridge on a linux box connected to my DAC.

When I do audio device setup, I see “Buffer Size” under advanced settings and currently I use 500ms. I am presuming this is the ALSA output buffer on RoonBridge? (I haven’t been able to find documentation on what this setting actually configures)

Generally speaking, I prefer ALSA output buffer sizes to be larger. I went fishing around the directory structure but couldn’t find where these device configs are persisted, but I did see them in the log (I’m presuming it is in the database?)

Is there a way to have a larger Buffer Size in advanced settings? If that is not related to ALSA output buffer size, is there a way to configure the ALSA output buffer size on RoonBridge?

Thank you!

From Roons KB

Buffer Size (WASAPI and ALSA only)

This setting allows you to tell Roon to request a specific buffer size from the driver. There is no guarantee that Roon will get the size you ask for, but it will try to choose the closest one.

In theory, all devices should be willing to accept any buffer size, but this is not always true in practice. Larger sizes aren’t always better! We get the best results in the 25ms-100ms range.

2 Likes

The specific documentation for this is buried in windows and Linux audio device driver architecture and API and driver implementation documents. An application can request a buffer size from an audio device driver within constraints that are determine by the audio device driver. Generally this audio device driver is class compliant USB 2 audio driver, but might be a device specific driver from the audio device manufacturer.

As I understand it, Roon endpoints maintain there own huge in memory audio streaming buffer (several seconds at least, if not a lot more if memory allows) and keeps the audio device driver’s buffer fed from that. This means that the audio device driver buffer does not need to be huge to accommodate network latency etc and instead it only needs to accommodate the response time of the Roon endpoint software which will generally be within a few ms most of the time, so a default setting will nearly always be more than adequate.

The situation in which it may not be adequate is that that computer is excessively loaded with other work loads resulting in dropouts and glitches. So the only time I would suggest increasing this is if you know the endpoint device CPU is struggling to keep up and you can hear regular drops and glitches. Often however these may have another cause.

1 Like

Thank you for the pointers and context! Good news that this setting is related to the ALSA output buffers

Any thoughts on how to get buffer sizes larger than 500ms? In my set up, I’ve found that SQ scales very nicely with ALSA output buffer size from my NUC (RoonBridge) to my DAC.

I have found where I can manually configure the buffer sizes. Posting info here for folks who search for this in the future.

Apparently, when you configure a network end point in Roon Core, the end point configurations are stored on the actual end point. On my linux-based NUC running Roon Bridge, the configuration file is:

/var/roon/RAATServer/Settings/device_9e7dfe0afa18e53fd8d0c57049692bc0.json

There is a different JSON file (device ID) for each core that I have that has enabled that Roon Bridge end point.

When you edit the file, there is a JSON parameter called “buffer_duration” (in seconds). I changed the buffer value here, saved, then restarted Roon Bridge.

Interestingly, after manually changing the buffer size, when I went to advanced device setup in Roon, the Buffer Size was shown as a dash ("-") in the drop down. Well done Roon dev team for not crashing out from an unexpected value!

I’ve been trying different values and am curious what value you’re currently preferring?

I find 1.5 gives a nice SQ improvement (fuller low end mostly and perhaps a bit less aggressive top end) and doesn’t delay controls toooo long.

For me, it seems to cap out after 2 seconds or so.

On SqueezeLite end points, there are buffer parameters on both input to the SL process and output to the ALSA driver. The former (when set to a large value) basically causes the entire current and next track to stream over ethernet very quickly (1-2 seconds), which means no ethernet traffic while the music is playing out of memory.

I believe this value is related to the ALSA output buffer (the buffer between the sound driver and the USB driver). Any SQ impact with larger buffer sizes may be limited by how Roon Core is talking to Roon Bridge

For instance, I hear no difference and see no controls delays differences between 4 and 40 seconds on this buffer. I do hear a significant SQ difference (and more controls lag) going from 0.5 to 4. 1.5-2.0 may be the sweet spot

I believe your theory regarding the experiments others have done with SqueezeLite and ALSA apply here too.

I’m not using RoonBridge, rather my Core is directly connected to my DAC via I2S.

With a buffer of 1.5 seconds I experience music playing on for an additional 1.5 seconds after I hit Skip or Stop…

Interesting…I think that pretty much confirms that it is the ALSA output buffer we’re tweaking (whether Roon Core or Roon Bridge is talking to the ALSA driver, behavior seems the same)

Also interesting that the effect can be heard on I2S. I’ve heard it on toslink and USB, but adding I2S to the party is another clue to what may be going on (although I still have no idea why it makes a difference)

If I may ask, are you going through a DDC to get from USB/toslink to i2S for your DAC, or direct I2S from your server?

Direct I2S. I have a PCIe card from Pink Faun. I’ve tried USB direct and USB into the Matrix and prefer direct I2S. It’s not night and day though, I think the ALSA buffer tweak is every ‘bit’ an audible improvement to my ears

I suppose it could be the input buffer just as easily unless I missed something that causes you to believe or know its the output. The bits are FIFO regardless so the effect could/should be effectively identical

It sounds great to me and the price is right, eh?

1 Like

I have noticed that by increasing the ALSA buffer, the interrupts of my I2S card and the CPU attention that is requires is dramatically decreased. I was used to seeing it pop up in Top with some regularity, every 10 seconds or so, now I don’t see if but once every few minutes if I happen to catch it. I have it’s IRQ prioritized over my NIC and the NIC above everything else.

Less attention needed is a good thing. I run Roon and OS completely from ram using ramroot. While this also improves the liquid-sound I think the ALSA buffer change is on par with it.

It’s hard to quantify these tweaks but they all do seem to add up to something quite special in those ‘priceless’ last few percentage points.

When I was playing with SqueezeLite large buffers, it was surprising how big the impact of output buffers were (input buffers to SL end point as well, but that is specific to the Slim protocol, not ALSA…setting those to large values basically minimized ethernet interrupts during music playback)

I’m currently jumping back and forth between Audio Linux (ram root) + Roon Bridge with this larger buffer and Euphony (ram root) with the StylusEP. Both with a separate NUC running Roon Core. Both sound lovely.

The best is still Euphony Stylus on the NUC (single box), but I can’t give up Roon client and experience. All these buffer and system tweaks are to try to get Roon to sound as good as Euphony sounds (getting closer, but still a gap)