Some sounds (not all) experience a 2 or 3 frame delay before they are played. I am using FMOD_System_SetFileSystem to load data. I under the impression that when using this the data is streamed. I don’t know if it is the load times causing the issue since some large sounds don’t cause a delay but small ones do. It’s perplexing.
I can’t just load the events because I rarely have knowledge of the sounds that will be played at any given time, and it would be a huge burden on memory to load hundreds of anticipated events.
I’m hoping there is something I am doing wrong.
My game is all in cpp and I don’t use Unity Unreal of any other game engine.
I haven’t been able to reproduce any noticable delays with various sounds in the asyncio example, what version of FMOD are you using?
You can ensure sounds are being streamed in by creating offending sounds with System::createStream instead of createSound. Otherwise, you should be getting “Loading delay exceeded” warnings when running FMOD in logging mode, which might provide some more useufl information.
To run FMOD in logging will need to call Debug_Initialize and link to the logging versions of the libs.
I finally got the debug libs installed on the Switch. There is a 6 second delay is starting a sound. That makes little sense. I see this all over the game, this is just an easy one to make happen. It’s not feasible to “preload” sounds. The game has hundreds and hundreds of sounds and based on game play and can’t be predicted. This isn’t a game with levels that can be loaded. I sometimes see 1 or 2 frame delays on the PC, but never 6 seconds like on the Switch.
The event has 3 tracks, each with a 8 sound Multi Instrument. The sounds last 1/10 of a second, so these aren’t large sounds.
[WRN] EventInstance::update : Event {b33005ad-c309-4d10-968a-8e27a118a4fe} waited 6616 milliseconds for sample data to load. Preload sample data to avoid this delay.
NX Memory Use: 552.6M / 4758.0M heap | 1.5M / 32.0M graphics firmware | 59.1M program bytes | 2.0M stack bytes
I have noticed that if we wait a while before starting to play much of the delay goes away. It seems that FMOD might be sill getting everything loaded (strings). If this is the case, can we just wait for all that to be done?
These happen when the bank is loaded (FMOD_Studio_System_LoadBankFile). I’m not playing any of these sounds. Is there a way to wait until this is over, or am I initing the banks wrong?
Thank you for the additional information. 6 seconfs is a significantly long time for such a short sound to load. If you are able to share your Master.bank file and the bank file that this event is contained in I can try reproducing this issue and see what’s going wrong?
In FMOD Studio you can set inidividual assets to be streamed in by setting its Loading Mode in the Audio Bin, or you can set the loading mode for everything for a Platform by going to Edit>Preferences…>Build>{Platform name}>Advanced Loading Mode.
For the offending sounds in this case, if they are encoded as an MP3, Vorbis or FADPCM then you will be able to take advantage of the Compressed Sample loading mode which will load faster than the default Sample (Decompressed Sample) loading mode. Stream is usually best suited for larger sounds and you should aim to limit the amount of them you have playing at any one time.
I have some more information about what appears to be happening. All the ambient sounds for the entire game are in one event (made from 100’s of wav files) and I use a param to jump around based on the location. When I first start the ambience I get the stream of SystemI::createSoundInternal calls and while this is happening (in the background) all new events seem to be blocked.
Setting up the ambience like that was probably not a good idea, but it’s too late to change. Is there a API call I can do to know if new events are going to be blocked?
The only platform where this is causing issues is the Switch.
Thank you for the additional information, I will see if I can setup a similarly large event and reproduce this problem on Switch.
Perhaps you can try polling the sample loading state of that event using EventDescription::getSampleLoadingState.
While that reports FMOD_STUDIO_LOADING_STATE_LOADING you will know that any subsequent events will not be able to load as that thread is occupied, and once it returns FMOD_STUDIO_LOADING_STATE_LOADED you can move on to loading other events. Alternatively, you can call Studio::System::flushSampleLoading immediately after beginning to load that event’s sample data. This will block the calling thread until all sample loading and unloading has completed, and then you can try playing/loading any other events after that.