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

Re: DSP API proposal/draft

From: Marcus Geelnard <mage@opera.com>
Date: Mon, 23 Jul 2012 16:07:37 +0000
Message-ID: <20120723160737.5606gwykksysss48@staff.opera.com>
To: olivier Thereaux <olivier.thereaux@bbc.co.uk>
Cc: public-audio@w3.org
Hi Olivier!

Citerar olivier Thereaux <olivier.thereaux@bbc.co.uk>:
> On 23 Jul 2012, at 14:08, Marcus Geelnard wrote:
>> I've put together a first (not yet complete) draft specification   
>> for a DSP API.
>>  http://people.opera.com/mage/dspapi/
> Thanks for sharing it. Looks quite nice, clear and complete.

Thanks :)  This is my first attempt at a Web spec, so I'd expect it to  
less than perfect...

>> Quite a bit of thought has gone into it, and some benchmarking has   
>> been done to find out what methods are useful to include, but I'm   
>> very open for discussions and changes. Here is a quick summary:
>> o Only 1D signal processing has been considered/included.
> I guess that's my main question. I understand that performance is a   
> big win, but we are talking about a lot of operations which would be  
>  very easy to implement from the basic math features in JS and other  
>  scripting languages. Arguably the benefit would be even higher for   
> vector math. But then... would the scope be way broader than that of  
>  our Audio WG?

For me the hardest thing is the balance between feature completeness  
and minimalism. If we want to solve *all* computational problems, we  
compete with e.g. WebCL and more advanced ECMAScript engines (and the  
whole point of the API is that it should be easy to implement). If  
we're too narrow, it's useless for anything but the audio API.

I personally think it's a good idea to focus on the audio part of  
things, though (thinking of the model of how Typed Arrays were  
introduced by the WebGL work). The other two main areas where I think  
array/vector math would be a huge benefit are 2D graphics (see my  
response to Jussi [1]) and 3D graphics (but that's a whole different  

I fully support the inclusion of support for 2D signals in the API  
(after all it makes perfect sense). The only question is if it should  
be part of the first version of the API, and if so who to sync the  
work with. I don't know of any other WG that deals with 2D signal  
processing (though granted, I haven't tried very hard to find one).



[1] http://lists.w3.org/Archives/Public/public-audio/2012JulSep/0264.html
Received on Monday, 23 July 2012 16:08:12 UTC

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