Re: Some comments on the Web Audio API Spec

Thanks Paul for the clarifications.  Agreed about ScriptProcessorNode;
it turns out to be even more broken than I understood/expected it to
be from the spec. AudioWorker looks like it will be a nice step
forward (for audio signal processing at least).

Sidenote: I've now downloaded the Firefox source and am starting to
study up on the WebAudio API implementation there.  My comments so far
have been from the perspective of only having the API spec
documentation in hand and some usage of the API. Hopefully going
through an implementation will help fill in some gaps and help me
better communicate further questions/comments.


On Mon, Feb 2, 2015 at 4:11 PM, Paul Adenot <padenot@mozilla.com> wrote:
> On Mon, Feb 2, 2015 at 9:46 PM, Steven Yi <stevenyi@gmail.com> wrote:
>> Hi Paul,
>>
>> Wow, ScriptProcessorNodes capable of missing blocks really makes the
>> current state of things a bit fragile!
>
> Exactly. We tried (in Firefox) to have a buffer queue instead of
> double buffering, and this does make things a bit better for the
> output side, in terms of glitch resilience, but it adds latency, so
> it's a different tradeoff than other implementations. It's terribly
> broken in any case.
>
>> 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.)
>
> Yes, this is one of the property we want the AudioWorkerNode to have.
> The other main properties are:
> - No additional latency induced by the AudioWorkerNode
> - Arbitrary schedulable parameters (AudioParams), accessible from the
> main thread
>
> Paul.

Received on Monday, 2 February 2015 22:46:43 UTC