[Bug 22723] OfflineAudioContext and ScriptProcessorNodes

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

--- Comment #20 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> ---
(In reply to comment #19)
> 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.

Hmm, I know that roc really wanted the buffer size to be a choice that the UA
makes not one that the author makes...

But that aside, I still don't correctly understand why we have to fix the
latency issue in the offline processing case by allowing a buffer size of 128. 
Let's say that on a given path from a source node in the graph to the
destination node, we have N ScriptProcessorNodes, all with a buffer size of M
(for simplicity's sake.)  In this sitaution, these nodes are creating a latency
of N*M frames.  Can't we address this issue by disregarding the first N*M
frames that the destination node observes?  (I'm not 100% sure if this solution
works, but I can't completely convince myself either way.)

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

Have you performed measurements on whether (and how much) that affects the
responsiveness of the main thread?  I'm worried that if the audioprocess event
takes let's say 5ms to process on average, this may degrade the performance of
the page if it uses requestAnimationFrame to render an animation, for example.

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

Received on Tuesday, 23 July 2013 22:33:39 UTC