Re: Sites using webkitAudioContext only

On Thu, Jun 20, 2013 at 4:21 PM, Robert O'Callahan <>wrote:

> On Fri, Jun 21, 2013 at 4:34 AM, Chris Wilson <> wrote:
>> I would say I would like to not continue to bikeshed issues like
>> constructors vs creators for an unspecified period of time, and that
>> changes on that level should not be considered without strong need.
>>  Removing alternate names is not a problem.
>> On Wed, Jun 19, 2013 at 1:42 PM, Ehsan Akhgari <>wrote:
>>> The only implementation which currently has an unprefixed implementation
>>> which is close to shipping is Gecko, and I've said many times in this
>>> thread that I'm open to delay shipping Web Audio in Firefox if we end up
>>> making a large number of changes in order to improve the API.
>> Yes, which I think is the right thing to do.  But simultaneously, I feel
>> that pressure is being placed on Blink to remove its current somewhat
>> stable webkitAudioContext, and to sign up for an unbounded set of changes
>> to the API.
> I agree that we shouldn't be doing that.
> I'm in favour of limiting the scope of compatibility-affecting changes for
> the unprefixed AudioContext to those that are either trivial or essential,
> and setting a hard, short deadline for finalizing that list --- 1-2 weeks.
> I think that list should be:
> -- Everything that's already in the spec
> -- Remove obsolete names. Ehsan will provide the precise list shortly.
> -- Remove AudioContext.createBuffer(AudioBuffer)
> -- Fixes to prevent races caused by changes to "live" AudioBuffers. I can
> provide a proposal for this today, based on what we've already implemented.

 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.

> Promise-based APIs can be added later in addition to the direct-callback
> APIs, without much pain, so I'd drop them for now. Using constructors
> instead of factory methods is cosmetic and I don't think it's worth
> changing those at this point.
> 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 Thursday, 20 June 2013 23:44:37 UTC