Intent to Implement and Ship: WebAudio: Allow user to close an AudioContext explicitly

[Raymond Toy]

Primary eng/PM emails rt...@chromium.org,hong...@chromium.org Spec http://webaudio.github.io/web-audio-api/ Summary An AudioContext can be explicitly closed, thereby releasing any hardware resources associated with the AudioContext. A new method, close(), is added to allow users to close the context. Motivation Currently, users have no way of shutting down an AudioContext except by destroying the graph and waiting for GC to collect the AudioContext. This means that the audio hardware is still consuming power and CPU for no reason, which is important for battery life on mobile devices. By adding a new close() method, users can now explicitly destroy the context, saving CPU and power. Compatibility Risk This has been a common request from developers who want to save power and cpu, or intend to create and destroy many audio contexts as part of their application. (WebAudio has a hard-limit of a few active AudioContexts.) Users do not have to use this, and contexts will get collected (or not) as before. Ongoing technical constraints None Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes OWP launch tracking bug http://crbug.com/439241 Entry in Chromium Dashboard https://www.chromestatus.com/features/5411681005993984 Requesting approval to ship? Yes

[Chris Harrelson]

Hi,

Seems reasonable. Is there evidence of support for this change from other browser vendors?

On Fri Jan 30 2015 at 12:39:26 PM 'Raymond Toy' via blink-dev <blin...@chromium.org> wrote:

Primary eng/PM emails rt...@chromium.org,hong...@chromium.org Spec http://webaudio.github.io/web-audio-api/ Summary An AudioContext can be explicitly closed, thereby releasing any hardware resources associated with the AudioContext. A new method, close(), is added to allow users to close the context. Motivation Currently, users have no way of shutting down an AudioContext except by destroying the graph and waiting for GC to collect the AudioContext. This means that the audio hardware is still consuming power and CPU for no reason, which is important for battery life on mobile devices. By adding a new close() method, users can now explicitly destroy the context, saving CPU and power. Compatibility Risk This has been a common request from developers who want to save power and cpu, or intend to create and destroy many audio contexts as part of their application. (WebAudio has a hard-limit of a few active AudioContexts.) Users do not have to use this, and contexts will get collected (or not) as before. Ongoing technical constraints None Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes OWP launch tracking bug http://crbug.com/439241 Entry in Chromium Dashboard https://www.chromestatus.com/features/5411681005993984 Requesting approval to ship? Yes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Rogers]

This seems reasonable to me too. LGTM

[PhistucK]

Looks like you are using an outdated template that does not mention Android WebView as a sixth platform. Where did you get the template from (so it could be updated)?

Just so you know, this intent was a bit confusing, you sometimes write "users" and you sometimes write "developers". At first, I thought you meant that users (that installed the browser) will be able to shut down the AudioContext (without closing a tab) in order to decrease the battery usage.

But you meant users (that use the API), so, developers only.

Anyway, this addition makes sense.

☆PhistucK

On Fri, Jan 30, 2015 at 10:39 PM, 'Raymond Toy' via blink-dev <blin...@chromium.org> wrote:

Primary eng/PM emails rt...@chromium.org,hong...@chromium.org Spec http://webaudio.github.io/web-audio-api/ Summary An AudioContext can be explicitly closed, thereby releasing any hardware resources associated with the AudioContext. A new method, close(), is added to allow users to close the context. Motivation Currently, users have no way of shutting down an AudioContext except by destroying the graph and waiting for GC to collect the AudioContext. This means that the audio hardware is still consuming power and CPU for no reason, which is important for battery life on mobile devices. By adding a new close() method, users can now explicitly destroy the context, saving CPU and power. Compatibility Risk This has been a common request from developers who want to save power and cpu, or intend to create and destroy many audio contexts as part of their application. (WebAudio has a hard-limit of a few active AudioContexts.) Users do not have to use this, and contexts will get collected (or not) as before. Ongoing technical constraints None Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? Yes OWP launch tracking bug http://crbug.com/439241 Entry in Chromium Dashboard https://www.chromestatus.com/features/5411681005993984 Requesting approval to ship? Yes

[Chris Harrelson]

@PhistucK: I figured out the stale template issue. Eric (cc'd is going to fix the code here: 

ttps://github.com/GoogleChrome/chromium-dashboard/blob/master/templates/blink/intent_to_implement.html

for it.

[PhistucK]

Thank you for the link, I submitted a pull request.

☆PhistucK

[Eric Bidelman]

Yep, we're going to update the Intent email template on chromestatus.com:

https://github.com/GoogleChrome/chromium-dashboard/issues/184

[PhistucK]

Well, at least accept my pull request until this happens, because a few intents have already been posted since three days ago and probably a few more will until this is fixed...

☆PhistucK

[François Beaufort]

Sorry for the late response!
Glad the earlier PR went through.

Here's another PR that updates completely the Intent-To-Ship blink template: https://github.com/GoogleChrome/chromium-dashboard/pull/189

[Alex Russell]

This seems reasonable (+1 to explicit control), but I have a question about the design:

   http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise

Suggests that an exception will be thrown if this method is called on an OfflineAudioContext; why is the Error not sent to the reject handler instead?

[Anne van Kesteren]

On Mon, Feb 2, 2015 at 11:48 AM, 'Alex Russell' via blink-dev
<blin...@chromium.org> wrote:
> This seems reasonable (+1 to explicit control), but I have a question about
> the design:
>
> http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise
>
> Suggests that an exception will be thrown if this method is called on an
> OfflineAudioContext; why is the Error not sent to the reject handler
> instead?

Note that due to the way IDL works throwing an error from an API
algorithm will result in a rejected promise in JavaScript land.


--
https://annevankesteren.nl/

[Raymond Toy]

On Fri, Jan 30, 2015 at 12:46 PM, Chris Harrelson <chri...@chromium.org> wrote:

Hi,

Seems reasonable. Is there evidence of support for this change from other browser vendors?

I have not heard of any direct support from browser vendors, but there were no objections when this was added to the spec. The discussion occurred here:  https://github.com/WebAudio/web-audio-api/issues/317

[Raymond Toy]

Yeah, as mentioned, I got it from the dashboard this time. Previously, I used the link from the chromium developers page.

[Raymond Toy]

On Mon, Feb 2, 2015 at 2:48 AM, Alex Russell <sligh...@google.com> wrote:

This seems reasonable (+1 to explicit control), but I have a question about the design:

   http://webaudio.github.io/web-audio-api/#widl-AudioContext-close-Promise

Suggests that an exception will be thrown if this method is called on an OfflineAudioContext; why is the Error not sent to the reject handler instead?

See https://github.com/WebAudio/web-audio-api/issues/441. 

[Chris Harrelson]

LGTM

[Philip Jägenstedt]

LGTM3, this sounds simple to implement and useful to Web developers.