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

Re: Resolution to republish MSP as a note

From: Chris Rogers <crogers@google.com>
Date: Thu, 9 Aug 2012 13:31:23 -0700
Message-ID: <CA+EzO0=s1_Ke+gDX+viY12HFUbL02boDnUZiGWEoq_A7ngZxgg@mail.gmail.com>
To: Marcus Geelnard <mage@opera.com>
Cc: olivier Thereaux <olivier.thereaux@bbc.co.uk>, Mark Boas <markb@happyworm.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, James Wei <james.wei@intel.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>
On Thu, Aug 9, 2012 at 1:16 PM, Marcus Geelnard <mage@opera.com> wrote:

> 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".
>
> Regards,
>
>   Marcus
>

Hi Marcus,

So far, we've been talking about allowing JavaScriptAudioNode to run in a
web worker, adding the potential for multiple inputs/outputs, and also
potentially adding tighter integration with AudioParam.  I know you've also
been working on a math library, which looks like something which could be
designed in parallel as a general-purpose API and that a
JavaScriptAudioNode could call these functions.

What are your thoughts here?

Chris
Received on Thursday, 9 August 2012 20:31:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 9 August 2012 20:31:52 GMT