- From: olivier Thereaux <olivier.thereaux@bbc.co.uk>
- Date: Fri, 25 May 2012 15:59:05 +0100
- To: Audio Working Group <public-audio@w3.org>
- Cc: Chris Wilson <cwilso@google.com>, Philip Jägenstedt <philipj@opera.com>
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… Agreed! > 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: http://lists.w3.org/Archives/Public/public-audio/2012AprJun/thread.html#msg388 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. Olivier
Received on Friday, 25 May 2012 15:02:02 UTC