我已经了解了A Tale of Two Clocks的能力，它描述了一种通过实时编辑（例如鼓机）为Web音频应用程序进行调度的方法，我对一个关键方面感到困惑。
该技术的主要动机是，一旦预定将AudioBufferSourceNode与start()一起演奏，就不能取消它。
但是如果我在计划播放之前在stop()上呼叫AudioBufferSourceNodes，它将永远不会播放，因此可以取消。那么为什么需要这种技术呢？我想念什么？
主要好处是audioBufferSourceNode.start(someTimeInTheFuture)精确采样。这就是为什么它比完全不准确的setTimeout(() => audioBufferSourceNode.start(), someTimeInTheFuture)更受青睐的原因。
由于Web Audio API的内部工作原理，如果可能的话，最好提前安排一些时间。每当在start()上调用AudioBufferSourceNode时，该命令就必须从主线程传播到音频线程，然后在该音频线程中执行该命令。这需要一些时间，这意味着如果您想立即开始某些事情，它可能在音频线程上的出现时间太晚了。
[我认为OP正在问“为什么我不提前安排所有音符，然后如果要停止则通过（stop。）取消所有剩余的音符？”
实际上，您可以这样做。对于小序列，这可能是一种好的方法。但是：
[如果您想要取消它们的功能，则需要分别挂起对每个AudioBufferSourceNode的引用-单独的第16音符踩hat模式在140bpm时有2800音符（= AudioBufferSourceNodes），播放5分钟的歌曲。对于整首歌曲，这也可能是大量的内存，可以一次分配和取消分配所有内存。对于更长的序列，可能没有吸引力。
如果您要对序列播放进行实时更改，尤其是这样-例如，如果您想更改速度，则需要取消所有剩余音符，然后重新安排它们。
我在ATOTC中详细介绍的技术的主要动机是在第二部分的结尾：“总之，因为您将需要灵活地更改速度或诸如频率或增益之类的参数（或完全停止调度），所以您不需要不想将太多的音频事件推入队列-或更准确地说，您不希望时间过长，因为您可能希望完全更改该计划。”我确实提到取消，但这确实是事后的想法。
如果您使用的是相对较短的序列，并且您不关心使用额外的内存，那么最简单的方法就是创建一个GainNode，将其连接到目标，然后将所有AudioBufferSourceNodes设置为连接到该GainNode。明确地，不要保留对您的ABSN的引用，而应保留对GainNode的引用-如果要取消，只需断开GainNode并释放它即可。没有其他东西可以玩到目的地了，所有东西最终都将被释放。 （我在第二节中也提到了这一点，尽管它可能有点贬义。对于较小的应用程序来说也可以。）