Re: "Lack of Serialization Primitives & Introspection" issue

It seems like this would only handle certain use cases though. For example,
if I wanted to be able to record the current state of my AudioContext when
pausing a session - say of a game or some sort of audio playback - manually
recording commands and states would mean my recording would have complete
history of every AudioBufferSourceNode ever played. If I'm an hour into my
session that's a ton of nodes that should actually be dead but are eating
up memory in the session recording.

Ehsan pointed out that it's hard to actually do that sort of resume anyway
since you can't adjust the currentTime of an audiocontext so you wouldn't
be able to ensure that those nodes were dead when you recreated them, or
resume them at the position they were at.

On Fri, Jul 26, 2013 at 7:50 AM, Ehsan Akhgari <ehsan.akhgari@gmail.com>wrote:

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