The AudioEcho instance is taking way more RAM than usual.
The repro file consists of a Baseplate with a LocalScript (located in StarterPlayerScripts) that creates 1000 AudioEcho instances in the workspace. When I playtest it, Roblox Studio’s RAM usage goes from ~1000 MB to ~8200 MB, which is 7.2 MB per AudioEcho. However, when my friend tested the same setup, their Roblox Studio only used 3.7 GB of RAM, so maybe it depends on the specs?
This bug started occuring on Roblox Studio v0.650.0.6500742, which also seems to be the version where the RampTime property was added.
The bug does not seem to be happening on the Roblox Player. (The RampTime property also seems to be disabled on the Roblox Player as of right now)
I don’t have any Beta Features enabled on Roblox Studio.
Hey @SquarePapyrus12, thanks for the report! It looks like when adding RampTime, we made the echo store its buffer in 32-bit instead of 16-bit, which increased the memory usage. We’ll get that fixed
If everything was working correctly, there would be 1000 AudioEcho instances on the workspace and the RAM usage would barely be affected.
AudioEcho is one of the more memory-heavy effects, since it has to store up to 5 seconds of past audio data – even after this fix, I would expect creating many of them will still use quite a bit of ram.
However, when my friend tested the same setup, their Roblox Studio only used 3.7 GB of RAM, so maybe it depends on the specs?
This probably has to do with your audio output device – if you are listening on a virtual surround-sound system with 8 channels, there will be 8 echo buffers, whereas a stereo system would only have 2
This was indeed why I had higher RAM usage than my friends, and when I plugged in my 7.1 headphones using the jack (to limit it to stereo), my results started matching theirs.
It seems that after the RampTime update, AudioEcho always allocates 5 seconds worth of past audio data instead of dynamically allocating it depending on the DelayTime property (previous behavior). This might be unrelated, but it also appears that before the update, AudioEcho did not allocate any memory until it was wired.
Ah good catch – with RampTime we’re aiming to make changes to DelayTime smooth and nicely-interpolated; unfortunately reallocating the buffer on-demand makes it very difficult to respond to changes without crackling.
We can definitely make it not allocate any memory until it’s wired up, though.