We’re using createSound/createStream to load, then play, previews of either one-shot samples or audio-streams (in 2 different frontend menus).
Both use .fsb’s containing multiple sounds, different audio formats on different platforms. The sample packs (loaded fully into memory) are usually around 200k and have around 6-7 samples, the streamed ones are audio much bigger, but played off disc.
When running these through the debugger off harddisk/USB/network, the async load works effortlessly. When running off a disc build, however, there are pauses in the game just as each one loads & plays. This is most noticeable on PS3 (freeze of up to 1 second each time), and least on Wii (regular, but very short pause each time). X360 gives very random/erratic freezes – different durations and not every time.
Tracing this in a profiler shows that it’s when createStream calls the internal filesystem function.
Anyone have any suggestions? Here’s hoping we’ve just missed some really obvious "turn on async filesystem operations" switch somewhere…
- paulfsg asked 8 years ago
[quote="a1psx":1cz9igh1]What flags are you using explicitly. How are you testing the state?[/quote:1cz9igh1]
[u:1cz9igh1]For the one-shot samples[/u:1cz9igh1]:
FMOD_LOOP_OFF | FMOD_NONBLOCKING, along with:
– FMOD_HARDWARE | FMOD_CREATECOMPRESSEDSAMPLE on X360, or
– FMOD_SOFTWARE | FMOD_CREATECOMPRESSEDSAMPLE | FMOD_IGNORETAGS on PS3, or
– FMOD_2D | FMOD_LOWMEM | FMOD_HARDWARE on Wii.
Function to check if it’s ready to play:
[code:1cz9igh1] FMOD_OPENSTATE tState;
FMOD_RESULT result = m_pSound->getOpenState( &tState, NULL, NULL );
return ( ( result != FMOD_ERR_NOTREADY ) && ( tState == FMOD_OPENSTATE_READY ) );
[u:1cz9igh1]For the streams[/u:1cz9igh1]:
FMOD_NONBLOCKING, along with FMOD_HARDWARE on Wii.
Most of the game code was already built around synchronous loading & assumes streams are ready to play immediately after creating them, so async streams automatically go into a queue which updates every frame, which queues up any play requests, and once the sound is ready, creates channel/s and calls the queued "[b:1cz9igh1]playSound[/b:1cz9igh1]" request.
The spike appears to be happening from the [b:1cz9igh1]createSound [/b:1cz9igh1]/ [b:1cz9igh1]createStream[/b:1cz9igh1] command, when it calls the internal filesystem command on that platform.
Tuner definitely shows a spike for us, it’s where createSound/createStream performs the internal filesystem call.
I thought it had something to do with using our own Open/Read/Close/Seek functions (since these turned out to not be async, just in a different thread), but letting FMOD access the filesystem directly didn’t seem to make any difference off BRD.
Starting next week, will be trying manually async opening the files using our own filesystem, then passing it as a memory ptr to FMOD… doesn’t help that the game’s 1 week away from beta
Note that FMOD does not perform -any- disk access in the main thread if you specify the nonblocking flag. That’s the whole point.
The only possibility I can see for a stall if people who use the event system have flooded fmod with load commands, and it is blocking, trying to flush the command queue. FMOD_ADVANCEDSETTINGS lets you control the queue size, but it is indicative of a higher level loading issue if this happens. There are plenty of warnings in the TTY when it happens as well.
Otherwise if the async thread is doing disc access, then a cooperative multitasker might switch in (wii, but not ps3 i’m pretty sure) if the thread priorities are wrong.
Whether or not FMOD was using our filesystem callbacks or not, the same delay was there. This, combined with Brett’s post about no disk access in the main thread, made me suspicious.
Eventually set up a minimal test app to asynchronously load, play & unload the sounds, with different timers to find where the freeze was happening. Turns out it was [i:2iy388sh]after[/i:2iy388sh] loading, when setting up the subsounds, channel/s etc before playing. Our code was waiting on a check to see if a definition file exists which allows the sounds to be accessed by a string, which combined with the rest of the post async load function, was causing the delay on PS3, but not on X360 (better file caching i assume) or Wii (in-memory FST).
Thanks for the help & suggestions.
Please login first to submit.