PSA: Intent to Ship: Unprefix WebAudio AudioContext

[Raymond Toy]

Primary eng (and PM) emails

rt...@chromium.org

Spec

http://webaudio.github.io/web-audio-api/

Summary

We've been shipping Web Audio support as a prefixed "webkitAudioContext" API since its introduction in M21 (behind a flag).  We now want to remove this prefix, and ship this support as the standards-compliant "AudioContext".

WebAudio allows web developers to generate audio in the browser without any plugins. Support is included for many different audio effects including reverb, filters, panners, and oscillators.

Motivation

Firefox implemented Web Audio in Firefox 25 as the unprefixed AudioContext object, signaling their belief that the Web Audio spec is nearing completion. Safari is still prefixed, but in a W3C Audio group teleconference, they have agreed to unprefix soon as well. 

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.  For Android, webaudio is enabled by default on ARM and behind a flag on x86.

Compatibility Risk

Moderate. Most Web Audio apps and sites alias the AudioContext if only the prefixed version exists; Firefox has already done a tremendous amount of advocacy to enable unprefixed support, so the vast majority of apps have been fixed already.  Our own Chris Wilson has published a popular "monkeypatch" library that provides compatibility between the prefixed and unprefixed AudioContext (making it easy to fix a legacy prefixed app, simply by including the library).

Also, as part of this unprefixing work, we will remove the legacy methods, types and attributes (e.g. noteOn/noteOff), requiring developers to write standards-compliant code that will work on Firefox and Chrome.  The monkeypatch library also fixes up these problems.

OWP launch tracking bug?

None.

Row on feature dashboard?

Yes

Requesting simultaneous permission to ship?

Yes. We're already shipping the prefixed version.

Ray

[Darin Fisher]

LGTM

[Adam Barth]

LGTM

I know we have use counter data for the APIs that are getting new names.  I didn't see the figures in your message, but I remember them as being quite small.

Adam

[Raymond Toy]

Yeah, I tried looking up the use counter data and they were small, but I got confused on what was actually counted.  The UseCounter.h file says LegacyWebAudio, but the use counter says LegacyWebAudioNoteOn, and I couldn't figure out if they were the same or not or how the name seemed to have changed.

[Eric Seidel]

LGTM.

Latest UseCounter for LegacyWebAudio shows 0.0050% which is well under
the removal threshold.

[Raymond Toy]

On Fri, Feb 14, 2014 at 11:27 AM, Eric Seidel <ese...@chromium.org> wrote:

LGTM.

Latest UseCounter for LegacyWebAudio shows 0.0050% which is well under
the removal threshold.

Thanks for looking that up for me.

And thanks, everyone, for your support!

[Raymond Toy]

An update on this. 

The intent of the original post was also to remove support for the prefixed version, although on re-reading this isn't so clear, but it was kind of hinted at in the Compatibility section.  So, we actually shipped a version that supported both prefixed and unprefixed AudioContext, with support for all of the legacy methods and attributes.

Now we would like to finally drop support for the prefixed version.  Firefox shipped WebAudio support for only the unprefixed AudioContext; a prefixed version was never supported.

We will also remove support (eventually) for all of the legacy methods when the prefixed version is removed.

On Fri, Feb 14, 2014 at 9:39 AM, Raymond Toy <rt...@google.com> wrote:

[Ben Wells]

Adding some developer experience to this, I've been converting a chrome app to use the unprefixed audio context, and realized the unprefixed version isn't available in stable yet. This means I need to use both the prefixed and unprefixed version in my app.

My 2c is we should let the unprefixed version flush through to stable before removing the prefixed version. This will make converting chrome apps, and sites that have advertised as only working on chrome (which from memory included a lot of the early adopters of web audio) a simpler proposition.

I realise I can just use the monkey patch but my OCD tendencies don't like that.

[PhistucK]

I guess the web store developers that use webkitAudioContext without checking for AudioContext should be (or should have been once that change was made into trunk) notified so they can fix their code.

These notifications are not uncommon and are very useful.

☆PhistucK

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

[Chris Wilson]

Phistuck, Ben -

Our goal is to hit up the key web store developers that use webkitAudioContext only prior to the removal making it into Stable.  Most developers have converted already, since Firefox shipped unprefixed AudioContext support last fall; there are a few key apps (e.g. Angry Birds) that have more convoluted multi-browser support.

Note that if you've kept your code relatively up-to-date with the spec, you don't need the full monkeypatch - you can get away with a single line:

window.AudioContext = window.AudioContext || window.webkitAudioContext;

And then your code will work in Firefox too.  :)

[PhistucK]

It depends on the confidence of the change. If we are relatively confident about the change making it to stable, we should let the web store developers know as early as possible (once the change is on trunk, for example) as even though it may look like a small patch to you, it may mean a bigger change to them or may require a lot of testing (and it might coincide with a planned release).

Letting developers know as early as possible is better. Do not assume that any change is a small change.

☆PhistucK

[Ben Wells]

Great to hear you'll be contacting webstore devs.

My main comment is that in general, if we are replacing one thing with another (e.g. prefixed audio context with unprefixed) we should let the new thing get to stable channel before removing the old thing. This make conversion a much simpler process.

[Raymond Toy]

On Sun, Apr 27, 2014 at 6:29 PM, Ben Wells <benw...@chromium.org> wrote:

Great to hear you'll be contacting webstore devs.

My main comment is that in general, if we are replacing one thing with another (e.g. prefixed audio context with unprefixed) we should let the new thing get to stable channel before removing the old thing. This make conversion a much simpler process.

Sorry for this trouble. We've talked this over in the audio group and have agreed that o make the transition easier, we'll update the canary builds to support both prefixed and unprefixed.  This means stable supports only prefixed; all others will support both prefixed and prefixed.

Note that the stable will support all of the legacy methods, but don't expect other versions to support these.  Fortunately, the replacements for the legacy methods will work just fine on the stable version.

I hope this will fix these issues for you.

[PhistucK]

I think you mixed things up a bit, or forgot "un" on some of the "prefixed" mentioning. You better re-post this, because what you just posted is very confusing and sounds pretty irrational. :)

☆PhistucK

[Chris Wilson]

Today:

- stable (m34) supports prefixed, but not unprefixed.

- beta (m35) supports both

- canary (m36) supports only unprefixed

We've decided to re-add prefixed support to canary (m36 - i.e., we are changing that last bullet point to "both"), as this will give an additional milestone for developers to adjust.  In m37, we will remove prefixed support again.

[PhistucK]

That is a lot clearer, thank you!

☆PhistucK

[Ben Wells]

Yes that's awesome, thanks for listening!

setn from phonr

[ph...@audyx.com]

Hello I am reopening this thread of discussion since I realised that m36 did finally removed all prefixed APIS while Chris Wilson post below was clearly mentioning they will be removed only on m37. How can we know about changes in planning ?

Philippe Cohen

☆PhistucK

☆PhistucK

☆PhistucK

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

☆PhistucK

☆PhistucK

☆PhistucK

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

[PhistucK]

What prefixed API are you missing?

webkitAudioContext exists, for example.

☆PhistucK

[Raymond Toy]

On Mon, Jul 21, 2014 at 3:36 AM, <ph...@audyx.com> wrote:

Hello I am reopening this thread of discussion since I realised that m36 did finally removed all prefixed APIS while Chris Wilson post below was clearly mentioning they will be removed only on m37. How can we know about changes in planning ?

Sorry for the confusion.  It was originally planned that m36 would remove support for the prefixed version. This turned out to be more troublesome than expected so m36 supports both unprefixed and prefixed. However, the legacy methods and attributes like createGainNode and createJavaScriptNode have been removed. (Most of these legacy methods were removed from the WebAudio spec a year ago or more.) This makes webkitAudioContext and AudioContext aliases of each other; there is no difference in functionality between the two.

We will eventually remove the support for the prefix completely, probably in 4-6 months.  We'll make an announcement here when the change is imminent.

We are still trying to reach out to authors to fix their WebAudio applications.  As a nice side-effect, their applications will then work with Firefox, which has never supported prefixed WebAudio.

--

Ray

[ph...@audyx.com]

Thanks Ray for the clarification. Indeed part of our application was using legacy methods and therefore we've experimented a severe regression that is now fixed. 

Thanks Phistuck for the input as well.

@Ray is there a group or a forum where we can stay tuned and asked questions that are related to all Web Audio interface and spec? 

Philippe

Philippe Cohen

☆PhistucK

☆PhistucK

☆PhistucK

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

☆PhistucK

☆PhistucK

☆PhistucK

<p dir="ltr" style="font-size:medium;font-family:'Times New Roman';

...

[Chris Wilson]

Phil: Web Audio questions can always be asked in the Web Audio Developers Community Group (http://www.w3.org/community/audio-dev/), discussion list at http://lists.w3.org/Archives/Public/public-audio-dev/.  Or on irc.w3.org#audio-dev, or freenode IRC ##webaudio.

[Raymond Toy]

On Tue, Jul 22, 2014 at 1:37 PM, 'Chris Wilson' via blink-dev <blin...@chromium.org> wrote:

Phil: Web Audio questions can always be asked in the Web Audio Developers Community Group (http://www.w3.org/community/audio-dev/), discussion list at http://lists.w3.org/Archives/Public/public-audio-dev/.  Or on irc.w3.org#audio-dev, or freenode IRC ##webaudio.

I didn't know about ##webaudio. I should join. :-)