Answered
0
0

I’ve posted my question to StackOverflow as well, so you can take a look there.

http://stackoverflow.com/questions/1604 … ed-samples

The TL;DR version is that it looks like FMOD is leaving codec information allocated when it’s no longer necessary.

  • You must to post comments
Best Answer
0
0

Hi, just wanted to revive this thread. Was this ever fixed? We just integrated to FMOD and there was a huge memory overhead when just letting fmod decode the ogg itself. Verified when we just did the decoding ourselves and just pass the raw data to fmod.

  • Brett Paterson

    The current recommended method is to use FSB with vorbis encoding, so it is 1 codebook, 1 codec, many sounds. You shouldn’t be using loose ogg files, as each file carries a codebook which is far more overhead than just the codec overhead.

    Are you trying to use FMOD_CREATESAMPLE to make it decompress into PCM rather than letting it play compressed in memory? (though you have no option with .ogg files).

  • Michael Gamil

    Right, thanks for the clarification Brett. Yes we are indeed using the createsample flag to decompress and not using the FMOD_CREATECOMPRESSEDSAMPLE flag as we have no choice at the moment (all our sounds are in vorbis encoded ogg). By the way, is it possible to just add an already compressed ogg to an FSB (without recompressing it)? So that we could just make a tool to convert all of our sounds and to make it possible to use the compressed flag. Thanks.

  • Brett Paterson

    Hi,
    No that would mean there would be many codebooks (they’re hundreds of kb each), where FSB just stores 1 for optimization reasons. The FSBankEx tool has a command line version, and it accepts oggs, so even though it is transcoding it would be quite easy to write a script that puts all of those sounds into an FSB.

  • Michael Gamil

    Alright, understood. We are already planning to just reexport all (or majority) of our sounds to using the studio bank format and just integrate the studio api in the long run ( to also take advantage of other advanced features ). Right now, we are just using the low level as a first pass and so that we could still load our existing sounds. Anyway, thanks a lot for your time Brett!

  • You must to post comments
0
0

Hi,
Yes your investigation is right, the codec remains, this is mainly so information and things like Sound::readData etc can still function. To rework it looks a bit complicated at the moment, and you have found the worst codec to have this problem with, as ogg (reference source) is extremely bloated. Using 2 sounds , 1 user created and 1 for decoding isnt a bad method to remove that codec memory.
Also i could recommend using FSB with vorbis encoding, as the overhead is a lot lower with FSB (basically we dont use ‘ogg’ at all, just the vorbis bit).

i’ll see if lowmem flag can remove the codec in the future , and things like readData can just return an error in this case.

  • You must to post comments
0
0

Thanks for the response.

When you’re talking about the overhead of ogg vs. FSB w/ vorbis, you’re talking about the codec size, not the PCM size, right? The game I’m working on currently has thousands of oggs that would be hard to convert over (large patch size and time), and in the future, I’d rather have a homogeneous file format than a few different. I’m not worried so much about memory while loading – just persistent memory. As long as the "load twice" solution (hack :-P) works in our further testing, I’ll be going with that, based on your approval of it. That is, until FMOD supports a way to disable this memory usage itself.

  • You must to post comments
0
0

yes I mean codec overhead not the PCM memory.

I’ve noted the issue down as a feature for a future version, to remove the codec.

  • You must to post comments
Showing 4 results
Your Answer

Please first to submit.