W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Resolution to republish MSP as a note

From: Marcus Geelnard <mage@opera.com>
Date: Thu, 09 Aug 2012 20:16:03 +0000
Message-ID: <20120809201603.2zy5krct88yswkcs@staff.opera.com>
To: olivier Thereaux <olivier.thereaux@bbc.co.uk>
Cc: Mark Boas <markb@happyworm.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, James Wei <james.wei@intel.com>, Chris Rogers <crogers@google.com>, Stéphane Letz <letz@grame.fr>, Audio Working Group <public-audio@w3.org>, Matthew Paradis <matthew.paradis@bbc.co.uk>, Christopher Lowis <Chris.Lowis@bbc.co.uk>
Citerar olivier Thereaux <olivier.thereaux@bbc.co.uk>:

> On 9 Aug 2012, at 09:40, Mark Boas wrote:
>> Standards are not about vendors, they are about developers.
> Sure. Notwithstanding the requests from developers who want to build  
>  libraries (useful, but a very specific view of things) the feedback  
>  we have received from developers seems to be:
> * The high-level access provided by the web audio API is great and   
> makes it easy to audio processing an analysis code easily, today,   
> with very little concern for optimization.
> * The moment you want to build anything custom, the API in its   
> current state is not great. I recall my team complaining that the   
> moment you want to do custom processing, you have to basically wrap   
> everything in your own class, and write a lot of boilerplate. [Ping   
> ChrisL/Matt for details.]
> The demand is for both, and I suspect this group would benefit from   
> having fewer suggestions that we should go for one XOR the other.

Yes, exactly. I think that the debate has been a bit biased towards  
only having good support for one of the two (either high level fixed  
function nodes or low level custom nodes). I'm in favor of having both.

The problem, as I see it, is that there has not been enough focus on  
fixing the custom nodes. The current set of fixed function nodes is in  
a quite mature state (the debate here seems to focus mostly on  
polishing the interfaces), but custom processing is not quite there yet.

I hope that we can have a serious discussion with the starting point  
of making custom processing a first class citizen of the Web Audio  
API, including identifying ways to make performance and latency as  
optimal as possible. If we all conclude that some of the required  
changes are not feasible at this point in time, we'll have to settle  
for something less, but let's not close the debate prematurely based  
on assumptions such as "It's complicated", or "Very few developers  
will use it anyway".


Received on Thursday, 9 August 2012 20:16:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC