VB-Audio ASIO Bridge streaming fails/hangs with 1.10 (fails to call outputReady)

[Katzenwerfer]

The program doesn't work at all on any of the backends nor devices I've tried.
This only started since the 1.10 update.
Rolling back to 1.9 has no issues as far as I can tell.

[Katzenwerfer]

Here is a log file in case it is useful.

FlexASIO.log

[dechamps]

Mmm, interesting:

2025-02-08T23:50:47.2668540-06:00 17592 14004 --- ENTERING CONTEXT: outputReady() on 007C25C0
2025-02-08T23:50:47.2668683-06:00 17592 14004 Host supports OutputReady
2025-02-08T23:50:47.2668822-06:00 17592 14004 --- EXITING CONTEXT: outputReady() [OK]
…
2025-02-08T23:50:47.3512017-06:00 17592 14004 --- EXITING CONTEXT: start() [OK]
2025-02-08T23:50:47.3512245-06:00 17592 12676 --- ENTERING STREAM CALLBACK
…
2025-02-08T23:50:47.3513107-06:00 17592 12676 Transferring input buffers from PortAudio to ASIO buffer index #0
2025-02-08T23:50:47.3513351-06:00 17592 12676 Firing ASIO bufferSwitchTimeInfo() callback …
2025-02-08T23:50:47.3514471-06:00 17592 12676 bufferSwitchTimeInfo() complete, returned time info: none
2025-02-08T23:50:47.3514683-06:00 17592 12676 Waiting for the ASIO Host Application to signal OutputReady or stop
2025-02-08T23:51:02.3668748-06:00 17592 14004 --- ENTERING CONTEXT: stop() on 007C25C0
2025-02-08T23:51:02.3669544-06:00 17592 14004 Stopping PortAudio stream 007E7638
2025-02-08T23:51:02.3669651-06:00 17592 12676 Transferring output buffers from buffer index #0 to PortAudio
2025-02-08T23:51:02.3670118-06:00 17592 12676 --- EXITING STREAM CALLBACK (0 [paContinue])
2025-02-08T23:51:02.3683758-06:00 17592 14004 Stopping high resolution timer
2025-02-08T23:51:02.3684206-06:00 17592 14004 --- EXITING CONTEXT: stop() [OK]

The host application signaled support for outputReady but didn't call it during the first (actually the second, post priming) buffer switch. This caused FlexASIO to hang, which in my opinion is the correct response to this situation. This suggests a host application bug. After 15 seconds it looks like the host application gave up and stopped the stream.

The reason why FlexASIO 1.9 works is because 1.9 suffers from #180, which was "hiding" the problem. So yes, using 1.9 makes sense as a workaround.

Thanks for reporting this. From what I can tell so far this is likely a bug in ASIO Bridge, not FlexASIO - it's just that FlexASIO 1.10 is less "tolerant" to this kind of misbehavior from the host application. I'll try to reproduce it on my own and report it to VB-Audio after I confirm the issue.