Source (streaming) starvation often sounds awful in interactive music, because tracks may become unsynchronized.
In the sound engine, streaming sources have implicit latency: they don't start playing until enough data have been streamed in. This latency is uncontrolled; it solely depends on disk speed bandwidth.
In the music engine, streaming sources are not allowed to have such an implicit latency. Music transitions are scheduled sample-accurately, so streaming sources need to be ready when asked to start playing. To overcome this, music tracks have a streaming look-ahead time property that is used to know how much time they should start reading sounds off the disk before they need to be heard.
The adequate value depends on disk bandwidth and required throughput (format, sample rate, number of tracks playing concurrently), so it is left to users to experiment. You may unlink it to use different values on some platforms, and you may also specify a global multiplication factor for this value through the SDK (see the AK::MusicEngine::Init() settings). On systems where I/O bandwidth is hard to predict (like Windows), you might even wish to expose this value to your players, so that those with slower drives may hear their music correctly.
The music engine needs to take the streaming look-ahead time into account when scheduling transitions. The synchronization point cannot be set before the destination's required look-ahead duration, therefore long look-ahead times generally result in slower transitions. The time constraint of the destination segment is the longest look-ahead time of all its streamed tracks, not the sum of tracks look-ahead times. Note that the presence or absence of audio clips inside these tracks is taken into account. The duration of the pre-entry may or may not be included in the constraint, depending on the transition rule.
In order to make your transitions "snappier", you may store track media in memory. If this is unacceptable for you, you may use prefetching: When you check the "Zero Latency" checkbox, the beginning of the audio file is stored in a bank. The amount of data that is stored is specified by the "Prefetch Length", which is similar to the look-ahead time. In fact, the difference between these two concepts is that the latter is a dynamic prefetching (read off disk at run-time), whereas the former is static (loaded in memory when loading banks).
Be aware of the following considerations when using Zero Latency with audio tracks:
- Prefetched data corresponds to the beginning of the file. If the source does not start at the beginning, then prefetched data cannot be used.
For example, if you lay down an audio clip at the beginning of the pre-entry, but a transition rule specifies that the pre-entry should not be played back, then the file will start playing at the position where the entry cue is located. In such a case, prefetched data is useless, so dynamic prefetching (look-ahead) will be used. This is why the look-ahead time is always specified for streamed tracks, even when you check "Zero Latency".
- The look-ahead time at the segment level is the longest of all tracks. If one track uses prefetched data, and another one does not, then your transitions will not be faster. It is probably useless to use prefetched data in such a case.
