W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: [web-audio-api] (OfflineAudioContext): Offline Audio Context (#222)

From: Olivier Thereaux <notifications@github.com>
Date: Wed, 11 Sep 2013 07:30:27 -0700
To: WebAudio/web-audio-api <web-audio-api@noreply.github.com>
Message-ID: <WebAudio/web-audio-api/issues/222/24244853@github.com>
> [Original comment](https://www.w3.org/Bugs/Public/show_bug.cgi?id=17389#0) by Srikumar Subramanian (Kumar) on W3C Bugzilla. Wed, 17 Oct 2012 11:47:25 GMT

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.

Reply to this email directly or view it on GitHub:
Received on Wednesday, 11 September 2013 14:39:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:24 UTC