I’m trying to use FMOD_CREATECOMPRESSEDSAMPLE to preload a series of MP2 files. They are 1.3 megs on disk, uncompressed they are around 12 megs. I’m seeing an increase in memory usage of 12 megs directly after load when preloading the MP2’s (versus not loading the files at all) regardless of whether or not I use the compressed sample flag.
We are using the FMOD_SOFTWARE flag aswell, which I understand is a requirement. Is there something else I’m missing? Is there some sort of fixed memory overhead involved with loading compressed samples? If this is an issue with MP2’s specifically, is there another format that’s confirmed to work? Am I misunderstanding the intended use of this flag?
Thanks in advance.
- S0F asked 10 years ago
I work with SOF. One other thing we have found, is that it does not appear that we can do runtime pitch changes on mp2 files. For instance we have a "jet sound" that is played when a player is moving around, and we change the pitch depending on how fast he is moving. When the jet sound is a wav file, you can hear the pitch changing as he moves around. However, changing the sound file to an mp2 file disables the pitch adjustment and the sound plays at its standard pitch at all times. The behavior is the same whether the mp2 is created using CREATECOMPRESSEDSAMPLE or not. Is this the expected behavior with this file format?
- banana answered 10 years ago
No that is not the expected behaviour. You call channel::setFrequency, it will alter the pitch of the sound without any problem. It does not matter if it is using FMOD_CREATECOMPRESSEDSAMPLE or not. channel::setFrequency works regardless of what is being played.
It should be fine, there is about 30kb per codec * 16 codecs default = about 480kb overhead, these are specifically for FMOD_CREATECOMPRESSEDSAMPLE.
Can you post some sample code and maybe link an mp2 file and I can see what it happening. Its possible its not an mp2 file and defaulting to decompress into memory via some other codec.
Thanks for the impressively fast reply.
Just to clarify, we didn’t change the advanced settings structure. My understanding was that the memory for the default 16 mpeg codecs (along with the other supported compressed sample formats) were allocated when the sound device is initialized and the memory overhead for the codecs would not be contingent on whether or not the FMOD_CREATECOMPRESSEDSAMPLE flag was ever actually used. Is that correct?
I’ll post the relevant code along with a link to a sample MP2 as soon as I get back to the office.
Thanks again for the quick response.
I tested our sounds with one of the example apps and it did seem to load compressed. After closer inspection, it turns out I was accidentally setting the streaming flag on those MP2’s due to some faulty logic, which it seems was overriding the compressed sample flag.
Everything seems to be working as expected now. Thanks again for the quick response!
Please login first to submit.