You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect this is subtly wrong. With this code outputReady only gets reset if it happened to get set after we started waiting for the condition. If outputReady was already true before we entered this block, then it will stay true forever. That doesn't seem right. The reset should happen unconditionally.
The consequence of outputReady being stuck at true is that ASIO output buffers will be transferred to PortAudio before the ASIO host application is done writing them, leading to corrupted audio output.
One reason why this went unnoticed until now is probably because this only has consequences in ASIO Host Applications that support OutputReady and return from bufferSwitch before they call it. I suspect such applications are rare.
The text was updated successfully, but these errors were encountered:
In retrospect, given the investigation in #235, it turns out this bug was worse than I originally thought: indeed the initial value of outputReady is true, which means we would never wait for outputReady, period. The wait code was basically dead until the fix. Thankfully, it looks most ASIO applications call outputReady before returning before bufferSwitch anyway, which means this bug would have no consequences for them.
dechamps
changed the title
FlexASIO skips waiting for ASIOOutputReady() if it is called early
FlexASIO never waits for ASIOOutputReady()
May 31, 2024
While reviewing some FlexASIO code I stumbled upon this:
FlexASIO/src/flexasio/FlexASIO/flexasio.cpp
Lines 998 to 1003 in 57e14e8
I suspect this is subtly wrong. With this code
outputReady
only gets reset if it happened to get set after we started waiting for the condition. IfoutputReady
was already true before we entered this block, then it will stay true forever. That doesn't seem right. The reset should happen unconditionally.The consequence of
outputReady
being stuck attrue
is that ASIO output buffers will be transferred to PortAudio before the ASIO host application is done writing them, leading to corrupted audio output.One reason why this went unnoticed until now is probably because this only has consequences in ASIO Host Applications that support OutputReady and return from
bufferSwitch
before they call it. I suspect such applications are rare.The text was updated successfully, but these errors were encountered: