Skip to content
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

Closed
dechamps opened this issue Oct 16, 2018 · 2 comments
Closed

FlexASIO timing information appears to be broken #9

dechamps opened this issue Oct 16, 2018 · 2 comments
Labels

Comments

@dechamps
Copy link
Owner

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.

@dechamps
Copy link
Owner Author

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.

dechamps added a commit that referenced this issue Oct 24, 2018
In particular the log will now include timing information.

See #9.
dechamps added a commit that referenced this issue Oct 24, 2018
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.
dechamps added a commit that referenced this issue Oct 24, 2018
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.
@dechamps
Copy link
Owner Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant