Repository navigation
Conversation
WPT non-regression comparisonERROR — the run produced no report. Workflow run · this comment is updated on every push. |
mdydek
added this pull request to stack #1361
October 22, 2026 16:07
mdydek
force-pushed
the
feat/get-output-timestamp
branch
from
October 23, 2026 08:38
f515df0 to
9b0f86a
Compare
This branch has not been deployed
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
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.
Closes #
Introduced changes
getOutputTimeStampfunction of the audio context implementationThe platform asks for a buffer of N frames, and we render it as ceil(N / 128) quanta back to back, as fast as the code runs. The buffer is played later, when the device gets to it.
currentTime advances by the whole buffer during that short render burst and then stays frozen until the next callback. A caller polling it can't tell where in that period they are.
currentTime also marks what was rendered, not what is heard. The device plays it about one output latency later (10–40 ms on the speaker, 150–250 ms on Bluetooth).
Scheduling at currentTime + x is therefore late by the output latency. Subtracting outputLatency fixes the average, but the click still lands 0 to N frames late, depending on when currentTime was read. With large buffers that's tens of ms.
getOutputTimestamp() returns contextTime, the frame leaving the speaker, together with the performance.now() moment it does so (of course is OS estimation, but its the best we can get). Because performance.now() advances continuously, you can extrapolate from that pair to any moment without the buffer-sized error. Our implementation already extrapolates to the moment of the call, so contextTime is the audible position now.
The pair connects the context's clock to the performance.now() clock, which everything else uses: animations, gestures, video, network messages, other devices.
To convert in either direction: contextTime + (perfMs − performanceTime) / 1000 and performanceTime + (ctxS − contextTime) × 1000. That lets visuals follow the audible position, sounds land on a visual event, taps be judged against what the user heard, or several devices sound in sync.
Checklist