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

Marcus,

I certainly agree in principle that scheduling lots of nodes up front
shouldn't consume so much resources. In practice, so far we've advocated
scheduling notes for only a certain time window ahead of the present to
mitigate such problems, and periodically "topping up" this list on an
interval timer. Chris Wilson posted an example of how to do this. I have
found this to be a really helpful practice in my current use of the API and
in fact hundreds of such notes can be scheduled without much of an impact.

Just to be totally clear, this is in no way suggesting that the bug
shouldn't be fixed.

...Joe

.            .       .    .  . ...Joe

Joe Berkovitz
President
Noteflight LLC

+1 978 314 6271

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Mon, May 9, 2016 at 6:45 PM, Raymond Toy <rtoy@google.com> wrote:

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