Make the output ring size configurable (fixed ~100 ms adds up for monitoring use)

[TommiIversen]

Hi ModernMube,

While measuring my output path (same RME setup as #39), I noticed the render ring gives the output a fairly fixed latency floor: I stopped my producers and audio kept playing for ~104 ms, matching RENDER_RING_SECONDS = 0.1 — and since Send keeps the ring topped up, that delay is always there regardless of the ASIO buffer size.

For playback that's a perfectly reasonable safety margin, so I understand the default.
But for live monitoring it ends up being the biggest part of my total latency.

Would you consider making it configurable — for example a field on the engine config, with 0.1 staying the default so nothing changes for existing users?
I'd be happy to test a smaller ring on my setup and report back with numbers, like last time.

Cheers,
Tommi

[ModernMube]

Hi Tommi,

You are right that the default value is a playback margin, so it remains ~100 ms.
I looked into the options, it is very important that the code remains compatible with older code. That is why this solution was born!

Now it is configurable from endpoint to endpoint:

• AudioConfig.OutputRingMilliseconds, default 100, so nothing changes for existing users.

• At the FFI level it is an additive export
  (ownaudio_v1_open_output_stream_ex with a render_ring_frames argument);

The old entry point delegates with 0 = default value, so the ABI version does not move and people tied to the C header are not affected.

• Requested depths smaller than three device buffers are rolled back — the ring during the callback period expires every time.

AudioEngineWrapper.OutputRingFrames indicates what you actually got after the limit, so you don't have to guess.

For your setup: new AudioConfig { BufferSize = 128, OutputRingMilliseconds = 10 } falls on a 480 frame ring, which is comfortably above the 384 frame lower limit.

Best regards

[TommiIversen]

Hi ModernMube,

4.0.6 is running on my side now, and the ring knob does exactly what I hoped. Same RME setup as before, read off the engine's own counters: with OutputRingMilliseconds = 10 I get a 480-frame ring (and OutputRingFrames reports it faithfully), and the observed ring depth went from 94.7-100 ms on the default to 10.7-16.0 ms at a 256-frame buffer - and 5.3-10.0 ms at 64 frames, with zero native underruns over a 60 s soak. That is roughly 85-90 ms off my monitoring path's latency floor, the biggest single latency win this project has had. The 3-device-buffer clamp behaved exactly as documented.

Thanks for turning this around so quickly - this can be closed from my side!

Cheers,
Tommi