W3C home > Mailing lists > Public > www-tag@w3.org > September 2014

Re: AudioContext suspend/resume/release

From: Chris Wilson <cwilso@google.com>
Date: Mon, 29 Sep 2014 08:54:17 -0700
Message-ID: <CAJK2wqXzv9P_3mWHS7K7+wW-F5N9ADzgLUCKUWB1Cf0U7CDaEg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>, Raymond Toy <rtoy@google.com>
Cc: W3C TAG <www-tag@w3.org>
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.

> 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?

/ 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
> >
>
Received on Monday, 29 September 2014 15:54:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:05 UTC