W3C home > Mailing lists > Public > public-audio@w3.org > April to June 2016

Re: Stopping a looping source when an envelope cycle has ended

From: Raymond Toy <rtoy@google.com>
Date: Mon, 9 May 2016 15:45:58 -0700
Message-ID: <CAE3TgXGpij9e8awg7mm+sseuqfBupCRfNdBgTZQc74P9dxBwZA@mail.gmail.com>
To: Marcus Geelnard <marcus.geelnard@gmail.com>
Cc: Paul Adenot <padenot@mozilla.com>, "public-audio@w3.org" <public-audio@w3.org>
Thanks for filing the bug. I now understand exactly what it is you're
trying to do and what you want to happen.

On Mon, May 9, 2016 at 2:13 PM, Marcus Geelnard <marcus.geelnard@gmail.com>
wrote:

> I filed bugs for Chromium and Firefox:
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=610456
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1271425
>
> The example used in the bug reports can be found here:
> http://mbitsnbites.github.io/misc/web-audio-many-notes.html
>
> My personal feeling/opinion is that either the Web Audio API should take
> care of these kind of things (which could be tricky, given all the possible
> corner cases), or there should be some easy-to-use API for catching things
> like AudioParam automation events (e.g. EventQueueEmpty). In general,
> looping/infinite sources are tricky, especially if they are only used for a
> short period of time (e.g. for a single note, as in my example).
>
> Regards,
>
>   Marcus
>
>
>
> Den 2016-05-09 kl. 19:27, skrev Raymond Toy:
>
> First, what Paul said:  File a bug with the browser.
>
> However, it seems to me that if you have a looping source, it can never be
> stopped (unless you stop or disconnect it).  Everything it's connected to
> must continue to process.
>
> In chrome, we do take some shortcuts if the gain is 0, but probably not
> when you have automations on the gain.  This would be an optimization that
> we need to do.
>
> On Thu, May 5, 2016 at 2:20 PM, Marcus Geelnard <marcus.geelnard@gmail.com
> > wrote:
>
>> Hi all!
>>
>> I just recently started doing some (almost) serious work with Web Audio,
>> and I'm glad to find that the API and the implementations are moving along
>> nicely!
>>
>> One of the things I have not been able to find a nice solution to yet,
>> though, is a situation that leaks memory and CPU cycles... (I'm sure
>> there's a solution that I have missed)
>>
>> I'm playing an AudioBuffer using a looping AudioBufferSourceNode,
>> followed by a GainNode that acts as an envelope modulator.
>>
>> Now, one AudioBufferSourceNode + GainNode is created and start():ed for
>> each note that I play, and all JS references to the nodes are dropped.
>> Eventually the GainNode will reach zero (when the envelope cycle has
>> ended), but as far as I can tell, the AudioBufferSourceNode will continue
>> sampling and eat CPU cycles.
>>
>> I think that this is correct behavior (the AudioBufferSourceNode has the
>> playing state set, so it will not be GC:ed), although there seems to be a
>> difference between Blink & Gecko w.r.t how much CPU is consumed by all the
>> silent nodes.
>>
>> Question: What is the best method for stopping / disconnecting a looping
>> source node at a predefined AudioContext time (i.e. when the GainNode has
>> finished all the automation events)? I would like to avoid keeping track of
>> all the active nodes myself (e.g. array of active source nodes + polling &
>> checking against currentTime)..
>>
>> /Marcus
>>
>>
>
>
Received on Monday, 9 May 2016 22:46:27 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 May 2016 22:46:27 UTC