Update SpeechRecognitionResult with audio timing attributes#192
Open
alan33d wants to merge 1 commit into
Open
Conversation
Added audioStartTime and audioEndTime attributes to SpeechRecognitionResult interface with explanations as proposed in WebAudio#191
alan33d
marked this pull request as ready for review
July 14, 2026 04:14
alan33d
marked this pull request as draft
July 14, 2026 04:15
alan33d
marked this pull request as ready for review
July 14, 2026 04:15
alan33d
marked this pull request as draft
July 14, 2026 05:28
alan33d
marked this pull request as ready for review
July 14, 2026 05:32
hoch
reviewed
Jul 14, 2026
|
|
||
| <dl> | ||
| <dt><dfn attribute for=SpeechRecognitionResult>audioStartTime</dfn> attribute</dt> | ||
| <dd>A nullable {{DOMHighResTimeStamp}} representing the start of the audio segment corresponding to this recognition result, in milliseconds relative to the time origin. Returns null if the underlying recognition engine does not support audio segment start timestamps.</dd> |
Member
There was a problem hiding this comment.
IIRC SpeechSynthesisEvent uses elapsedTime, which is float.
Is there a specific design reason for using DOMHighResTimeStamp here?
Collaborator
Author
There was a problem hiding this comment.
No specific reason, I started with double? but it was suggested by @evanbliu to use DOMHighResTimeStamp? to mirror event.timeStamp property. I don't have a strong preference on this.
Collaborator
There was a problem hiding this comment.
IIUC, DOMHighResTimeStamp is just a typedef for a double but it makes it clear that the units are in milliseconds.
I assume SpeechSynthesisEvent uses float because DOMHighResTimeStamp didn't exist (or at least wasn't widely adopted) back in 2012.
PaulKinlan
added a commit
to PaulKinlan/chrome-platform-showcase
that referenced
this pull request
Jul 25, 2026
…+ missing root suite Source-review against the explainer (readonly attribute DOMHighResTimeStamp? audioStartTime/audioEndTime on SpeechRecognitionResult — milliseconds relative to time origin, nullable when the backend supplies no segment timing, ~2ms fuzzing to mirror HTMLMediaElement.currentTime; latency = event.timeStamp - result.audioEndTime), PR WebAudio/web-speech-api#192 (OPEN/unmerged as of 2026-07-24, updated 2026-07-15), Chromium main's speech_recognition_result.idl ([LegacyNoInterfaceObject]; currently only length/item/isFinal — the timestamp attributes are NOT in trunk and no dedicated runtime feature exists yet, so even the experimental-features catch-all may expose nothing), the direct chromestatus detail (updated 2026-07-16: v153 listing dev trial desktop_first 153; detail desktop None, 'Proposed'; ff/safari=5 no-signal), MDN (SpeechRecognitionResult 200, no timestamp coverage yet), and WPT (27 speech-api files, no timestamp test as of 2026-07-25). The family was already structurally honest: the LegacyNoInterfaceObject detection recipe (no constructor to probe — inspect a live result instance), absent-property vs present-but-null distinction (unsupported vs no-value), SAMPLE-tagged walkthroughs that never pose as live results, headless/no-mic errors reported as availability problems, and per-result values only ever read from real result objects. Hardened: - Index lede 'Chrome 153 adds' replaced by labelled-proposal framing; 'why it shipped' renamed 'why timestamps matter'; an explicit availability paragraph states the in-flux implementation state (dev trial at 153 per listing; detail 'Proposed'; PR unmerged; not in trunk IDL as of 2026-07-24; no dedicated flag yet). - All three concepts' enablement notes now carry the same in-flux precision instead of promising the catch-all flag works. - pagehide recognition.stop() cleanup added to latency-monitor and caption-timeline (capability-probe already stops on end/stop). Conformance: NEW immutable root suite (8 assertions = 8 rendered rows = 8 reported): the recognition constructor host, the LegacyNoInterfaceObject no-global trap, the explicit start instance-vs-static pair, the interim/continuous configuration members, the no-synthetic-result-construction contract (per-result values must come from a live object — never fabricated or inferred from event cadence), and the two clock contracts (Event.prototype.timeStamp as the latency subtraction operand; performance.timeOrigin as the shared origin the audio times are relative to). No microphone is requested anywhere; the timestamp ATTRIBUTES themselves are structurally untestable without a live recognition on an implementing engine, recorded honestly in the suite descriptions. Executes live, recounted from rendered rows: 8 total = 8 pass / 0 fail / 0 blocked on Chrome 150. Missing feature-level suites 3->2 (795/798 -> 796/798). Lifecycle: feature critique with guidanceConsulted (accessibility, privacy); responsive-support ok/ok (harness); check-routes PASS (798/798, touched=1); fmt/audit/check exit 0. MCP on HeadlessChrome/150 (no blind mic grants): surface probe (SpeechRecognition + webkit present, SpeechRecognitionResult global ABSENT as LegacyNoInterfaceObject requires), live inspect reports 'Recognition error: not-allowed' as an availability problem with the probe unaffected and duplicate suppression restoring the button, latency sample walkthrough (SAMPLE-tagged segments, verdict tracks threshold changes, gauge fill/marker live), caption timeline sample with 'SAMPLE — not a live recognition result' banner and positioned segments, zero console errors, zero failed requests. Two mobile defects found post-interaction and fixed in place: probe results table 543px -> 306px (overflow-wrap + fixed layout), and the index's unbreakable 23-char title word spilling text-level past its 342px box -> h1{overflow-wrap:anywhere} (433px -> 390px). All four pages re-verified contained at 390px. Co-Authored-By: Kimi K3 <noreply@moonshot.ai>
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
3 participants
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.
Added audioStartTime and audioEndTime attributes to SpeechRecognitionResult interface with explanations as proposed in #191.
Fixes: #191
Preview | Diff