- From: Raymond Toy <rtoy@google.com>
- Date: Mon, 9 May 2016 15:45:58 -0700
- To: Marcus Geelnard <marcus.geelnard@gmail.com>
- Cc: Paul Adenot <padenot@mozilla.com>, "public-audio@w3.org" <public-audio@w3.org>
- Message-ID: <CAE3TgXGpij9e8awg7mm+sseuqfBupCRfNdBgTZQc74P9dxBwZA@mail.gmail.com>
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