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. 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 13:06:25 UTC