对于任何项目，在开发过程中遇到性能问题都是很常见的。问题原因可能多种多样，但大部分情况下都和同时播放的声音数目直接相关。虚声部（Virtual Voice）只计算音量，而实声部（Physical Voice）则是完全进行处理的（包括流播放，解码，滤波等等）。比较理想的情况是能确保每个实声部都能听见并在整个声场中发挥作用。Wwise自身是不能做决定的，因为它不知道每个声音的意义。幸运的是，在声音设计过程中，你有很多工具可以进行这方面的管理。

实声部数量应该定为多少？

当然这是一个没有标准答案的问题，要看游戏所支持平台的最低配置，还有你的团队为声音分配的CPU预算是多少。尽管如此，还是可以列出一个大概的数字范围：

• PS4、Xbox One、PC、Mac：声道总数小于80
• Nintendo WiiU、Switch，以及高端Android和iOS：声道总数小于60
• 低端Android、iOS和PC（XP时代）：声道总数小于40

很明显，这些数量不是Wwise的极限，而且有些游戏能够支持更多声道。请注意我这里说的是“声道”而不是“声音”，因为一般来说，CPU占用会随着声道数的升高而增加（例如立体声的CPU占用是单声道的两倍）。但是以上参考数量可以作为一个大致起点，如果游戏设计允许的话就再增加。这些数字很大程度上取决于编解码类型，以及游戏同时处理的其它运算。大部分游戏的平均数量是比参考数量低的。数量越少越好，因为超过一定数量后，多个声音听起来就会变成杂音，声音整体质量就降低了。当然，有时声部数的峰值会超过这个数量，但只要不持续太久，声音引擎会迅速恢复，数量也会回复正常。应通过Playback Limits（回放限制）控制峰值数量，等会我们会说到这一点。

规划和原型设计

如果规划得当，从流程伊始就可以减少声部数量。应当评估特定游戏组件需要多少声部。别忘了乘上要使用该“组件”的游戏对象数。比如，一辆跑车9个声部没问题，但如果比赛时有20辆车，声部数会达到180个！

设计时，别忘了你不需要游戏也可以使用Profiler（性能分析器）。在屏幕顶端点击“Start Capture（开始采集）”即可。

这会非常有用，你可以一边构建声音结构，一边验证之前预测的数目并测试其表现。进行这样的原型测试时，请使用Soundcaster来触发多个声音，改变RTPC值并触发已有的其它Events，就像游戏中一样。得到的CPU占用并不表示最终性能，因为现在场景是在PC或Mac上运行，而不是最终的主机上。但是，你可以依靠声部数目和Effects数目来判断。而且可以想见，能使PC CPU降低的做法也会帮助最终目标平台降低CPU占用。你也可以在Performance Monitor（性能监视器）窗口中找到实声部数目（Physical Voice Count），如以下截图所示。

使用距离衰减

在游戏这种互动环境中，声音可能重复触发，累计起来就会让CPU（甚至是用户的耳朵）不堪重负。为了减少该情况，一种显而易见的方式就是避免播放距离太远的声音。要做到这一点，重要的设置有：

 

• 音量阈值 （Project Settings 即工程设置中）：这决定了声音在多大电平之下就被认为“听不见”了。该电平可能根据游戏所在平台而不同，但也取决于你的游戏类型。可以想想一款吵闹的FPS游戏与解迷游戏的区别。在嘈杂环境中，玩家不会发现缺失了某个-50dB的声音，而在安静点的游戏中他们就可能发现。在可以容忍的范围内，音量阈值应该尽可能高。一般来说将其设置在-96dB是不合理的。而且，对游戏进行最后优化的时候，把它调高几个dB能帮你获得几个宝贵的CPU周期。

• 虚声部行为（Advanced Settings即高级设置标签页中））：这指定了如果声音“听不见”时怎样处理它。没有特殊情况时，请设置为Kill if finite else virtual（如果不是无限循环则终止，否则设为虚声部）。假如声音并非循环播放，这样设置会终止它。

• 3D定位及衰减（Positionning即定位设置标签页）：这两个设置在控制声部数量时是共同作用的。可以预见，当发声体和听者互相远离时，音量会降低。之后，Volume Threshold（音量阈值）和Virtual Voice（虚声部）设置会接管不发声的声音，使其终止。

游戏中的大部分声音会通过这一机制进行筛捡。别忘了您也可以为不同的组件设置不同的衰减曲线，让其中一些提前终止。修改方法很简单，在Positionning（定位设置）中修改参数即可。

如果你觉得游戏中衰减范围有问题，可以使用Game Object Profiler（游戏对象性能分析器）（F12）并观察各个对象和它们的衰减范围。

低端平台版本

通常，性能瓶颈只有在性能最低的平台才会出现。幸运的是，Wwise对大部分属性有“Platform Link/Unlink（平台连接/断开）”功能。该功能允许为每个平台设置不同的值。而且，它允许排除整个声音结构或其中一部分。在用户界面中，寻找橙色的“胶囊”标识。右键单击选择 Unlink，取消与通用值的关联，然后进行更改。显示的属性值是当前平台的数值，可以在窗口左上角看到当前平台。

你可以通过Project菜单或Shift+Alt+P打开 Platform Manager（平台管理器） ，为低性能平台单独创建子平台。和Link/Unlink（连接/断开）功能一起使用，你可以轻松将设计中不太重要的部分排除，以此节省CPU周期。

基于RTPC的细节设计

任何游戏参数都可以用来增加或减少声音细节。在声音设计的各个环节都可以将RTPC关联到多个Switch Container或Blend Container。很明显，可以用内置距离RTPC来做到，虽然它和Attenuation（衰减）效果基本一样。但是，你可以使用Height（高度）来移除另一层楼的声音。或者可以制作一个Player vs Non-Player（玩家vs非玩家） Switch，为玩家相关的声音（而不是NPC声音）添加或移除细节。

为玩家和非玩家声音制作不同版本

减少声部的一个简单方法是为非玩家对象使用同样音频组件的简化版。比如，你有个“汽车”声音带有全部细节（引擎、涡轮、轮胎滚动、风声、悬挂等等），这个版本用于玩家Game Object（游戏对象），同时应该有一个简化版（只有引擎和轮胎）用于周围的NPC。这可以由两个不同的Event触发，或由一个Switch Container事件触发。这个方法简单，但不是任何时候都适用。结构复制，即使是在简化时，也可能导致在游戏制作过程中出现混淆和维护性问题。但它依然是简单情况下的可行解决方案。

如前所述，采用包含Blend Containes和Switch Container的唯一结构，然后启用/禁用子元素是完全可能的。这比复制一个结构要好，可以避免额外的维护。不要担心音频数据重复，因为Wwise能正确处理重复数据；在音频包中或流播放文件中可以只保留一个文件。

设置回放限制

如果有足够多的同类型声音在播放，Playback Limits（回放限制） 对于避免触发声音非常有用。比如在很多NPC到处走动的城市环境中，可能会有很多脚步声。当然，使用衰减会自动剔除那些远的声音。但还是会有很多声音在可听范围内，而玩家不需要听见100多个脚步声也能知道他们在人群中。要在可听范围内筛选，你会需要Playback Limit和Priority settings（优先级设置

有三个层级可以设置限制： actor-mixer、总线、或全局。

全局层级作为最后一道防线，可以保证整个游戏不会有多于允许的数目，这样遇到失控的游戏环节也不会占用全部CPU。全局限制是在Project Settings中的Max Voices Instances（最大声部实例）中设置，应该比你预期的峰值数目略高一点。

在Actor-Mixer或Interactive Music层级中任何对象的Advanced Settings标签页里，都可以为该对象设置限制。请注意，限制只针对声音数量，而非父级结构本身。比如，Random Container中含有三个变体，将容器的全局限制（相比游戏对象限制）设置为2，可以保证整个游戏中最多只有两个变体同时播放，但它不会限制触发的Event数目。在层级结构中可以设置多个限制，在脚步声层级的例子中，为顶端Actor-Mixer对象设置即可一步到位地限制所有地表材质子容器。

在Bus（总线）上也有Playback Limits设置，它们会限制总线输入的声部数量。为声音大类分配额度时，这会很有用。例如，在顶层SFX总线、VO总线和Music总线上设置限制，可以保证永远有足够空间容纳至少一条VO（画外音）和足够的音乐分轨。理论上，这会累加到全局限制上，但也不一定如此。

声音开始播放时，会对照Actor-Mixer、总线和全局的所有限制进行检查，只有每个层级都有余量时才会播放。

但只有数量限制的话，还是可能陷入意外的局面，重要的、近处的、更大的声音被终止，其它声音则继续播放。脚步声的例子就是这样。如果我们把脚步声限制为10个，那本来播放的声音中我们应该终止哪些？这个问题用Playback Priority（回放优先级）设置可以解决，更具体点说，是通过Offset priority by X at max distance（在最大距离时将优先级减小X）设置解决的。它在界面中不起眼，但可以在接近听觉半径边沿时，逐渐将优先级从指定的P降低到（P-X）。这意味着最远的声音会先被终止。

 

选择正确的编解码

声部之所以会占用大量CPU，主要是因为复杂编码的解压缩。使用的编解码格式及其设定会很大程度上影响CPU。最好的编解码器总是会平衡音频质量、CPU开销、文件大小、和流播放限制。在游戏中根据不同用途选择不同的编解码和设置是很明智的。比如音乐与画外音就有不同的带宽需求和限制。

最初，人们会倾向于注重质量，这也是有道理的！但选择正确的听感质量才能将CPU周期好钢用在刀刃上。根据经验法则，您可以将大部分“嘈杂”的声音（如爆炸、脚步、和撞击声）压缩得稍多一些，因为在这类声音中压缩产生的瑕疵并不会让用户的大脑觉得声音有“问题”。这对于大部分编解码都适用。很显然，应该先选几个代表性的声音来尝试这样的质量设置，然后再大批量应用。这些设置会有很大的影响，比如，Wwise中超高质量（Q=10）压缩的 Vorbis文件占用的CPU是同样文件低质量（Q=0）压缩的两倍。请注意这个编解码格式在2017版中还进一步优化过。

相比硬件编解码，软件编解码（PCM、ADPCM、Vorbis）有一个优势：它们在所有平台上工作方式都一样。文件大小和音频质量都一样，但很显然，CPU开销会不同。Vorbis通常比硬件编解码慢，但ADPCM可能更快些。当然了，PCM不算是编解码，所以CPU开销是最小的。

对于有硬件解码器的平台来说（PS4和Xbox One），别觉得这些编解码器是不需要处理资源的！在不同平台上，音频在解码器和CPU间来回传输时，内存总线或CPU可能阻塞，这会导致处理能力降低。但总的来说，这比更复杂的软件编解码器有优势。请注意，硬件编解码器可能在文件长度、循环点位置、或者提示点（Cue）上有进一步的限制，某些情况下将无法使用它们。

需要注意的是，即使有硬件解码器，IOS的AAC也不是作为通用编解码器的好选择。“iDevices”是作为音乐播放器构建的，所以只有一个足够优化的解码器，用于单个流播放的实时解码。Wwise会利用该解码器处理一个声音，但所有其它的声音都会软件解码，并且比其它编解码器要慢。 因此，为了最大程度地利用系统，请为同时只播放一条的声音种类使用ACC。如果你知道对话基本没有可能重叠的话，画外音用ACC是个不错的例子。

你可以在Profiler视图中监控每个编解码器的开销。在Advanced Profiler窗口中， Plug-ins标签页会展示所有插件的CPU开销明细。在Wwise中，编解码器也是插件，所以它们的占用也会显示在这个列表中。

结语

控制声部数是减轻CPU负荷的一条康庄大道。以上办法可能在某些情况下并不适用；但总体来说，使用这些方法会对你的游戏产生很大的影响。虽然在很多游戏中CPU占用取决于活跃声部数，但是还是会有很多其它性能缺陷。我们会在未来的博客中探寻其原因。