Another way to reduce memory is to not load the entire audio file into the game system’s RAM all at one time. Instead, Streaming provides a way in which the audio can be played directly from the stored memory such as an optical disc or hard drive. This option provides game developers with another strategy for how they can manage memory. The use of streaming varies depending on the technical needs of each game, but streaming is particularly effective for large audio files that can be several minutes long, such as music. The downside of Streaming is that when the game engine calls for the sound, there may be a pause before the sound starts playing because it takes time to locate the file and begin the stream. This would not work well for a gunshot, but would be fine for things like continuously playing ambience or music. Another limitation of streaming is that there are technical limits to the total amount of data that can be read from the stream at one time and it’s possible that there’re other assets such as video that may be competing for bandwidth on that stream.
For the Platformer Game, streaming provides a way to reduce the Music SoundBank, which is quite big in size as well. Streaming the music is a great way to reduce memory usage and it does so without changing the sound quality.
In the Designer Layout select any Music Track within a Music Playlist Container. Look to the right at the Streaming Properties. (Pic01 Streaming Properties)
There are a couple of Streaming Properties to choose from. This is where you’d normally adjust the Parameters and values. Because the music of this game is split into several different Music Tracks, select all of them within the various Music Playlist Containers of the Music Switch Container.
After selecting all Music Tracks, right-click and click Show in Multi Editor. This is where you can adjust Streaming Properties for all selected Objects. (Pic02 Multi Editor)
Select the Is Streaming Enabled check box to enable Streaming. (Pic03 Is Streaming Enabled)
Other Streaming Properties appear, but it’s not necessary to change these unless you want to minimize the latency it takes to start the stream. Let’s look at the available Properties.
The Look-ahead time (ms) is the amount of time reserved by the Wwise Audio Engine to seek the Streaming Data. This time defines the latency of the track, which is by default 100 ms. This means that whenever the Event for playing music is fired by the game engine, the corresponding music will play 100 ms after the game call. If you check the Zero Latency option, the beginning of the streaming file is stored into SoundBanks. When you post an Event to play them, they start playing immediately using the data that was stored in the SoundBank (Prefetched Data). But if they run out of Prefetched Data before the following part of their file has been streamed from disk, Source Starvation occurs. In such a case, increase the Prefetch Length (ms). The Non-Cachable Property leaves no cache when streamed audio plays. This is good for long loops or non-recurring sounds that have no reason to stay cached in memory after completion.
To see the memory savings you have acquired by streaming, you need to generate SoundBanks in the SoundBank Layout.
Choose the SoundBank Layout and click Generate. Now look at the Data Size. (Pic04 Memory Savings)
You can see that streaming the music has had a significant impact as the Music SoundBank, which was over 14 Mb, is now under budget at less than 3 Mb. By simply enabling the Stream Property, on generation of the SoundBanks the sound will be stored in a .wem file next to the SoundBanks to be streamed in-game. (Pic05 .wem Streaming Files)