You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Specify OfflineAudioContext suspend and resume better #2662
The bits that I saw were yet to be done from #302 are
specification of suspend() Promise resolution,
specification of statechange to suspended,
add a means to progressively render an arbitrary duration.
#302 for progressive rendering has been replaced by #2445, but proposals there would suspend and resume the offline context, so it perhaps might be better to wait on specifying 1 and 2 until it is clear how these will interact with progressive rendering.
Adding suspend promise resolution and a statechange event is a good time to consider what these provide.
As currently spec'd, the suspend() Promise is never resolved.
There are a few cases where OfflineAudioContext.suspend(suspendTime) is specified to reject.
The Promise needs to be resolved on success because a caller needs to await the Promise to determine whether the suspend() call has successfully inserted the limit on the duration of rendering (unless we change suspend() to be infallible).
i.e. The suspend() Promise needs to be resolved before the caller calls resume():
For #2445, the startRendering() Promise and the OfflineAudioCompletionEvent would not provide an AudioBuffer with all the AudioDestinationNode audio data.
This data is available via other means (AudioWorkletNode, AnalyserNode).
If we want another means of getting the audio data from the AudioDestinationNode, then there are other options to consider:
My first thought was that the resume() Promise might return an AudioBuffer with the audio data from the AudioDestinationNode since the resume() call.
However, resume() is already specified such that it can be called additional times, while the context is already "running", in which case additional overlapping AudioBuffers would seem unnecessary.
Perhaps a new Promise<AudioBuffer> resume(length) method could be added that adds a suspend point at the right place and resolves with an AudioBuffer on the next transition to "suspended". It could throw if the context is already running. It would save having to make two function calls for each rendering step.
I assume there will be a single event named "statechange" for each transition from "running" to "suspended", so this could perhaps carry an AudioBuffer as an alternative way to provide the AudioDestinationNode audio data since the most recent transition to "running".
https://www.w3.org/TR/design-principles/#state-and-subclassing says "Put state on the target and use events to signal updates to that state, rather than having state on Event objects." I guess the audio data is not really "state". New subclasses of Event "can be used to provide information relating to how the state change occurred".
Activity
karlt commentedon Jan 14, 2026
The bits that I saw were yet to be done from #302 are
#302 for progressive rendering has been replaced by #2445, but proposals there would suspend and resume the offline context, so it perhaps might be better to wait on specifying 1 and 2 until it is clear how these will interact with progressive rendering.
Adding suspend promise resolution and a statechange event is a good time to consider what these provide.
karlt commentedon Jan 14, 2026
As currently spec'd, the suspend() Promise is never resolved.
There are a few cases where OfflineAudioContext.suspend(suspendTime) is specified to reject.
The Promise needs to be resolved on success because a caller needs to await the Promise to determine whether the suspend() call has successfully inserted the limit on the duration of rendering (unless we change suspend() to be infallible).
i.e. The suspend() Promise needs to be resolved before the caller calls resume():
(Note that these requirements conflict with a proposal to provide partial rendering buffers on the suspend Promise, but there are other options, which I'll post separately.)
karlt commentedon Jan 14, 2026
The OfflineAudioContext.state attribute changes to "running" after resume(), but there is no corresponding change to "suspend".
There is "For every render quantum, check and suspend rendering if necessary".
An event named "statechange" (and
state == "suspended") would indicate to the client that the chunk of rendering up to the suspend time is done.karlt commentedon Jan 14, 2026
For #2445, the
startRendering()Promise and the OfflineAudioCompletionEvent would not provide an AudioBuffer with all the AudioDestinationNode audio data.This data is available via other means (AudioWorkletNode, AnalyserNode).
If we want another means of getting the audio data from the AudioDestinationNode, then there are other options to consider:
My first thought was that the resume() Promise might return an AudioBuffer with the audio data from the AudioDestinationNode since the resume() call.
However, resume() is already specified such that it can be called additional times, while the context is already "running", in which case additional overlapping AudioBuffers would seem unnecessary.
Perhaps a new
Promise<AudioBuffer> resume(length)method could be added that adds a suspend point at the right place and resolves with an AudioBuffer on the next transition to "suspended". It could throw if the context is already running. It would save having to make two function calls for each rendering step.I assume there will be a single event named "statechange" for each transition from "running" to "suspended", so this could perhaps carry an AudioBuffer as an alternative way to provide the AudioDestinationNode audio data since the most recent transition to "running".
https://www.w3.org/TR/design-principles/#state-and-subclassing says "Put state on the target and use events to signal updates to that state, rather than having state on Event objects." I guess the audio data is not really "state". New subclasses of Event "can be used to provide information relating to how the state change occurred".