We solve this by loading all .fevs at startup. I know it’s not the best of solutions but it works for us, at least so far.

I have been working quite alot with FMOD and its resource management and even though it might have its points internally its one of the hardest and most complicated systems I have tried to integrate with an existing resource system. As one big wish right now I would like to see some enhancements here like for instance options for loading everything from memory and non-blocking. I know this isn’t the case right now for .fevs.

Great. As a programmer I would like to add one thing to the list which actually is of very great importance to us and that is a way of controlling data loading. I know that you have massive support in our classic API for this where it’s even possible to handle streaming of audio data. Now, the later isn’t really top priority but to be able to controll loading of data definatelly is in order to achieve optimal disc performance, mostly with respect to seeks. When it comes to streaming it would be nice if we could control when FMOD is allowed to access disc so we can sync with our data streamer.

You can already use EventSystem::getSystemObject() and then System::setFileSystem() to make the eventsystem use your file routines. We’ll also be adding a "load fsb" callback very soon which gives the programmer control of loading the fsb’s that the eventsystem requests. This way you can load the fsb’s however you like, precache them, load them from memory etc.

That’s pretty much what I wanted to hear I guess this means that for instance loading a project which today is blocking could be made non-blocking in our code provided that the filesystem we use will do the magic and that we add some wrapper code that handle that the project can’t be used before loading is complete.

We would still need to add a nonblocking flag for EventSystem::load on our end in order to have nonblocking project loads. The main benefit of overriding the file routines is so you can control fsb loading i.e. the big data stuff.

So if I call EventGroup::loadEventData I will only get a callback for readnig fsb’s, right? Would it be possible in the future to get callbacks for all data loading? What about controlling streaming? Can disc access be switched thru some callback or how do we do that?

So, right now if I use System::setFileSystem() to route all data loading to our routines then in the case of FMOD designer I won’t get any callbacks at all (apart from data streaming) until you have implemented support for this, right? When do you plan on implementing this?

No, System::setFileSystem() will catch all FMOD Ex and FMOD EventSystem disk accesses. This is implemented in the current version.

The fsb callback that I mentioned previously is something completely different than just overriding the filesystem using System::setFileSystem() and it is not implemented yet. We’re planning to have it implemented in the next couple of weeks.

To clarify, System::setFileSystem() is a low-level function that overrides ALL file operations. The "load fsb" callback will be a high-level callback that the user can register with the EventSystem. The EventSystem will call the callback with an fsb filename when it wants to load that fsb – the user can load that fsb however he likes – and then the user passes a pointer to the loaded fsb back to the EventSystem.

Thanks for clarifying the file i/o matters. I think I know what you mean now. When you add that loading-fsbs-seperatly function please make sure that it notifies the events that uses the sampledata so they can release their resources. In previous API’s I have worked with this hasn’t been very stable and has always caused crashes and I just don’t see why it has to be that way.