I’m profiling calls to freeEventData and am seeing that it sometimes takes 15ms. What could be causing it to take so long?
[code:2oj6b238]TBOOL bWaitUntilReady = TFALSE;
FMOD_RESULT result = pGroup->freeEventData( TNULL, bWaitUntilReady); [/code:2oj6b238]
Here’s some more info for the particular group in question.
[b:2oj6b238]Wave Bank Settings[/b:2oj6b238]
Bank Type: Stream from Disk
Enable syncpoints: No
Optimize Sample Rate: No
Force Software: No
Max streams: 1
[b:2oj6b238]All Events referencing .wav files in the Wave Bank have the following common properties[/b:2oj6b238]
Max Playbacks: 1
Max Playbacks Behavior: Just fail
These particular events are retrieved by calling [code:2oj6b238]TBOOL bCacheEvents = TFALSE;
pEventProject->getGroup(a_sGroupID, bCacheEvents, &pEventGroup);
pEventGroup->getEventByIndex( iSoundIDIndex, FMOD_EVENT_NONBLOCKING, ... );[/code:2oj6b238]
All of these events are being used for Voice Overs. I’m using a separate event for each voice over so I don’t have to programmaticly manage a list of wave file names needed to play the events as programmer sounds.
I’m trying to unload a Voice Over group if
1. no voice overs are playing or
2. no voice overs are qued to play.
3. the group hasn’t had an event played from it in 5 seconds.
It’s necessary to do this b/c we don’t have enough memory to only unload voice over groups at the end of the level.
Thanks for your help!
- NESboi asked 10 years ago
freeEventData should return immediately if the waitunitready parameter is set to false. I haven’t been able to reproduce this behaviour in any of my tests. Is there any other info you can give us to help reproduce it. How often does it happen for you?
Do you have the software mixer turned on? We suspect that it could have something to do with that.
(you can make sure it is turned off by linking to the _reduced version of the wii library, or passing in FMOD_INIT_SOFTWARE_DISABLE to eventsystem::init)
Hi. Thanks for the response. We are already doing everything you suggested. Below should be the pertinent part of our FMOD initialization code.
[code:l2181txo]int iMemSize = 12*TMEMORY_MB
alloc = TMemoryHeap_Memalign(TMemory_GetMem2Heap(), 32, iMemSize);
FMOD::Memory_Initialize(alloc, iMemSize, TNULL, TNULL, TNULL);
pFMODSys->setHardwareChannels(10, 20, 10, 20);
m_pEventSystem->init(m_oInitValues.m_iNumChannel, FMOD_INIT_SOFTWARE_DISABLE, 0, FMOD_EVENT_INIT_NORMAL );
a_iStreamBufferSizeBytes = 64 * 1024;
m_pSystem->setStreamBufferSize(a_iStreamBufferSizeBytes , FMOD_TIMEUNIT_RAWBYTES);[/code:l2181txo]
With regards to providing you with additional information, I’d be glad to but can you be more specific as to what sort of information would be helpful?
[b:l2181txo]Some Additional Info[/b:l2181txo]
Our Voice Over event groups have min 22 to max 41 events in them.
Each group references sound definitions which reference audio that is stored in separate Wave Banks.
A single sound definition can reference multiple wave files. Thus each wave banks has ~[62 – 82] wave files in them.
- NESboi answered 10 years ago
You said above you are waiting for streams to stop before freeing the event data. Are you freeing eventdata on streamed events or in memory or a mixture of both?
It could even be possible that you have a thread of your own that has taken priority during fmod’s function, stalling it and not returning until 15ms later (remember wii’s multitasker is not pre-emptive it is cooperative).
Try using the logging version and add the timestamp flag to FMOD_Debug_SetLevel so that you can see how long it took between each debug log line, it would let us know at what point there was a stall.
Please login first to submit.