Re: Some comments on the Web Audio API Spec

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
blocks.

Thanks,
Paul.