[Bug 17389] (OfflineAudioContext): Offline Audio Context

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

Srikumar Subramanian (Kumar) <srikumarks@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |srikumarks@gmail.com

--- Comment #1 from Srikumar Subramanian (Kumar) <srikumarks@gmail.com> ---
The current webkit implementation of an "offline audio context" is by
overloading the AudioContext constructor to accept 3 arguments -
numberOfChannels, numberOfFrames and sampleRate. The AudioContext interface
also has an event listener field called 'oncomplete' to indicate completion.
Should this be formalized in the spec? 

One consequence of offline contexts would be in the "4.1.3. Lifetime" section
of the draft spec which currently reads "Once created, an AudioContext will not
be garbage collected. It will live until the document goes away." Offline
contexts will need to be GC-ed.

An argument against offline contexts is that mix downs can be implemented in
pure JS anyway, but then the rendering pipeline for such a mix down will have
to reimplement all the builtin nodes in JS, which is wasteful.

>From an API perspective, it will be better to indicate that a context will be
offline in a more explicit manner than the constructor overloading approach in
the current webkit prototype.

If offline contexts are included, one likely additional requirement would be
the ability to schedule JS callbacks when the context reaches certain times.
This will be needed to setup dynamic parts of the render graph just-in-time so
the memory requirement of the render graph does not grow in proportion to the
duration of the offline context. One way to work-around the absence of such an
explicit callback mechanism is to introduce a dummy JS node whose purpose is to
trigger such callbacks. For this work-around to actually work, native nodes
have to stall for JS nodes, which should not happen in the realtime case if I
understand correctly. Such behaviour differences will then have to be
documented in the spec.

-- 
You are receiving this mail because:
You are on the CC list for the bug.