Windows ASIO output and frameSize conflicts

[marcelblum]

ASIO is a strange bird and I've been running into an issue where many devices have control panels in which the user can specify buffer size settings. These settings seem to override any attempt to specify frameSize in RtAudio's openStream(). The problem is if a frameSize is specified in openStream() that is not exactly equal to whatever the user selected in their control panel, then calls to write() fail silently. The frameOutputCallback is never called following the write(), no error is fired, and isStreamOpen and isStreamRunning both return true. So the RtAudio instance is in this weird state where buffers keep piling up in the queue with every call to write() but are never played. There's no way that I can see to detect the user-set buffer size and pick the right magic number for frameSize when instantiating an RtAudio stream. Is there a way to have getDevices() return the device's current preset buffer size? Or perhaps some flag that forces overriding the control panel setting?

Here are 2 examples of the sort of ASIO device control panels I'm referring to:

You can see that in the MOTU device panel both sample rate and buffer size are configurable, but interestingly the sampleRate specified in openStream() does override the panel setting (I can see the change reflected in the panel as soon as I open the RtAudio stream).

I guess an ugly workaround would be to brute force it by continuously opening streams and checking if the frameOutputCallback was called, and if not, open a new stream and try again with a different power of 2 value until arriving at the magic number that works, but it would be nice to have a more elegant solution.

[marcelblum]

Looking at the source RtAudio docs for openStream I see that it allows passing a value of 0 for bufferFrames:

A value of zero can be specified, in which case the lowest allowable value is determined. The actual value used by the device is returned via the same pointer.

I wonder if for ASIO this gets interpreted as the control panel forced value. I tried passing 0 for frameSize with audify's RtAudio but it does not work as expected and seems to actually open an unusable stream with a 0 buffer size.

[marcelblum]

I think the problem starts here, the frameSize value passed to openStream() is used in all subsequent calculations and checks, which if 0 always leads to failed checks/errors thrown by Audify (not by RtAudio!), even though the stream actually does get created successfully with an unknown frameSize:

audify/src/rt_audio.cpp

Line 230 in 856fdba

_frameSize = frameSize;

So there needs to be a way to poll the stream instance for "The actual value used by the device".

[almoghamdani]

Fixed in v1.7.1.
Thanks to @marcelblum for the fix.

Please re-open if you're still encountering issues.