Re: AudioContext suspend/resume/release

On Mon, Sep 29, 2014 at 8:54 AM, Chris Wilson <cwilso@google.com> wrote:

> On Sat, Sep 27, 2014 at 1:43 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> > We're discussing an issue in the Web Audio API (
>> https://github.com/WebAudio/web-audio-api/issues/317) of the need for
>> suspending and resuming AudioContexts for power consumption reasons.
>> Alongside this, we've found the need to be able to release AudioContexts
>> completely - in short, AudioContexts may be consuming system resources, and
>> we need a way for developers to definitively state "I'm done with this
>> now", aside from just releasing references and hoping the GC takes care of
>> it.
>> >
>> > The current proposal is to add a method to the AudioContext interface:
>> >
>> > Promise release ();
>>
>> This is a general pattern that we have seen in many APIs. Canvas is
>> another such example. Blobs and WebSockets are other.
>>
>> I believe there is a bit of prior art in calling the function .close().
>> This is what Blob and WebSocket calls it (though WebSocket's close() does
>> other things too).
>>
> I'm certainly not opposed to renaming to close() if there's precedent.
>

 Either name works for me. Or dispose (used in C#?), or anything else.

> What is the purpose of returning a Promise? I don't particularly mind, but
>> given that this is a function to save resources, why incur the cost of an
>> extra object creation?
>>
> Hmm.  I believe I did this because it will sometimes be desirable to know
> when the audio device has been actually released - i.e. one can create
> another audio context.  Raymond?
>

I'm not 100% sure, but I think there is potentially some (small) delay
between when I ask to stop the audio hardware and when the resources are
actually released.  I'm not sure either if we have the infrastructure in
place if we can even be told this.

And it's really about the HW resources associated with the context, not the
extra objects that might be created in JS.


>
> / Jonas
>>
>> >
>> > Releases the audio context, including any system resources used by it.
>> This will not automatically release all AudioContext-created objects,
>> unless other references have been released as well; however, it will
>> forcibly release any system resources that might prevent additional
>> AudioContexts from being created and used. The promise resolves when any
>> AudioContext-creation-blocking resources have been released.
>> >
>> > Do you have any concerns over this pattern?
>> >
>> > Thanks,
>> > -Chris
>> >
>>
>
>