这有点像我之前的问题Web Audio API- onended event scope那样扩展，但我觉得这是一个足够单独的问题来保证一个新线程。
我基本上尝试使用网络音频API进行双缓冲，以便以低延迟播放音频。基本的想法是我们有2个缓冲区。每个都是在另一个人播放的时候写的，他们一直来回播放以形成连续的音频。
前一个线程中的解决方案只要缓冲区大小足够大就可以正常工作，但延迟需要一点点，因为我最终能够使用的最小缓冲区大约是4000个样本长，在我选择的44.1k的采样率约为90ms的延迟。
我理解，从前面的答案来看，问题在于使用onended事件，并且有人建议可以更好地使用ScriptProcessorNode。但是，我的理解是ScriptProcessorNode有自己的内置缓冲区，只要节点接收到音频并在构造函数中确定，就可以访问该缓冲区：
var scriptNode = context.createScriptProcessor(4096, 2, 2); // buffer size, channels in, channels out
我最初使用过两个交替的源缓冲区。有没有办法从ScriptProcessorNode访问那些，或者我需要改变我的方法吗？
答案 0 :(得分：0)
不，没有办法在脚本处理器中使用其他缓冲区。今天，您最好的方法是使用脚本处理器并将样本直接写入那里。
请注意，AudioBuffers的工作方式，您在以前的方法中无法保证不会复制和创建新的缓冲区 - 您无法同时从音频线程和主线程访问缓冲区
将来，使用音频工作者会好一些 - 它会避免一些跳线 - 但如果您（例如）从网络源向下缓冲流缓冲区，那么您将获胜。能够避免复制。 （事实并非如此昂贵。）如果你正在生成音频缓冲区，你应该在onaudioprocess中生成它。