Streaming and Latency

Hello!

It has generally been my understanding that for sounds that require precision timing and minimal latency, the Stream load setting is best avoided.

However, I have some questions about the details of streaming latency, in case it is useful for an edge case that requires minimising memory use.

In this forum post, @joseph said:*
“Streaming assets incur around 85.3 ms of additional latency due to the need to buffer the stream.”*

and in this one, that it is “…impossible to pre-load streaming assets or schedule them to play with sample-accurate timing.”

So I have two main questions about this:

  1. Is the latency for streaming applied to only the playing of the asset, or the entire event? A couple of examples of what I mean:

    • In the case of a timeline which has two assets lined-up to start at the same time, where one asset is being streamed and the other pre-loaded, will these two assets play perfectly in sync with each other?
    • In the case where multiple streaming assets are lined up to start at the same point on an event timeline, will they play perfectly in sync with each other?
  2. Can the streaming buffer be “primed” by starting to stream a sound and then pausing it, allowing it to be resumed later without the latency incurred by initialising the streaming buffer?

I’ve been having a discussion about this with some other technical sound designers who also aren’t certain about it, so I would really appreciate an explanation of how streaming behaviour functions at this level for our collective enlightenment!

Thanks,
Zander

Hey Zander,

To answer your questions in order:

In both cases, both instruments will be scheduled to play at the same time. If the stream takes longer to ready for playback than the non-streaming asset, the latter will be delayed to match the former.

Technically yes, although you would need to use the API to pause the event instance, and not a sustain point. Loading stream sample data is handled on demand i.e. when the instrument falls within the scheduling window the stream is created. In the hypothetical case where you’d “prime” the stream, what you’d essentially be doing is pausing while the stream is within the scheduling window, which would allow the stream’s buffer to be filled, and then unpausing afterwards. To do this, you’d likely want to start the event instance and hook into the instance’s callback to pause the event once FMOD_STUDIO_EVENT_CALLBACK_STARTED or FMOD_STUDIO_EVENT_CALLBACK_SOUND_PLAYED fires, depending on how the event is set up.

With that said, a more effective way of reducing scheduling delay for streams would likely be to modify FMOD_STUDIO_ADVANCEDSETTINGS.streamingscheduledelay using Studio::System::setAdvancedSettings.