Re: Some comments on the Web Audio API Spec

Hi Paul,

Wow, ScriptProcessorNodes capable of missing blocks really makes the
current state of things a bit fragile!

For AudioWorkers, does this part of the spec (from 2.11.2):

"The AudioWorkerGlobalScope has an audioprocess event that is
dispatched synchronously to process audio frames."

then mean that it will not miss any blocks?  (I guess this is what I
was assuming of the ScriptProcessorNodes originally.)

Thanks!
steven

On Mon, Feb 2, 2015 at 3:23 PM, Paul Adenot <padenot@mozilla.com> wrote:
>
>
> 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.

Received on Monday, 2 February 2015 20:47:13 UTC