[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22723

--- Comment #19 from Chris Rogers <crogers@google.com> ---
(In reply to comment #18)
> (In reply to comment #17)
> > (In reply to comment #16)
> > > (In reply to comment #15)
> > > > (In reply to comment #7)
> > > > > If every node used this "wait for all inputs before running" logic, then
> > > > > script nodes with buffer sizes greater than 128 need not impose a delay in
> > > > > their signal paths. 
> > > > 
> > > > I just realized a subtlety in this. If a script processor node's
> > > > onaudioprocess reads computed values from AudioParams, then the perceived
> > > > k-rate for those AudioParams will be determined by the block size set for
> > > > the script node and not the fixed 128-sample-block in the spec. Not only
> > > > that, it will look like a filter-type script node (with input and output) is
> > > > prescient and anticipates animated AudioParams, because the the
> > > > onaudioprocess will only get to run once enough input chunks have
> > > > accumulated, meaning the values of some of these k-rate AudioParams could
> > > > already have advanced to a time corresponding to the end of the script
> > > > node's buffer duration.
> > > 
> > > No, according to the spec the implementation must do 128-frame block
> > > processing all the time, which means that for example if we have 1024 frames
> > > to fill up for a ScriptProcessorNode, we need to call the block processing
> > > code 8 times, and each k-rate AudioParam will be sampled at the beginning of
> > > each block.
> > 
> > That holds only for the native nodes, doesn't it?
> 
> No, that's true for all nodes.
> 
> > With the real-time
> > context, script processor nodes with buffer sizes > 128 (which is all the
> > time) already have a lower k-rate than the native nodes if they read
> > computed values of AudioParams within their onaudioprocess callbacks.
> 
> I'm not sure what you mean here.  How do you "sample" the AudioParam value
> inside the audioprocess event handler?
> 
> > Anyway, to ensure that the k-rate is uniform at least during offline
> > processing, it looks like the only way is to raise onaudioprocess events for
> > each 128-sample-frame block. The event dispatcher better put up some
> > performance :)
> 
> Doing that violates the current spec, and I think would be a very bad idea.

I agree that we shouldn't force it to run at 128.  But I think we should change
the current spec to allow for size 128, especially for the OfflineAudioContext
case.  Right now, the minimum size is 256, and we would like to get zero
latency for this offline case.

I've created an early prototype in Chrome which synchronizes the audio thread
with the main thread, and runs at 128.  I've found that the average time
between 
onaudioprocess callbacks is around 50microseconds.  I tried a really simple
test case:

AudioBufferSourceNode -> ScriptProcessorNode -> OfflineAudioContext.destination

and processed during a time period of several minutes long.  On a mid-range Mac
pro I saw around 60x real-time performance.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 23 July 2013 22:20:13 UTC