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

Re: "Lack of Serialization Primitives & Introspection" issue

From: Ehsan Akhgari <ehsan.akhgari@gmail.com>
Date: Fri, 26 Jul 2013 10:50:15 -0400
Message-ID: <CANTur_5wfpSSHPJivot-iEgRnGeCHSsSaZ43sCLk_C4-2ZTHJg@mail.gmail.com>
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>
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


> 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

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