FMOD Engine User Manual 2.03
This chapter lists a number of common issues that can be encountered while working with the Core API and Studio API, along with techniques for overcoming them.
If you encounter a problem, and none of the techniques listed in this chapter help, post a question on the FMOD Forums for advice and support.
If you are finding the output of your application is starting to crackle or become distorted when playing for a long time, it is likely there are too many processes using up CPU usage. This can be due to too many large complex events playing at once, too many expensive DSPs in use such as convolution reverbs, or an excessive build up of events.
To visualize the audio CPU and memory usage of your application, you can record a Live Update profiler session in your FMOD Studio project, or if using the Core API only, utilize the FMOD Profiler provided with the API installation. This will assist in tracking down exactly where the resources are being used.
For Studio API users, some common issues that can cause a build up of events are:
This usually happens because the .strings.bank file has not been loaded. The error FMOD_ERR_EVENT_NOTFOUND would be logged to the game engine's debug logger. The .strings.bank file includes all the metadata required to look up events, buses, snapshots, and VCAs during runtime.
Refer to What Building Creates in the FMOD Studio User Manual, for more information on what a strings.bank file contains.
All Core API and Studio API functions return a FMOD_RESULT. This result is FMOD_OK if the function works as expected, or an error error code describing the problem. You can find a list of all possible errors in the documentation for FMOD_RESULT.
If further debugging is required, you can initialize the Studio API or Core API using the logging or "L" version of the respective library, i.e.: fmodstudioL.dll or fmodL.dll. To modify the amount of logging or the way it is displayed, see Debug_Initialize.
FMOD has an automatic device switching feature which is enabled by default.
A reason for this not to work is that an FMOD_SYSTEM_CALLBACK_DEVICELISTCHANGED callback has been registered. This callback disables the automatic device switching feature on purpose, as it assumes you will be controlling which device gets selected in the callback.
The Studio API and Core API return pointers to types. Some of these types are actually implemented as an underlying handle, but represent the handle data as a pointer type. For information about specific objects' underlying representation and lifetimes, see the Channel Groups and Routing section of the Core API Mixing and Routing chapter, the Initializing the Core API section of the Core API Getting Started chapter, and the Studio API Types section of this chapter.
All FMOD types, whether they are represented internally via pointer or handle, look like a pointer type. No matter the type, a null pointer can never be returned as a valid result, but it is not safe to assume anything else about the pointer value. Do not assume that the pointer value falls in any particular address range, or that it has any zero bits in the bottom of the pointer value address.
All FMOD types are equivalent for both the C and C++ API. It is possible to cast between the appropriate types by re-interpreting the pointer type directly.
Studio API types are returned as pointers, but actually consist of packed handle data. If the underlying type has been destroyed then the API returns FMOD_ERR_INVALID_HANDLE. An example of this would be unloading a Studio::Bank and then referencing a Studio::EventDescription belonging to that bank.