W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2013

Re: Sites using webkitAudioContext only

From: Chris Wilson <cwilso@google.com>
Date: Thu, 20 Jun 2013 23:00:42 -0700
Message-ID: <CAJK2wqXQQFaJQjFpTq_WRwURrKjPvuywP-z4gzCxGC4E1m4sDA@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, Ehsan Akhgari <ehsan.akhgari@gmail.com>, Kevin Gadd <kevin.gadd@gmail.com>, Marcus Geelnard <mage@opera.com>, Chris Lowis <chris.lowis@bbc.co.uk>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "public-audio@w3.org" <public-audio@w3.org>, Alex Russell <slightlyoff@google.com>
+1.  (Yeah, after nine hours of driving and several more hours of
unloading, that's about all I can say.  :)

On Thu, Jun 20, 2013 at 4:44 PM, Chris Rogers <crogers@google.com> wrote:

> On Thu, Jun 20, 2013 at 4:21 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>> On Fri, Jun 21, 2013 at 4:34 AM, Chris Wilson <cwilso@google.com> 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 <ehsan.akhgari@gmail.com>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 Friday, 21 June 2013 06:01:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:18 UTC