想象一下你正在开发一款具有音频监控系统的“秘密间谍”游戏：这个玩法系统能让你在世界中安插一个隐藏的麦克风。声音在窃听器或者虚拟麦克风的位置捕获并被无线传送到一辆监视车上。车里的玩家会实时听到被窃听房间内的动向。被麦克风捕获的声音会通过车内的“虚拟扬声器”播放。这个扬声器本身是一个虚拟世界中的空间化发声体—该音频的声音恰巧是关卡另一处发出声音的混音。我们甚至会将futz效果应用于这个混音，以便通过扬声器来模仿信号的低保真传输和失真。

Wwise 2017.1引入了这样的能力：在音频信号上对任意数目3D声源的输入进行混音，然后3D空间化。我们把这种“空间化子混音”叫做3D-Bus。本文将展示如何利用Wwise 2017.1中的3D总线来模拟游戏中的特定音频行为。我们选择了这个场景，因为它凸显了Wwise 2017.1设计工具和声音引擎中的几个新的特性和变更。在阅读后，您就能将这些概念应用于其他音频通路的场景，包括在文末要提到的那些。

游戏对象

在示例中，我们至少会注册4个游戏对象，在Wwise 2017.1中，听者也是游戏对象，而游戏对象可以既是听者也是发声体。

• 玩家听者（player listener）：这一游戏对象代表角色的耳朵，角色在聆听游戏中的音频。在示例中，这就是在车里听着实时监控的角色。
• 环境声发声体（environmental sound emitter）：在游戏中发出声音的对象。也许是一个敌人角色，或者其它对于我们秘密监听小队有用的发声对象。实际上，您的游戏中会有很多这样的对象一起组成一个丰富的环境，但在我们的示例中，简便起见只有一个对象。
• 麦克风（microphone）：这一对象代表放置的隐藏麦克风，也就是那个“窃听器”。这一对象的放置很重要，因为只有在听觉范围内（由它们在Actor-Mixer Hierarchy中的衰减曲线决定）的发声对象才能被“收录”，并对麦克风来说是有声音的。
• 扬声器（loudspeaker）：发出音频（由麦克风捕获）的空间化混音的发声游戏对象。扬声器的位置代表着声音被转接传输的点。在我们的示例中，扬声器是在一个离原始声源很远的监视车里。但是，如果它离原始声源足够近，则玩家听者能同时听到扬声器和原始声源的混音。

听者-发声体关联

听者发声体关联是通过使用SetListener和SetGameObjectAuxSendValues API 在代码中定义的。它们定义了游戏对象间的关系；也就是，哪个游戏对象会监听其它哪个游戏对象。在Wwise 中，区分发声体和听者游戏对象的唯一方法就是用听者-发声体关联，这个关联是用API在它们之间定义的。

在我们的示例中，我们定义以下的关联：

• 环境声发声体和扬声器的听者是玩家听者。
• 麦克风的听者是扬声器
• 环境声发声体 的听者是麦克风, 这个指派是使用SetGameObjectAuxSendValues API进行的。我们把它设置为一个“辅助发送”听者，这样我们就能在 Wwise 工程中专门指定一条总线来在Wwise Authoring工具中为麦克风的行为建模了。

您可以通过检查Advanced Profiler中的Emitter-Listener 选项卡，来确认您的发声体听者关联设置正确。 请注意，Environmetal_Sound_Emitter 的条目（听者为麦克风）表明了它是向麦克风总线发送的，并且通路类型为“游戏定义”。“游戏定义”的通路类型是指发声体-听者关联和输出总线是使用游戏定义的发送API来确定的。而另一方面，“用户定义”的通路类型指的是输出总线是由Wwise工程（在Master-Mixer Hierarchy中，输出总线是父级总线，而在Actor Mixer Hierarchy中，输出总线在General Setting选项卡里） 定义的。如果通路类型是“用户定义”，则Bus栏将会是空的，因为一个已知名称的对象有可能有任意数量的声部或总线，其中每一个都有工程（换句话说，就是用户）定义的独特输出总线。与“用户定义”通路类型相关联的听者游戏对象是由SetListeners API建立的——Wwise工程中无法建立发声体-听者关联。

https://blog.audiokinetic.com/working-with-the-new-3d-bus-architecture-in-wwise-2017.1-simulating-an-audio-surveillance-system/