Skip to content

Update audioStartTime and audioEndTime to be relative to start of aud… - #203

Open
alan33d wants to merge 4 commits into
mainfrom
alan33d-patch-1
Open

Update audioStartTime and audioEndTime to be relative to start of aud…#203
alan33d wants to merge 4 commits into
mainfrom
alan33d-patch-1

Conversation

@alan33d

@alan33d alan33d commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

We want to switch to stream-Relative (0-based) impl. since:

  • In Web Audio and Media APIs (HTMLMediaElement.currentTime, AudioContext.currentTime, WebCodecs VideoFrame.timestamp), media timelines are always 0-based offsets relative to stream start, not the time origin.
  • Immune to inter-process jitter since SODA and audio capture run in a separate utility/browser process. Translating stream offsets to the renderer's timeOrigin relies on estimating when IPC AudioStarted() arrived, which introduces IPC latency jitter. Stream-relative offsets are not prune to this and aligns with the raw audio frames.
  • If SpeechRecognition is used with a pre-recorded MediaStreamTrack, a 0-based stream offset reflects the actual position in the audio track regardless of when the webpage was loaded.
  • Being relative to performance.timeOrigin doesn't make sense in general for the Web Speech API because it assumes that the audio source is live. Since a SpeechRecognizer can also be created for a prerecorded media stream I think the timestamps on the speech recognition events should be relative to the position in that media stream.

See https://crbug.com/542330168 for more details.

…io stream

We want to switch to  stream-Relative (0-based) impl. since:
- In Web Audio and Media APIs (HTMLMediaElement.currentTime, AudioContext.currentTime, WebCodecs VideoFrame.timestamp), media timelines are always 0-based offsets relative to stream start, not the time origin.
- Immune to inter-process jitter since SODA and audio capture run in a separate utility/browser process. Translating stream offsets to the renderer's timeOrigin relies on estimating when IPC AudioStarted() arrived, which introduces IPC latency jitter. Stream-relative offsets are not prune to this and aligns with the raw audio frames.
- If SpeechRecognition is used with a pre-recorded MediaStreamTrack, a 0-based stream offset reflects the actual position in the audio track regardless of when the webpage was loaded.
- Being relative to performance.timeOrigin doesn't make sense in general for the Web Speech API because it assumes that the audio source is live. Since a SpeechRecognizer can also be created for a prerecorded media stream I think the timestamps on the speech recognition events should be relative to the position in that media stream.

See https://crbug.com/542330168 for more details.
@alan33d
alan33d requested review from evanbliu and reillyeon August 12, 2026 19:58
Added a section on converting stream timestamps to document time origin and provided a live translation latency example with code.
Added separator before security section and closed example section for live transcription measurements.
@alan33d alan33d self-assigned this Aug 12, 2026

@michaelwasserman michaelwasserman left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drive by review: lgtm with a nit, fwiw. I implemented the suggested timestamp offsetting in my demo, and it seems to work well. https://michaelwasserman.github.io/web-speech-demos/speech_latency.html

Comment thread explainers/speech-recognition-result-timestamps.md Outdated
@alan33d
alan33d marked this pull request as ready for review August 13, 2026 00:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants