- From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Date: Fri, 26 Jul 2013 10:50:15 -0400
- To: "K. Gadd" <kg@luminance.org>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, Alex Russell <slightlyoff@google.com>, "public-audio@w3.org" <public-audio@w3.org>, "www-tag@w3.org List" <www-tag@w3.org>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
- Message-ID: <CANTur_5wfpSSHPJivot-iEgRnGeCHSsSaZ43sCLk_C4-2ZTHJg@mail.gmail.com>
On Fri, Jul 26, 2013 at 9:05 AM, K. Gadd <kg@luminance.org> wrote: > Is it possible for that library to function without causing leaks, though? > I'm not sure how you would distinguish between dead AudioBufferSourceNodes > and live ones in such a system since the only approximation to weak > references JS has is a WeakMap. It seems like if you were to do > interception to record graph nodes, you would end up accumulating > information on every single dead AudioBufferSourceNode and eventually > exhaust available memory. Maybe you could solve all problems of this type > by manually doing garbage collection of the interception data, and figuring > out which nodes have to be dead based on how long it has been since they > started playing, etc, and then release the data appropriately. > What I meant was for the interception layer to record its own structure of the graph, not keeping the underlying AudioNodes alive by any means. When "replaying" the graph, the library will run code to regenerate the AudioNodes and connect them appropriately to create a new graph with the same structure. Please keep in mind that an AudioNode created using one AudioContext cannot be connected to another one created by another AudioContext, so keeping the nodes themselves alive will not buy one much anyway. Cheers, -- Ehsan <http://ehsanakhgari.org/> > > On Fri, Jul 26, 2013 at 5:57 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote: > >> On Thu, Jul 25, 2013 at 7:37 PM, Robert O'Callahan <robert@ocallahan.org>wrote: >> >>> Thanks for this feedback! >>> >>> Regarding this issue, see >>> http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0432.htmland the surrounding thread. Web Audio's design encourages a "fire and >>> forget" approach of constantly creating new nodes and never explicitly >>> removing them, which is incompatible with APIs that expose graph structure. >>> If the TAG insists on having such APIs, then we'll have to redesign Web >>> Audio significantly (probably making it harder to use), which I don't think >>> anyone in this group really wants. >>> >> >> I agree. Also, I'd like to note that it's possible to write a Javascript >> library which intercepts the Web Audio API calls to record the information >> needed to reconstruct the graph on a different AudioContext to achieve the >> desired behavior described in this issue. >> >> -- >> Ehsan >> <http://ehsanakhgari.org/> >> > >
Received on Friday, 26 July 2013 14:51:29 UTC