We are using the PS3 version of FMOD Ex as a low level driver for our sound system.
The sounds are FSB wrapped MP3s resident in memory and they are opened with [b:3cyjpnf1]FMOD_CREATECOMPRESSEDSAMPLE | FMOD_OPENMEMORY_POINT[/b:3cyjpnf1]. We are playing between 30 and 50 sounds at time.
We release around 5 sounds per frame. Sometimes, when we call Sound::Release it gets a lot of time to complete, >10ms very common with spikes of 25ms.
Our system is quite loaded (on the main processor side) but there isn’t any evident relation between system load and Sound::Release running time.
- alahel asked 10 years ago
[quote="outi":3b70g1xh][quote="brett":3b70g1xh]you’re not really supposed to be allocating and freeing samples in realtime.[/quote:3b70g1xh]
Could you explain this a little bit? Isn’t it inefficient use of memory not to release sounds when they have played to end?[/quote:3b70g1xh]
its way more inneficient to be loading and freeing sounds every time you play them, thats a huge waste of cpu time.
If you want to do it, then you have to face the fact it has to free memory and close file handles etc. Im not sure how this is supposed to be done in zero cycles.
Could you please suggest which is the proper "strategy" for streamed sounds?
Is it possible to release them after some time without incurring in the time penalty? Will it be ok, for example, to wait 1 minute and then release them?
I could easily imagine a real application (a video game in my case) in which there is very intense action with a lot of streamed sounds for a prolonged span of time. In that case the "release at the end" strategy it is not a good one and the huge time penalty for "release immediately" make things unpleasant.
A streamed sound (or any sound) can be opened with FMOD_NONBLOCKING.
This flag puts it in a thread and loads / prebuffers in the background. Sound::getOpenState is used to poll the status of the loading progress.
To close – you generally have this done at the end of a level, or even when leaving the game (ie leave it open). Thats why we have FSB, so you can pack all of your streams into 1 file then use getSubSound to switch between different streams instead of having to open and close indivual files all the time.
Sorry to reopen this thread, but I’m using the event-based programmer sound method to load speech from an fsb, using the SOUNDDEF_CREATE/RELEASE callbacks to getSubsounds of an fsb opened for streaming, as mentioned in other dialogue threads.
If I try to release the fsb stream when I’m finished with it (e.g. at the end of a level), I get a crash. Looking at the ProgrammerSound example, the fsb is released [b:2lir8rnq]after[/b:2lir8rnq] the event system, so maybe this is just something that is essential, and there’s no way to release the fsb in this instance? (even though I’d already released the Sound it gave me). If I’d been using the event system for this, then obviously I could call freeEventData on the speech event group to release the fsb data, but with this method there is no way to do it, but ideally it would seem there should be a way to release this memory too when leaving a game level. So…
- Are you simply not able to release a streamed fsb from FMOD::System, even if nothing is using it any more?
- If I wanted to organise my speech into different soundbanks for organisation reasons, that would open these gradually (allocating more memory each time) and just leave all these fsb streams open until the game closes. Is the overhead involved for these just not worth worrying about then (as long as I didn’t have lots of them)?
- crouton answered 10 years ago
Make sure you are releasing the sound only when it’s COMPLETED or in ERROR state.
For example if the sound is still LOADING (e.g. busy) and you try to release it, it would delay the release.
Check the documentation on release().
If you are using the EVENT system to play them, that’s not in the doc, but it happens internally.
I am not sure of what you mean with COMPLETED state. As I said the sounds are in memory (not streamed). We are using the C++ API.
In any case, Sound::getOpenState is always FMOD_OPENSTATE_READY (I cannot find the ‘completed’ state you were referring to). Channel::isPlaying is always [b:75xqr7rk]false[/b:75xqr7rk] and it returns FMOD_OK most of the time, FMOD_ERR_INVALID_HANDLE sometimes and FMOD_ERR_CHANNEL_STOLEN rarely.
you’re not really supposed to be allocating and freeing samples in realtime – it was never intended for that. Release has to do all sorts of things including freeing memory, and waiting for the dsp engine to finish mixing before it can disconnect stuff.
[quote:1afynxhy]you’re not really supposed to be allocating and freeing samples in realtime – it was never intended for that.[/quote:1afynxhy]
Thanks. That make things clear.
However this raise another issue: it is ok to pre-create sounds and release them in the end for static one; but for streamed sounds it doesn’t make much sense. Could you confirm me that "the intended way" of using streamed sounds is create them when needed but release them only at the end? This seems a little bit inefficient… for the time that we are ready to release them they can be thousands!
Is there a way to tell when a sound is "ready" to be released without to much overhead?
[quote="brett":tzt91xg5]you’re not really supposed to be allocating and freeing samples in realtime.[/quote:tzt91xg5]
Could you explain this a little bit? Isn’t it inefficient use of memory not to release sounds when they have played to end?
- outi answered 10 years ago
oh… another thing about the streamed sounds.
It seems to me that the file from which a sound is streamed is closed only on Sound::Release. Sure you are not saying that we have to leave all the streamed file in an open state! Could you please elaborate on that?
Please login first to submit.