-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FlexASIO timing information appears to be broken #9
Comments
After reviewing the code and going over the ASIO SDK docs again, I believe I have found the bug, and it's a big one indeed. ASIO uses a very surprising encoding convention for timestamps (32-bit halves of the 64-bit integer are swapped on little endian architectures such as x86), and my code didn't take that into account. As a result, the timestamps that FlexASIO reports to the host application are utterly corrupted and completely unusable. This completely explains the phenomenon shown in the screencast, because one would expect the timestamp to overflow all over the place and behave very erratically. I am fixing that right now. Expect a release with the fix shortly. |
In particular the log will now include timing information. See #9.
The ASIO SDK documentation explicitly states that ASIOTime::reserved and AsioTimeInfo::reserved must be set to zero. Therefore FlexASIO should not leave these fields uninitialized. See #9.
The example provided in the ASIO SDK docs doesn't set them, and doesn't set the kSpeedValid flag. This shouldn't really matter, but let's follow the official example out of an abundance of caution. See #9.
@josephernest: I believe the bug you reported is fixed in FlexASIO 0.3. The timing information might not be optimally accurate yet, but it should at least be reasonable now. If you are still seeing the issue, please gather logs (see README) and post them here - the new version logs timestamp related information in more detail. |
In #3 (comment), @josephernest posted a Source Forge screencast where the cursor position behaves erratically when playing through FlexASIO. One likely explanation is that FlexASIO is reporting timing information in an incorrect way, leaving host applications confused.
In #3 it was also speculated that this might have something to do with MIDI being broken in some host applications while using FlexASIO, as MIDI might be relying on the same timing information.
The text was updated successfully, but these errors were encountered: