Looping "daisy chain" playlist overhead?


#1

I’ve tried making ‘equipment handling rattle’ type sounds by cutting handling sounds into tiny little short bits that I load into a Multi-Sound playlist and set the playlist to loop, so that those short sounds play one after another in random order over the length of the trigger region.

Just wondering… does this kind of daisy chaining of sounds cause extra overhead, if the samples are very short and rapidly play one after another? How far is it feasible to go? (for example, divide a diesel engine sound into single cycle wavelengths? Too fast, too much?)

We’ve had one odd case of one such sound getting orphaned and ending up playing forever on a console. It was a high overhead situation overall with lots of physics happening, and it’s only happened once so far. But still, just checking.


#2

There shouldn’t be any problem with using extremely short assets in looping multi instrument playlists. FMOD Studio’s scheduler is able to handle it.

I haven’t been able to reproduce the “orphaned sound” issue that you describe. Is there any more information you can give us about the circumstances in which it occurred?


#3

Thank you for the verification. Is there any difference in performance between playing a single looped sample vs daisy chained samples from the playlist? What happens if the Multi-Sound is pitched up a lot, will it cause buffer read issues if the scheduler has to jump between samples?

That “orphaned sound” was a freak incident, it only ever happened once. I’ll check if there was any more to that incident than just overall heavy overhead on the game side (combat taking place, lots of physics, projectiles and visual effects occurring simultaneously).


#4

Is there any difference in performance between playing a single looped sample vs daisy chained samples from the playlist?

Assuming all the samples are all the same length and set to a loading mode other than streaming, playing a daisy chain of samples will require more audio assets to be loaded into memory. Since you’re using extremely short samples, however, the added cost is not likely to be significant. (It’s unlikely that you might try using streaming loading mode for this use-case, as it’s the exact opposite of the situation that loading mode is designed for; I mention it only for completeness.)

What happens if the Multi-Sound is pitched up a lot, will it cause buffer read issues if the scheduler has to jump between samples?

No buffer read issues. The scheduler takes care of it.

The scheduler is so called because it schedules changes in advance, so as to ensure each new audio file is loaded and able to start playing at the exact right moment, instead of having to wait for update() to be called. It achieves this by predicting what is about to happen, based on the current state of the project: If it can see that a looping multi instrument playlist is going to finish playing its current playlist entry within the next few milliseconds, it selects the next playlist entry and schedules it to start playing at the appropriate moment. If it sees that that playlist entry will finish playing too, it selects the next entry and schedules that to play a little further in the future, and so on. This allows you to do things that would otherwise be impossible… Such as playing hundred of tiny audio files in rapidfire succession without noticeable gaps or seams. (Scheduling things in advance does mean that there’s technically a tiny amount of latency between making a real-time change and that change being applied to the audio, but it’s negligible under most circumstances.)

There is one potential performance-related issue that might result from using tiny audio files in a looping playlist: Each new audio file played by a multi instrument counts as a voice from the moment it is scheduled. Most multi instruments’ audio files are are longer than the scheduler delay, so this isn’t significant - but if your audio files are shorter than the scheduler delay, you may find that the instrument consumes more voices than other instruments while playing.