FramesPerBuffer echoes the requested size, could it report what the driver granted?

[TommiIversen]

Hi again,

A small one: when I request a buffer size, FramesPerBuffer reports the value I asked for, even if the ASIO driver rounded it to something else.
I ended up inferring the real size from the callback drain sizes, which works but is a bit roundabout.

If the granted size is available from the driver at init, exposing it (either in FramesPerBuffer itself or as a separate property) would make mismatches visible to the host. No urgency at all, just something I bumped into while measuring.

Cheers,
Tommi

[ModernMube]

Hi,

This is a bug – I documented IAudioEngine.FramesPerBuffer as
"what the device actually gave us", so the contract promised exactly what
you asked for, while the implementation just echoed the request.

There are two things that prevent me from making FramesPerBuffer itself the specified size:
the cpal treats BufferSize::Fixed as a request and never reports back what
the driver set, and FramesPerBuffer is read synchronously at init (the
engine wrapper and mixer size their buffers from this), so it can't be a value
that only appears after the first callback.

So the callback length – the only default value – is now fixed in both
directions, and appears next to it:

int asked = OwnaudioNet.Engine!.FramesPerBuffer; // the request
int granted = OwnaudioNet.Engine!.OutputCallbackFrames; // 0 until the audio is played
int capture = OwnaudioNet.Engine!.InputCallbackFrames;

Two properties are used because outside of ASIO the render and capture sides
don't have to match. These represent the latest callback, not a fixed
contract - ASIO has a single size, WASAPI is shared, CoreAudio can change the
block. There is no additional overhead on the audio thread; the frame count is already
calculated for the load counters.

Thanks.

[TommiIversen]

Hi ModernMube,

Upgraded to 4.0.6 and wired OutputCallbackFrames/InputCallbackFrames into my diagnostics. On my RME with the panel at 64 frames they report capture 64 / output 64 once audio flows - matching the drain-step sizes I previously had to infer the real block size from. Mismatches are now visible instead of guessed, which is all I was after. The Log.Sink addition in 4.0.6 turned out to be a nice bonus here too: the init line with the granted values now lands in my worker's log instead of on the console.

This can be closed from my side. Thanks!

Cheers,
Tommi