Re: Sites using webkitAudioContext only

On Wed, Jun 12, 2013 at 11: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).
>

FWIW I, too, think that the core of the audio processing model in the spec
is quite solid, and Chris Rogers definitely deserves credit for all of
that.  Most of my concerns are about the API.  Though I have a lot of
concerns with the synchronous createBuffer API, and the
ScriptProcessorNode, but Robert O'Callahan has mostly convinced me that we
need something like ScriptProcessorNode...


>
>
>> 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?
>
>
>> 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.
>>
>
> From my perspective on TC39 and the TAG, it seems like unprefixing is the
> final chance to walk these decisions back and make final clean-ups. And
> that's not really related to the spec process except that they are highly
> correlated.
>

I agree.  Not sure if you've seen the other thread on the list yesterday,
but we're currently hoping to ship an unprefixed implementation of the full
spec in Firefox 24 which is currently scheduled to ship on September 17th.
That said, I'm absolutely open to adopting whatever spec changes we agree
on in Gecko, even if that means delaying the release of our implementation.


> I urge everyone here to take a second look: *can* the surface area for
> normative names be reduce*d?*
>

I really believe that going ahead with two alternate names is a mistake.
I'd very much rather only spec'ing one of them, and I personally don't care
a whole lot which one, though I think the start/stop names are a lot
clearer than noteOn/noteOff.


> *Can* the create*() APIs be walked back in favor of constructors?
>

I think so.


> *Can* the iterop story with the <audio> element be improved?
>

I'm not sure what the interop problems there are, and if they're issues at
the spec level or at the implementation level.  I finished my patch for
MediaElementAudioSourceNode in Gecko yesterday and I haven't hit any major
issues, but I can see how things can be trickier in other implementations.


> If the practical answer, based on real-world usage is "yes", then now's
> the time.
>
>
>> I still believe that Web Audio is still not nearly as widely used as most
>> other web APIs,
>>
>
> It's certainly not as widely used as many engine-specifc JS bugs and
> features which we are walking back/change over in TC39 land. As Yehdua
> said, "where's this magical land of compatibility? I build stuff on the
> edge of the platform and it breaks and changes all the time."
>
> Lets not tie ourselves down based on a promise that nobody is practically
> asking us to keep.
>
>>
Does Blink currently promise maintaining the exact same API when
unprefixing a webkit-prefixed API?


>  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 adoping 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,
>>
>> Cheers,
>> --
>> Ehsan
>> <http://ehsanakhgari.org/>
>>
>
>
Cheers,
--
Ehsan
<http://ehsanakhgari.org/>