mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-03 12:54:29 +00:00
Vance Ingalls
c28300f0cb
`onSetVolume` assigned `clipVolume * volume` straight to
`HTMLMediaElement.volume`. `data-volume` is an authoring GAIN up to
MAX_AUDIO_GAIN (12 dB, ~3.98) — the native property accepts only 0..1 — so a
clip authored above unity threw
IndexSizeError: Failed to set the 'volume' property on 'HTMLMediaElement':
The volume provided (2.42103) is outside the range [0, 1].
2.42103 is the +7.68 dB fader stop, serialized by `formatAudioGain`. The bridge
clamps its OWN argument to [0,1] (bridge.ts) but nothing clamped the product,
and because the throw escaped mid-loop it abandoned the rest of the sweep:
every media element after the loud one kept its previous volume.
`clampNativeMediaVolume` already existed in audioGain.ts for exactly this — used
by `withUnclampedVolume`, never here. The gain is not lost by clamping: the Web
Audio transport owns it (`webAudio.setVolume` on the line above), and this
native assignment is only the fallback for elements the transport does not route.
Pre-existing, not from this branch: the line dates to a7a664885 (2026-05-07,
"feat(player): add volume/mute controls"), written before over-unity authoring
gain existed. This branch's faders are what make an over-unity `data-volume`
routine, so it surfaces here.
Regression test in init.test.ts drives a real `set-volume` control message at a
2.42103 clip and asserts no error reaches the window; verified it fails on a
revert of the clamp. Note for whoever edits it: the bridge only accepts
`source: "hf-parent"` — a message with any other source is silently ignored, so
a test that gets that wrong passes while proving nothing.
core: 122 files, 2480 tests pass.