During cook, we compress the audio files using a codec appropriate for your platform. Then depending on your Sound Groups, when we load the sound, we either decompress the whole thing on load or we decompress in real-time.
Real-time decompression will only decompress the parts of the sound necessary for uninterrupted playback–this means that most of the sound (probably) is compressed in RAM.
Decompress (or Decode) on Load decompresses the entire sound on load, which means it sits fully decompressed in RAM.
Streaming means that the sound will only load from disk the parts necessary for uninterrupted playback. This frees up RAM on long sounds which would otherwise be Realtime Decoded, but puts strain on your disk I/O as you’re constantly loading the next bit off of disk during playback.
The way to think of the impact they have on your resources is something like:
Streaming: Continuous demand on your Disk I/O (especially when you have a lot of streaming sounds at once), Continuous demand on your CPU for decoding, Very Good on RAM, May be significant latency on initial playback.
Realtime Decode: Momentary demand on your Disk I/O (when it first loads the compressed version), Continuous demand on your CPU for decoding, Good on RAM, May be some latency on initial playback
Decode on Load: Momentary demand on your Disk I/O (when it first loads the compressed version), Momentary demand on your CPU (when it first loads), Not Good on RAM, No-to-Low latency on initial playback
Usually Decode on Load is used for things that are time critical like footsteps or guns.
Streaming may be used for background ambient beds or background music, as often times they are not time critical and they tend to be very long.
Realtime decode is a kind of compromise between the two.
We are actively working toward a new and improved paradigm for memory management, so definitely stay tuned. Until then, this is the gist of the legacy approach to memory management.