Whether an asset should be set to stream is a question of resource availability and allocation.
Each currently-playing streaming asset requires constant file I/O (which is to say, access to the disk) and a very small amount of memory; whereas assets with other loading modes require much more memory but only require file I/O when they’re first loaded, and only require these resources once, no matter how many instances of the asset are playing.
File I/O is a very limited resource on most platforms, and is used for many things other than audio. Fortunately, most games load much of their content into memory up-front at the start of new levels and areas, and many users do not run applications that access the disk in the background. This means that there are usually periods when the player’s device is not otherwise loading content from disk, meaning that streaming assets that play in those periods can enjoy uncontested and uninterrupted file I/O. By contrast, a streaming asset that plays while the disk is being accessed regularly by anything else may not be able to access to disk frequently enough to refresh its ring buffer, and so may suffer from buffer starvation. Buffer starvation of a streaming asset manifests as the sound stuttering or stopping entirely.
The streaming loading mode is therefore best used for assets that meet the following conditions:
- The asset would take up an awkwardly-large amount of memory if fully loaded.
- Few instances of the asset ever need to be playing at the same time.
- Few or no other streaming assets ever need to be playing at the same time as the asset.
- The asset only plays at times when the game does not need to read or write much to the disk on which the asset’s bank is stored.
The first point is why assets longer than ten seconds are set to stream by default, but the other points are all dependent on details of your game’s design that FMOD Studio has no way of knowing about. If you know that a given asset does not meet those criteria, you should set it to not stream.
For example, you’ve mentioned that you have many looping sounds that are likely to play in parallel. Playing a large number of streams (or a large number of instances of the same stream) at the same time is a bad idea, since every concurrently-playing instance of a streaming asset requires constant file I/O for as long as it plays, and forcing a large number of assets to fight for disk access can easily result in one or more of them suffering from buffer starvation.
Music assets, by contrast, are a good choice of asset to make streaming, as such assets tend to be large, and it’s rarely necessary to play more than one or two music assets at a time.