API reference

Every public class, method, and event in @codexo/exojs. Generated from source.

C

classAudioOutputClock

@codexo/exojs / audio / stable

Converts between audio-context time and the `performance.now()` timeline, so that audio scheduled in one can be lined up with rendering, input or animation measured in the other. ```ts const clock = new AudioOutputClock(); const beatAt = clock.contextToPerformanceTime(nextBeatContextTime); ``` Where the environment offers `AudioContext.getOutputTimestamp()`, the correlation names the sample the output device is playing right now, so a context time converted through this class already accounts for the output path: a beat scheduled for `contextTime` maps to the `performance.now()` instant a listener hears it, with no latency arithmetic of your own. AudioOutputClockSnapshot.baseLatency and `outputLatency` are telemetry, not a correction to apply on top. Nothing here knows about display latency. Aligning a beat with the frame that shows it is the caller's decision, because only the caller knows how far ahead of the photons its render loop runs. Every reading is taken fresh, so long-lived instances track drift between the two clocks rather than accumulating it. Two conversions therefore need not use the identical correlation; where exactness matters more than currency, take one snapshot and do the arithmetic against it. The wall clock is never consulted - a user changing the system time cannot move an ExoJS audio correlation.

1
props
3
methods
0
events
Import
import { AudioOutputClock } from '@codexo/exojs'

Converts between audio-context time and the `performance.now()` timeline, so that audio scheduled in one can be lined up with rendering, input or animation measured in the other.

```ts const clock = new AudioOutputClock(); const beatAt = clock.contextToPerformanceTime(nextBeatContextTime); ```

Where the environment offers `AudioContext.getOutputTimestamp()`, the correlation names the sample the output device is playing right now, so a context time converted through this class already accounts for the output path: a beat scheduled for `contextTime` maps to the `performance.now()` instant a listener hears it, with no latency arithmetic of your own. AudioOutputClockSnapshot.baseLatency and `outputLatency` are telemetry, not a correction to apply on top.

Nothing here knows about display latency. Aligning a beat with the frame that shows it is the caller's decision, because only the caller knows how far ahead of the photons its render loop runs.

Every reading is taken fresh, so long-lived instances track drift between the two clocks rather than accumulating it. Two conversions therefore need not use the identical correlation; where exactness matters more than currency, take one snapshot and do the arithmetic against it.

The wall clock is never consulted - a user changing the system time cannot move an ExoJS audio correlation.

Constructors1
new(context?: AudioContext): AudioOutputClock
Methods3
contextToPerformanceTime(contextTime: number): number
The performance.now() instant matching contextTime, in milliseconds.
performanceToContextTime(performanceTime: number): number
The audio-context instant matching performanceTime, in seconds.
snapshot(): AudioOutputClockSnapshotOne correlated reading of the audio clock against the `performance.now()` timeline.
Take a fresh correlated reading.
Properties1
context: AudioContext
The context this clock reads. Resolving the shared context creates it when none exists, the same as any other entry point into ExoJS audio.
Source
src/audio/AudioOutputClock.ts