Re: Sites using webkitAudioContext only

On #1 - it was actually a design goal for me to not provide both sets of
names.  I wanted one library that would give you the new names if they
didn't exist (including unprefixed) to include if the user was using a
browser that didn't support the standard as writ, and a different library
if you were just quickly patching an app written to webkitAudioContext.
 Those were two different goals, to me.

On Thu, Jun 20, 2013 at 6:52 PM, Srikumar Karaikudi Subramanian <> wrote:

> Hi,
> A couple of points -
> 1. I noticed that Chris Wilson's AudioContextMonkeyPatch is only one way.
> This is not what I need
> because it doesn't patch AudioContext in un-prefixed implementations. So I
> made one for my
> own use since I do have legacy code that I can only port over time .. if
> anyone's interested.
> This patch will provide new names in implementations that have only the old
> names and will provide old names in implementations that have only the
> new names. It will provide both the prefixed and unprefixed AudioContext
> constructor if either is missing. On top of that, it will emit deprecation
> warnings
> for the old names upon use (only once) and urge you to move to new API
> names
> right away. This is exactly what *I* (as a dev) need to save myself time
> checking
> whether my code will work in various browsers (Blink, Opera, Mozilla)
> whenever
> they come out.
> 2. I think Mozilla "being forced to include webkitAudioContext" just to
> run
> existing code is a failed argument if neutering is already implemented to
> solve
> race conditions. Much of my code won't run, even with the above linked
> bi-directional
> monkey patch. I'm quite sure there are others like me. A "good" solution
> to this problem
> (imho) is to use immutable objects (ex: Blobs) instead of (or in addition
> to) ArrayBuffers,
> but I believe the decision is already made?
> Best,
> -Kumar
> On 21 Jun, 2013, at 5:25 AM, "Robert O'Callahan" <>
> wrote:
> On Fri, Jun 21, 2013 at 11:44 AM, Chris Rogers <> wrote:
>> I agree with most of this, especially the part about "limiting the scope
>> of compatibility-affecting changes for the unprefixed AudioContext to those
>> that are either trivial or essential".  The "races" issue for AudioBuffers
>> I do not agree with.  We can't be in a situation where we're
>> copying-data/duplicating/neutering large PCM data buffers each time we play
>> a sound.  These buffers are often quite large, and it's common to
>> re-trigger the same sound (from the same buffer) rapidly in succession for
>> game sound effects, synthesizers, etc.
> We're not neutering AudioBuffers --- you can use them over and over again
> without copying. We're neutering the ArrayBuffers used to create the
> AudioBuffers.
> Rob
> --
> Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le
> atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa
> stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm
> aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt
> wyeonut thoo mken.o w

Received on Friday, 21 June 2013 05:59:29 UTC