I have about 10 returns, each with convolution reverb (each reverb with about 1MB .wav file). In game they are using over 130MB of memory all the time…
Is it possible to reduce memory usage somehow, I have maximum two reverbs actvate at the same (to allow blending), I don’t need all active all the time, maybe it is possible to upload impuse data in runtime instead all of them in mixer with all buffers allocated?
Did you solve it?
Hi,
If you share an impulse between 2 reverbs, current versions share that memory.
Did you find a solution for this? I have the same issue. What would you say is the best option to manage 10+ reverbs ?
Same issue here.
Big memory usage. A 6.6 MB IR files generate a > 41 MB data occupation on the bus.
I see on the other hand that the cpu cost is quite little so I could guess this big memory usage is related to some kind of algorithm maximizing speed but also increasing memory occupation? Maybe some different trade-off could be used by using another algorithm?
What approach do you suggest to use multiple convolution reverbs?
Hello, what format is your source IR file? The data is converted to frequency domain complex number format which is 8 bytes per sample. 6.6mb is actually quite a large impulse.
I have a ‘big hall’ impulse which runs for 4 seconds which is 352kb
Hey Brett,
thank you for your reply. I see, so you’re doing fast convolution frequency based.
We are using multichannel impulse responses, that’s the first reason.
Files are simple multichannel wave files 48Khz 24 bit.
I noticed anyway that some impulse responses that are added are 96 Khz and those IRs are our mistake for sure.
We will downsample everything to 48Khz 16 bit but we will need also to shorten the impulses I guess, we have some impulses about 7 seconds.
So I guess using 4 sec 48Khz resultes in a 4 * 48 * 10^3 * 8 bytes → 1500 kB for a mono file.
If I am using at least quad it means 6 MB for each convolution reverb, right?
That is still not small but it’s much better
Hi Luca, your calculation sounds about right. Convolution is a big ‘expensive’ effect so impulses must be managed to shorten length (trim silence or low activity tails) and extra channels increase overhead by multiple of each channel.
For CPU overhead FMOD , has a unique feature in that it can multithread the convolution processing into 3 threads to avoid large cpu spikes in the mixer or in the game. It also supports GPU processing on consoles.
For memory, I looked into storing the impulses compressed - but didnt continue down that path, it came with a lot of complications but could be considered again. It pushes more cpu overhead into the mixer to decompress impulses on the fly and -then- do the convolution.
Hi Brett,
I see. Indeed your algorithm is very performant, at the moment we have no particular cpu spikes with multiple convolution reverbs, but my cto rightly was quite worried about memory, so yeah we’ll have to take some measures as you suggested. We’ve already used it but not intensively as this time, so this kind of problem was kinda new.
It could be a good point for the future to allow to choose between raw or compressed impulse responses as platform options (even if I agree the overhead on the mixer might be so relevant that most of people would prefer the raw option).
Thank you!
Hey Brett,
sorry to come back on this topic, but I’m not sure that memory consumption is working correctly between shared impulse responses (there’s a post above you wrote down some years ago).
I have four buses that have 4 convolution reverbs with the same impulse (same file dragged from audio bin).
When i profile it I see that the memory used is exactly the same for each bus, but in the “total” memory count the memory of the 4 buses sums up. Instead, I would expect from your post above that memory should be shared and only take into account 1 instance of the reverb (21733 KB total memory in our example).
I can probably fix that with a more complex routing, but I wanted to know if I am misunderstanding something? Is there a particular way to share the impulse between different reverbs (it’s not enough using the same file?).
Thank you
I’ve done some investigation and it has changed somewhat in the last few years . some elements are shared but I would assume that impulses aren’t shared at this point.
I’ll have to check if this used to have a map/cache for the same impulse (in the past) but I don’t think it did. I can’t see why this couldn’t be implemented at some point.
I’ve done some core api tests creating reverbs with the same impulse (100kb wav) and the memory usage per instance is
1 instance = 2.42mb
2 instance = 3.97mb (1.64x original)
3 instance = 5.53mb (2.46x original)
4 instance = 7.08mb (2.92x original)
which is saying there’s about a 1.5mb per instance and a 900kb shared overhead for all instances.
quad channel, long impulses will use excessive memory so the key is to try and make them as small as possible in length.
Thank you for verifying this. If you could add the “shared impulse memory” to your tracker it would be a great feature to have!
Thanks Brett
