[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #15 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> ---
(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.

Again, using a buffer size of 128 would solve such rate discrepancies in
reading AudioParams. In general, it is looking to me like the best way for
script nodes to access AudioParams would be via some structure passed through
the event instead of directly reading the AudioParam objects.

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

Received on Sunday, 21 July 2013 14:49:57 UTC