Re: Sites using webkitAudioContext only

On Wed, Jun 12, 2013 at 1:43 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Wed, Jun 12, 2013 at 8:53 AM, Alex Russell <slightlyoff@google.com>wrote:
>
>>
>>
>>
>> On Wed, Jun 12, 2013 at 1:01 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:
>>
>>> On Tue, Jun 11, 2013 at 7:44 PM, Chris Wilson <cwilso@google.com> wrote:
>>>
>>>> On Tue, Jun 11, 2013 at 4:08 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com
>>>> > wrote:
>>>>
>>>> On Mon, Jun 10, 2013 at 12:23 PM, Chris Wilson <cwilso@google.com>wrote:
>>>>>
>>>>>> I would actually strongly suggest that developers use a monkey patch
>>>>>> library, like my paired set:
>>>>>>
>>>>>> https://github.com/cwilso/AudioContext-MonkeyPatch: This library
>>>>>> should be used for new projects, which are written to the official Web
>>>>>> Audio specification, and it should monkey-patch the calls on systems that
>>>>>> may not support the most modern definitions (e.g. patching AudioContext to
>>>>>> webkitAudioContext, and start() calls get patched to call noteOn()).  You
>>>>>> could use this, for example, to get a properly written Web Audio app to
>>>>>> work on iOS today.
>>>>>>
>>>>>
>>>>> I'm not sure how useful this is for the Safari problem, but as far as
>>>>> Gecko is concerned, we fully support all of the alternate names mandated by
>>>>> the spec, so if you just switch to using AudioContext, then everything
>>>>> should work (including noteOn/noteOff, setTargetAtTime, etc.)
>>>>>
>>>>> Can you please modify this library so that it doesn't touch
>>>>> AudioContext?  I don't believe any of the AudioContext monkey-patching is
>>>>> necessary any more.
>>>>>
>>>>
>>>> Umm, no, that's the point of the library - otherwise, you CAN just do
>>>> audioctx = AudioContext || webkitAudioContext.  But read on...
>>>>
>>>>
>>>>>  https://github.com/cwilso/webkitAudioContext-MonkeyPatch: This
>>>>>> library can be used for old apps, written to webkitAudioContext
>>>>>> implementations, to get them working on proper spec-compliant
>>>>>> implementations of AudioContext (e.g. Firefox), without having to rewrite
>>>>>> all your code.  This is kind of a cheap way to do this (obviously, for any
>>>>>> significant app you should likely revise your code), but it makes it quick
>>>>>> and easy to get old code working on Firefox if nothing else.
>>>>>>
>>>>>
>>>>> Given the above, all you have to do is to use the AudioContext
>>>>> constructor, and fall back to webkitAudioContext if that's not available.
>>>>>
>>>>
>>>> I'm afraid I'm confused by what you want.  I'm going to share my
>>>> personal thinking here, but understand that Chris Rogers and I disagree
>>>> somewhat on some of the finer points, so this is not "the Google opinion".
>>>>
>>>> I personally think long-term, having "alternate names" is significant
>>>> badness.  If they're important enough to implement everywhere, just use
>>>> them; if your concern is just that your standard-following implementation
>>>> doesn't "work" for all those webkitAudioContext, noteOn()-using apps out
>>>> there right now, let's attack that problem together with some monkeypatch
>>>> libraries and some evangelism.  If you're just going to implement them all
>>>> anyway, then why do we change names and confuse developers by giving them
>>>> two methods to do the same thing, that differ only in name?  The
>>>> monkeypatch libraries, on the other hand, let us make these kind of changes
>>>> and fix it up in the short term, letting developers be "clean".
>>>>
>>>> My personal belief is the "alternate names" should be removed from the
>>>> spec long-term, as we migrate all the implementations out there to support
>>>> the new names (obviously, iOS Safari is the least-known quantity here).  In
>>>> the meantime, we can use evangelism of monkeypatching libraries to hide the
>>>> implementation complexities across different browsers, and as we roll
>>>> Chrome into unprefixed AudioContext, I would hope we could start removing
>>>> some old stuff.  (Yes, this is where Chris and I disagree, I believe.)  I
>>>> had not realized you were just implementing all the old names in Firefox.
>>>>
>>>> We have the unfortunate and difficult task of having multiple browsers
>>>> implement the old names, under prefix, and a fair bit of legacy content
>>>> that we do not wish to break, as well as the task of good stewardship for
>>>> the long term.  I still think we have the opportunity to fix the long term
>>>> without destroying the short term, but if I'm the only one who believes
>>>> that's the approach we should take, I'll just delete those two monkeypatch
>>>> repos and developers can use the || approach.
>>>>
>>>
>>> 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.
>>>
>>
>> I agree with all of this, and that's coming from someone who respects and
>> enjoys the overall current design. The block processing system is
>> fantastic, but the API is not. We can make it better backwards compatibly
>> too, should compatibility be shown to be a huge issue with real-world data
>> (which these discussions do not seem to have included to date).
>>
>>
>>> 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...)
>>>
>>
>> ...that's incredibly frustrating to hear. The WebKit world was different
>> than the Blink world; Chris: do you think we have the ability to make these
>> changes now?
>>
>
> There was nothing in WebKit's policy that controlled what Chrome shipped
> with concerning these APIs, so this was not an issue.
>
> The issue is that the names we're talking about (noteOn(), noteOff(), and
> others) have been in use for over two years shipping in Chrome, and for
> nearly a year in iOS and Safari.  These methods are about the most commonly
> used in the whole Web Audio API, so removing support for them would wipe
> out two years of content that has been produced.  This represents a set of
> work which I consider significant.
>

Do we have any actual data on how many real world (read: non-tech-demo)
content out there uses Web Audio (specifically, webkitAudioContext)?  It
would be _really_ helpful if we had publicly available data about this for
these kinds of discussions.  Angry Birds (or any other few games/libraries)
in itself should not be a significant factor in our decision making since
we can always evangelize around these kinds of problems.


> Whether or not these names should be a part of the spec and how they're
> described in the spec is one matter.  They were previously listed as
> "recommended" by me, but others wanted me to make them be normative.
>

Originally I did not implement any of the "alternate" names, so for example
Gecko supported AudioBufferSourceNode.start but not noteOn.  Then we
started to get feedback from developers who tried various Web Audio demos
by renaming webkitAudioContext to AudioContext and telling us that Gecko's
implementation "doesn't work" because those names were not implemented,
even though the functionality _was_ implemented under the new names.  Which
is why I feel that without those names going away in WebKit/Blink, we will
end up with conforming implementations which are not interoperable, which,
I believe, is the absolutely worst outcome we can have.


> In any case, because these APIs have shipped for a significant amount of
> time, it is up to individual browser vendors to decide how to support these
> older APIs.
>

Well, to be honest I'm not very interested in what WebKit/Blink decides to
do in webkitAudioContext.  The more important things are whether you're
open to the idea of breaking backwards compatibility on the unprefixed
AudioContext implementation, and if there are plans to unprefix
AudioContext soon at least in Blink.  Last time we discussed this you were
not open to the idea of content targeted at Chrome to break when developers
rename their usages of webkitAudioContext to AudioContext when the
unprefixing has happened.  Given the fact that the current WebKit/Blink
implementation is the de facto standard, that won't be a simple browser
vendor choice, it's going to be tried to the Web Audio spec.

Also, let me reiterate the importance of some of the implications of the
Web Audio spec as it is today:
* It is, to the best of my knowledge, the only web spec which has multiple
API names for the exact same functionality.
* It's repeating mistakes such as decoding audio on the main thread (see
the synchronous AudioContext.createBuffer override).  We have been spending
years trying to fight other similar bad ideas (see synchronous XHR as an
example.)
* It doesn't do things in a webby fashion (using creator methods instead of
constructors).  While that may seem like a style issue, I believe that it's
an API quality factor, which means that developers will have to do things
differently for parts of their code which uses Web Audio than other parts
(such as, creating a new audio element using the Audio() constructor.  :-)

Cheers,
--
Ehsan
<http://ehsanakhgari.org/>