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: Paul Adenot <padenot@mozilla.com>
Date: Mon, 9 May 2016 09:28:28 +0200
Message-ID: <CANWt0WoHo1Yn-=xwdyU8gkKivwHV9XNH-97iAJUebcEE_+CuKQ@mail.gmail.com>
To: Marcus Geelnard <marcus.geelnard@gmail.com>
Cc: "public-audio@w3.org Group" <public-audio@w3.org>
I think you're seeing an implementation bug (or bugs), please file a bug in
the respective vendor's bug tracker (or, in case of Gecko, just send me an
email if you prefer).


On Thu, May 5, 2016 at 11:20 PM, Marcus Geelnard <marcus.geelnard@gmail.com>

> 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 07:29:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 May 2016 07:29:18 UTC