Specify OfflineAudioContext suspend and resume better

[padenot]

It's pretty light at the moment, and I'd like this clear before doing progressive rendering, that is imminent because we've made progress on it.

[karlt]

The bits that I saw were yet to be done from #302 are

1. specification of suspend() Promise resolution,
2. specification of statechange to suspended,
3. 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.

[karlt]

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():

await suspend(suspendTime);
await 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]

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]

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".