Is this just an example?  Of course, for this example, the obvious solution is to schedule the source node to stop at or after when the gain node has reached 0.  For the example, this is a known time for each.

I assume you have another example where you do not know when the gain node reaches zero so you don't know when to schedule a stop for the source node.  Is that right?

Having said that, I think it's generally not a good idea to expect GC to release everything for you.  You don't know when GC will happen so you may still run out of resources sooner than you might expect.

You're correct. In this example I could easily schedule a stop time for the
source based on the known end-of-envelope time for the gain node. In
another setup that I had, the gain node and the source node were logically
decoupled (i.e. only the envelope generator knew the stop time, and only
the sound source had access to the source node).

I will refactor my code to solve the issue, but I still think that it would
be reasonable to assume that the graph could auto GC in more situations
than today, e.g. when the following conditions are met:

1. A gain node has the gain value zero.
2. No more automation events are schedule for the gain value.
3. The gain value is not connected to any other node.
4. No JS referenser is held to the gain node.

...then the gain node could safely be GC:ed, just as a source node can be
automatically GC:ed under certain conditions.
Den 10 maj 2016 9:52 em skrev "rtoy@chromium.org via Monorail" <
monorail@chromium.org>:

On a related note, I'd also like to point out that there is a performance problem with having many pending source nodes.

If you indeed add an explicit stop to the provided example (i.e. srcNode.stop(t + attack + sustain + release) just after srcNode.start(t)), you will notice that the CPU usage actually starts high and then goes down as more and more notes are played.

If I change the number of notes from 256 to 1024, I will even get glitches during the start of the demo, which eventually goes away as the CPU usage goes down.

If I start 2048 notes, the audio context will only play for a fraction of a second before it automatically terminates. (Again, this is on my dual 1.7 GHz CPU).

Re c#3:  Thanks for the info.  Yes, you are right; we could GC nodes sooner.  For your gain node, I think item 3 isn't even required.  The output is silence, so we can just disconnect to from all downstream nodes and collect it right away.

Adding all of these smarts to the individual nodes will take some time and debugging, of course.

Re c#4: I assume all of the source nodes are connected to a gain node that is connected to the destination.  This is pretty much expected behavior.  If the source is connected to the destination (directly or indirectly), the source needs to check to see it needs to play the buffer.  In this particular example, the "easy" solution is not to connect the source to the gain node until you're just about ready to play it.  

This is one reason why we have been very reluctant to implement the "patch cable" approach in crbug.com/485728.  If the patch cable approach is done, source nodes will always be processing.

As for the strange high CPU usage at the start, I'll have to take a closer look to see what's causing that.  I don't know off-hand what it could be.

While I understand that having many inactive source nodes connected to the main graph will consume CPU cycles, I think that it should be possible to allow for a few 1000 inactive nodes without severely affecting the total CPU load?

My use case is basically to schedule all the notes of a piece of music up front - something that seems like a reasonable use of the API, or maybe I'm overoptimistic?

I think your requests are reasonable.  

Currently, inactive means not connected directly or indirectly to the destination.  So for your use case, create all the nodes up front, even connect them to the gain nodes, but don't connect the gain node to the destination until you're ready to play the note.

We should definitely strive to do something better than this; I'm just not sure what we can do, though. :-(

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Need to investigate this further as an optimization.