[Regression/Bug] Windows Audio - WASAPI shared mode: buffer size selection has no effect since 83e3cd8be9

[Rasmuskurstein]

Hi:)

Since commit 83e3cd8be9, changing the buffer size in WASAPI shared mode has no effect. Even though a range of buffer sizes is presented as available through getAvailableBufferSizes(), currentBufferSizeSamples is always set to defaultBufferSize regardless of what is selected.

The reasoning makes sense. However, prior to this change, setting a larger buffer size did have a functional effect: The audio thread would accumulate more samples before calling the callback, allowing to trade latency for lower CPU usage.

As I see it, there are two options:

1. As previously, allow currentBufferSizeSamples to differ from the hardware period, since the accumulation logic supports it. Then getAvailableBufferSizes() could return only sizes larger than or equal to defaultBufferSize.
2. Keep the current behavior, but have getAvailableBufferSizes() return only the default size in shared mode, so the UI doesn’t present non-functional options.

cc @reuk

[anthony-nicholls]

Thanks for reporting, this is now fixed on the develop branch.

WASAPI: Only return the default buffer size

Note, we went with only reporting the default buffer size as it’s misleading and confusing to end users to report a different size than is used internally (even if this might happen in some other situations).

[Rasmuskurstein]

Great, thank you!