Conflict on resuming context

[hoch]

Here is the behavior on resuming a realtime context.

The promise is rejected if the context has been closed. If the context is not currently suspended, the promise will resolve.

For offline context, we have

If the context is not currently suspended or the rendering has not started, the promise is rejected with InvalidStateError.

Which one is more reasonable?

[padenot]

The first behaviour has been shipping for some time, I'd say we can't really change it now.

[hoch]

I agree. @rtoy WDYT?

[rtoy]

Yeah, I wouldn't want to change the existing online context behavior of resume.

I don't have any objections if resume on offline contexts behaves differently. The use cases are different and suspend is already different (time arg required).

[hoch]

Honestly, resuming a running context is not that really meaningful. Especially In OfflineAudioContext, changing audio graph or scheduling things will be done much faster than realtime, so doing something after the resuming is not the recommended usage.

[joeberkovitz]

TPAC 2015: Change the behavior of OfflineAudioContext to match the online one, i.e. resolve the promise if the context is in a running state and reject only if it is closed.

Since both AudioContexts will now inherit from a single interface it would be strange to vary this behavior even though the use cases are somewhat different.

[hoch]

I forgot to bring up another question: what should we do about resuming a context that has not been started?

I think we should reject the promise.

[padenot]

Yes, for the Offline case. For the online case, this would behave normally, but is kind of useless.

[hoch]

For this issue, PR #656 is on the review.

[hoch]

The spec has changed and the PR #656 is not applicable any more. I am removing In the PR Review label.

[hoch]

Oh, I forgot to close this: #1096.