Re: Sites using webkitAudioContext only

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.


> 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.

Cheers,

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



> The big reason for not evangelizing the use of (AudioContext ||
> webkitAudioContext) is that it actually makes it *harder* to consider
> changing names (between webkitAudioContext and AudioContext), as the
> developers will just patch that in, and won't think about finer-grained
> changes later on.  Monkey-patch libraries can be updated independently,
> though.
>
> (As an aside - I'd love help testing and evangelizing these libraries.
>  Or, if someone wants to take them over I'm happy to have that happen too.)
>