Re: Sites using webkitAudioContext only

On Tue, Jun 11, 2013 at 5:01 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

> No, you're not the only person thinking that.  I agree that having
> "alternate names" is significant badness.  Really, Web Audio in its current
> form is not a great web spec.  It should probably use constructors instead
> of creator functions, have a better interface for recording playback rather
> than OfflineAudioContext, and probably have a singleton "context" object,
> etc.
>

Hmm, not sure I agree with the constructor-vs-creator and singleton context
issues - how would you (eventually) do multiple audio devices, if you don't
keep separate contexts (and link the creation of nodes to specific
contexts)?

I don't think anyone, Chris included, thinks OfflineAudioContext is the
right interface for "recording"; it *is* necessary (and useful) for offline
processing, though.  I would expect that at some point we'd add a
RecorderNode, that can start and stop recording, and ideally even have
encoding built in.  This is pretty easy to do using a script processor
node, though, as recorderJS shows (minus the encoding bit - yes, big WAV
files are BIG).


> The reason that we are stuck with "alternate names" and all of the rest of
> the API badness in Web Audio _is_ Blink/WebKit resisting changing most of
> the APIs.  (Actually most of this discussion was before Blink was publicly
> announced, and from what I know resisting this is actually in contrast to
> the new Blink policy, but Chris Rogers probably knows those rules better
> than I do...)
>
> I initially resisted implementing the alternate names in Gecko, and I was
> planning on resisting to implement some of the other bad ideas in the Web
> Audio spec (such as the synchronous createBuffer override), but I changed
> my position given the developer feedback of "Web Audio not working in
> Firefox Nightly", etc.  For better or worse, Google pushed
> webkitAudioContext as _the_ Web Audio standard to use way before the API
> was looked at by other browser vendors, and now we're stuck with these
> issues because WebKit/Blink will not accept "breaking" changes to their
> implementation, and IIRC Chris Rogers said that even when it's unprefixed,
> he's planning to maintain backwards compatibility with webkitAudioContext
> APIs.
>
> I still believe that Web Audio is still not nearly as widely used as most
> other web APIs, and the only engines shipping it have implemented it with a
> prefix.  We still have time to fix this, but we need buy-in from
> WebKit/Blink (or at least Blink).  If we get that buy-in, I will work on
> adopting all changes to the spec in Gecko, even if it means that we would
> need to delay shipping this in Firefox, since I believe that shipping a
> better API is better than shipping a bad API sooner,
>

Chris is absolutely correct that there are some critical apps out there
today that use the API as it is.  I would not, for example, like to be the
one who breaks the sound in Angry Birds - and this stuff has been shipping
in Webkit (and now Blink) to a very large number of developers and users.
 It's also hard to coordinate a change for developers across the multiple
implementations we have in the wild today.  However, that said, I don't
think that means we should give up on those changes being made; it just
means that when we make a change in the spec, it is going to be a process
to change over to the new way and remove the old way, and it is not going
to be instantaneous, or in some cases even very quick.  We will have to
push the use of the old ways to near-zero before we could pull them out;
and I've been waiting for Safari to deploy the new naming before beginning
the evangelism of "use this, not that."  In addition, the availability of
monkeypatching libraries would, in my opinion, help this process quite
dramatically - and finally, as Alex said, the unprefixing is yet another
inflection point for us.

We have to proceed down this path doing the right thing.  I don't want us
making gratuitous changes to the spec, but we should be building the spec
we want to have.

-Chris