Source starvation（源干涸）与内存优化思路
当流数据未在规定截止时间内发送到 Stream Manager 时，就会发生源（I/O）干涸。
产生原因：
wwise工程设置问题：
互动音乐：Interactive Music 层级结构的流对象在事先预定，需要流数据及时准备就绪。此预读时间为每个音乐轨的属性。如果互动音乐发生干涸，可能是因为您指定的 Look-ahead Time（预读时间）不够大造成的。
零延迟流：如果您在声音和音乐轨属性中选择“Zero Latency”选项，流文件的开头将存储在 SoundBank 中。发布播放事件时，会使用存储在 SoundBank 中的数据（预取数据）立即开始播放。但是，如果在文件的后续部分从磁盘流播放之前就已经处理完预读数据，即会发生源干涸。在这种情况下，请增加预读长度。Actor-mixer（角色混音器）层级结构中，未标记为“零延迟”的声音绝不会在达到其目标缓冲长度之前开始播放。达到目标缓冲所需的时间即为声音的初始延迟。因此如果这些声音发生干涸，可能是由于 I/O 条件有误或失衡造成的。
I/O 设置问题：https://www.audiokinetic.com/zh/library/edge/?source=SDK&id=streamingmanager_tips.html
内存优化思路
从wav文件本身入手
编码格式
采样率
声道数：双声道的体积是单声道的两倍，因为双声道的声音发送到左右两个扬声器的信号是不同的。
弃用没必要的文件。
启用流播放：不把整个文件一次性加载到游戏系统的内存中。直接从存储介质播放音频。（缺点：不适用于即时切换的声音，适用于较长的声音如环境音与音乐。）
细分Soundbank。
业务逻辑层面：使用AkBank组件中的Save decoded bank选项，当对Soundbank解码时，它会将解码后的Soundbank资源保存在本地DecodedBanks文件夹中，以便下次加载时，不用额外对资源进行解码，这种方法对使用了Vorbis高压缩的编码格式效果显著，前提是对游戏解包安装后的本地存储容量无要求。
