有一个很长的maxDelayTime有什么危害？

Question

我正在构建一个使用多个延迟节点的实时循环应用程序。我通过将maxDelayTime设置为比delayTime稍长来初始化延迟节点，因为这似乎是正确的做法。我不知道它是否真的有所作为，但是设置一个maxDelayTime例如看起来很浪费。 3分钟，我只需要延迟〜10-15秒。

但是，我希望用户能够调整循环的大小，这就是我遇到问题的地方。如果用户希望循环更小，我可以将delayTime设置为更小的数字，并且都是好的。但是，用户不能使循环变大，因为maxDelayTime不能被覆盖。我可以用适当的maxDelayTime重新创建所有延迟节点，但延迟节点连接到其他节点或从其他节点连接，所以我宁愿不重新创建整个事物。

所以我的问题是：

它是一个坏主意，创建8个延迟节点有3分钟maxDelayTime，即使delayTime通常少于30秒，以防用户想要做一个更长循环？

Answer 1

是的，这是一个坏主意。

想到这一点的最佳方法是maxDelayTime设置不断更新的内部缓冲区的大小 - delayTime只是改变了该缓冲区中的查找点。如果你设置的maxDelay过大，你会咀嚼大量的内存（例如8个延迟节点，立体声为44.1kHz，maxDelay为3分钟将占用大约496兆字节。在移动设备上，这是一个（甚至在桌面上，这是相当多的）

我可能会有一些拐点换出新节点 - 例如> 30秒，> 2分钟 - 并为这些设置maxDelay例如，如果您的默认值为30秒，那么您的8个节点“仅”为82 meg