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

Re: Sites using webkitAudioContext only

From: Marcus Geelnard <mage@opera.com>
Date: Wed, 19 Jun 2013 11:26:03 +0200
To: "Chris Wilson" <cwilso@google.com>, "Ehsan Akhgari" <ehsan.akhgari@gmail.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Chris Rogers" <crogers@google.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>
Message-ID: <op.wyw5tpdzm77heq@mage-speeddemon>
Den 2013-06- 22:33:38 skrev Ehsan Akhgari <ehsan.akhgari@gmail.com>:

> On Sat, Jun 15, 2013 at 12:45 PM, Chris Wilson <cwilso@google.com> wrote:
>> On Fri, Jun 14, 2013 at 4:17 PM, Robert O'Callahan  
>> <robert@ocallahan.org> wrote:
>>> On Sat, Jun 15, 2013 at 9:45 AM, Chris Wilson <cwilso@google.com>  
>>> wrote:
>>>> We are open to removing the old names from Blink; however, I expect  
>>>> we will begin by offering a clean unprefixed version, and work hard  
>>>> at >>>>evangelizing to move developers over to that standards  
>>>> implementation; we can then remove the prefixed version at some point  
>>>> in the future (after >>>>doing console warnings, etc., to deprecate  
>>>> its usage).
>>> The problem is that this all needs to be done very soon.
>> Indeed, I can understand why this is time-critical for Mozilla, as you  
>> need to make decisions before shipping.  That's why I'm even MORE  
>> concerned >>about the introduction of the possibility of "more drastic  
>> changes", because any even medium-sized changes (and definitely  
>> something as major as >>changing the constructor pattern) is going to  
>> change this discussion.
> Here are the three categories of things which I would like to see  
> changed in the current spec:
> * Having more than one way to do things in the API.  This is mostly the  
> question of the alternate names which we're currently discussing.
> * Ways in which the API design introduces data race possibilities.  This  
> includes things such as allowing read-back from buffers used by the  
> audio >processing code, such as WaveShaperNode.buffer,  
> AudioBuffer.getChannelData, etc. as previously discussed on the list.   
> Removing these read-back >mechanisms would make it possible to use  
> copy-on-write techniques in order to make sure that we avoid copies  
> where we can, and that web content will >not be allowed to do things  
> which introduce data races.
> * APIs which make it possible to write inefficient code.  The  
> synchronous decoding using AudioContext.createBuffer is the only one  
> here that I can >think of.
> * General Web API design best practices.  This includes things such as  
> using constructors instead of creator methods, using DOM event targets  
> (which >we have already fixed), using DOM Promises for callbacks as  
> opposed to plain functions, etc.

Technically, that sounds like four categories ;-)

I would like to add that there are still some pretty awkward interfaces in  
the API (might fall under the last category, or in a separate  
"consistency/clean up" category?). In particular, not much has happened to  
the AnalyserNode (except for changing names from RealtimeAnalyserNode):  

Marcus Geelnard
Technical Lead, Mobile Infrastructure
Opera Software
Received on Wednesday, 19 June 2013 09:27:09 UTC

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