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 22:59:01 -0700
Message-ID: <CAJK2wqUqpcfTmbxw3MmGTRkOPhdc7m6akVyzMTLNDe1DybBEiw@mail.gmail.com>
To: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, Chris Rogers <crogers@google.com>, 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>
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 <
srikumarks@gmail.com> 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.
> https://gist.github.com/srikumarks/5780007
> 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
> http://sriku.org
> On 21 Jun, 2013, at 5:25 AM, "Robert O'Callahan" <robert@ocallahan.org>
> wrote:
> On Fri, Jun 21, 2013 at 11:44 AM, Chris Rogers <crogers@google.com> 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

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