Search code examples
javascriptdelayweb-audio-api

What's the harm in having a long maxDelayTime?


I'm building a live-looping application that uses several delay nodes. I initialize the delay nodes by setting the maxDelayTime to be slightly longer than the delayTime, because this seems like the right thing to do. I don't know if it actually makes a difference, but it seems wasteful to set a maxDelayTime of e.g. 3 minutes when I only need a delay of ~10-15 seconds.

However, I want the user to be able to resize the loop, and that is where I'm having problems. If the user wants the loop to be smaller, I can set delayTime to be a smaller number, and all is good. However, the user can't make the loop larger, because maxDelayTime cannot be overwritten. I COULD recreate all the delay nodes with an appropriate maxDelayTime, but the delay nodes are connected to/from a bunch of other nodes, so I'd rather not recreate the whole thing.

So my question is:

Is it a bad idea to create 8 delay nodes with maxDelayTime of 3 minutes, even though delayTime will typically be less than 30 seconds, just in case the user wants to make a longer loop?


Solution

  • Yes, that's a bad idea.

    The best way to think of this is that the maxDelayTime sets the size of the internal buffer that is continually updated - the delayTime just alters the lookup point in that buffer. If you set a maxDelay to be overly aggressively large, you'll chew up a large amount of memory (e.g. 8 delay nodes in stereo 44.1kHz with a maxDelay of 3 minutes would take up approximately 496 megabytes. On a mobile device, that's a huge amount. (even on a desktop, it's quite a bit.)

    I'd probably have boundaries around some inflection points that swap out for new nodes - e.g. >30 sec, >2min - and set the maxDelay for those sizes. If your default was 30 sec, for example, your 8 nodes is "only" 82 meg.