0
0

I noticed that one of our streamed events was taking an extraordinarily large amount of memory when it was playing (3.9 megs). On further investigation, I found that that event was a random music event with approximately 65 samples in it.

By reducing it to 2 samples, the memory for that event when playing dropped to around 0.3 megs.

So, my question is: why does having a lot of inactive samples in the event incur such a huge memory penalty? In terms of memory, it would be much cheaper for us to make a random music object with 65 individual events and randomly select one programmatically instead of letting FMOD do it.

My sound guy and I couldn’t understand why it wouldn’t be cheaper to save the event overhead of 64 events and let FMOD randomly choose. Any reasons for this? FMOD isn’t attempting to buffer the beginning of every single sample in this case, is it?

(We’re still using FMOD 4.18 if that matters)

  • You must to post comments
0
0

it doesn’t sound like those sounds are streaming. I would double check the wave banks.
If you have them all in one bank, and it is set to streaming, it will open 1 stream. If there are layers with simultaeous sound instnace playback, or crossfades, it will probably open more.

  • You must to post comments
0
0

well, we did double check the wave bank settings and that wave bank is indeed set to "Stream from disk". This also matches what we see in the sense that there’s no way 65 pieces of music would be fitting in 3.9 megs, even in compressed form. the source audio is nearly 1 gigabyte of .wav files.

when that particular event is not playing, the memory usage attributed to that soundbank is 0 (unless some other event in the bank is playing). the way you are describing the system is exactly the way i would assume it works, which is why this behavior is totally odd.

should we send you guys the soundbank?

  • You must to post comments
Showing 2 results
Your Answer

Please first to submit.