W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2015

Re: Some comments on the Web Audio API Spec

From: Paul Adenot <padenot@mozilla.com>
Date: Mon, 2 Feb 2015 21:23:57 +0100
Message-ID: <CANWt0WowY3=SWsXvUyAbnBM3t9S-F1Qea_ET3rP_yQSw7f_A7A@mail.gmail.com>
To: Steven Yi <stevenyi@gmail.com>
Cc: public-audio@w3.org
On Mon, Feb 2, 2015 at 8:36 PM, Steven Yi <stevenyi@gmail.com> wrote:

> Hi Paul,
> Thank you for your replies to my points. I'll reply to your further
> questions below.
> Thanks!
> steven
> #######
> # Regarding:
>  "Can you clarify what "built-in [...] events in the Web Audio API" are
> ? Things like "connect" "disconnect" "node.buffer = somebuffer" ?
>  I was thinking that Web Audio doesn't have a notion of an Event
> object and processing system(and probably shouldn't, to allow the user
> to develop their own).  For example, Web Audio does not have something
> like audioContext.addEvent(2.0, func, arg0, arg1, arg2) that would
> create and queue up an event object, then fire it at time 2.0, and do
> an apply of the func with args.
> I think that's fine, as long as the user has the ability to write
> their own event system that can process synchronously with the audio
> thread, so as to get precise, reproducible event processing.

Exactly, we need to have a way of implementing precise mutation of the
graph, but we need to choose which path to take. Thanks for clarifying.

> # Regarding:
> "I'm curious why you think having ScriptProcessorNode is better than
> set{Timeout,Interval} or requestAnimationFrame, maybe something is
> badly worded in the spec ?"
> I may be operating under a wrong assumption. I'm assuming that
> ScriptProcessorNodes have their onaudioprocess called in sync with the
> audio thread's calling of other node's process functions. Maybe a
> little more formally stated, if buffer_0 is processed in a node that
> either depends upon or is depended upon by a ScriptProcessorNode, then
> buffer_0 will be processed by a ScriptProcessorNode before buffer_1 is
> processed by either depends upon or depended upon nodes.
> If that is not the case (which it sounds like), then I suppose using
> ScriptProcessorNodes do not have any better timing guarantees than
> setTimeout/Interval. But then it seems that ScriptProcessorNodes also
> have no guarantee that they will receive all audio samples for
> processing for a given audio graph?

It is not the case, and you're right that ScriptProcessorNode can miss

Received on Monday, 2 February 2015 20:24:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 February 2015 20:24:46 UTC