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

Re: Group rechartering update (Was: [Agenda] W3C Audio WG Teleconference, 23rd May 2012)

From: olivier Thereaux <olivier.thereaux@bbc.co.uk>
Date: Fri, 25 May 2012 15:59:05 +0100
Cc: Chris Wilson <cwilso@google.com>, Philip Jägenstedt <philipj@opera.com>
Message-Id: <99E1F218-34F1-498C-8D34-A38F0AA6D53D@bbc.co.uk>
To: Audio Working Group <public-audio@w3.org>

On 25 May 2012, at 13:13, Philip Jägenstedt wrote:
>> Can you think of a scenario or two, and the kind of timing which would result from it?
> This is extremely hard to estimate…


> Taking the video section of the HTML spec [1] as an example of a spec that defines things in the detail necessary, the green sections are for Web authors and the rest is implementation requirements. The Web Audio API spec currently consists mostly of the kind of information that would be authoring information in HTML. Assuming that the proportions will be similar to be sufficiently well defined to write a test suite, the Web Audio API spec will need to grow to several times the current size. I can't guess how long time that will take, perhaps Chris is in a better position to guess.

At least the model for the web audio API is almost carbon-copied from a number of proven audio processing systems, which I think will help.

Taking the straw man proposal I sent earlier

> FPWD: Dec 2011
> LC: Q3 2012
> CR: Q1 2013
> PR: Q2 2013
> REC: Q2 2013

and based on the feedback, a more conservative estimate for the Web Audio API could look like this:

FPWD: Dec 2011
LC: Q4 2012
CR: Q2 2013
PR: Q4 2013
REC: Q4 2013

The thinking behind it is:The spec is based on years of audio processing experience, and there is already a fairly stable implementation of the draft spec: I don't think there will be a lot of features added. On the contrary, the bulk of the controversy around the spec will probably be about removing features from the v1 

See also, by the way, my message about splitting/modularising it:

While there will still be significant work on conformance/implementation language, I can see the group agreeing on a set of reasonably well defined features before the year is out. Hence a LC (hopefully the first and last) in Q4 2012. 

The rest flows from there, with a number of guesses as to how much reviewing LC would create, and how hard the implementation/testing effort would be. The result is a guessed timeline which feels quite right. 

It feels very important to me that we don't give ourselves a time target too far in the future. Demand for the API is happening *now* and I'd rather we focused on having a good feature set widely implemented in early 2013 than release an irrelevant do-it-all standard in 2016.

Received on Friday, 25 May 2012 15:02:02 UTC

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