Repository navigation
webmidi: report input timestamps on the monotonic clock's scale - #260
Merged
Merged
Conversation
MIDIMessageEvent.timeStamp counts milliseconds from the page's time origin, while absolute_timestamp() answers with the monotonic clock, which emscripten reports as timeOrigin + performance.now(). A consumer subtracting the two — placing an incoming message inside the current audio buffer, say — was therefore off by the time origin, some 1.8e12 milliseconds, and every message landed at the start of the buffer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SCvayD61okH7PATstw4whi
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MIDIMessageEvent.timeStampcounts milliseconds from the page's time origin,while
absolute_timestamp()answers with the monotonic clock, which emscriptenreports as
timeOrigin + performance.now().A consumer subtracting the two — placing an incoming message inside the current
audio buffer, say — was therefore off by the time origin, some 1.8e12 ms. In
libossia's
execution_statethe subtraction hit the< 0clamp, so everymessage landed on frame 0 of the buffer: no crash, no error, just no
sample-accuracy on the web.
Found while tracking down an unrelated abort in the same path. Reasoned from the
generated JS and emscripten's clock implementation; I have not measured a message
landing on a non-zero frame, so this side of it is unverified.
🤖 Generated with Claude Code
https://claude.ai/code/session_01SCvayD61okH7PATstw4whi