最近，我有机会设计了一个小型音频模块，用于以空间为主题的WebVR仿真。
许多人不知道浏览器是否支持一套出色的工具来创建和转换音频文件。
我们希望我们的太空模拟尽可能地身临其境。 用户体验全都与沟通有关。 我们需要沉浸式音频来匹配我们的VR。
让我们看看如何仅使用浏览器为星际无线电传输创建沉浸式音频！
这就是我们原始，干净的音频听起来像的。
这就是我们完成后的声音！
在本文中，我们将重点关注正确的音频。 稍后，我将分享如何使用Google Daydream控制器来创建出色的身临其境的体验，使玩家感到自己正在使用真正的科幻Commlink！
增加延迟
首先，我们需要使音频感觉像是经过了很长一段距离。 毕竟，您在太空中。
一个明显的选择是WebRTC（实时通信），我最初尝试过。
WebRTC可能很挑剔。 对于无线电传输来说，这也感觉太迫切了。 连接后，浏览器将向其他用户发送连续的音频流。
消息不是离散的。 他们不觉得自己从卫星上反弹了。
为了发出离散消息，我们向Google Daydream控制器添加了即按即说功能。
握住控制器的用户将按住按钮来记录消息。 一旦他们释放了按钮，该消息即被确定并发送给其他用户。 它使控制器感觉像是科幻通信链接。 WebRTC非常适合流媒体播放，但不适合一键通。
与其使用WebRTC，不如考虑Google的Firebase之类的数据库解决方案。 Firebase是一个快速，实时的数据库，可以从Google仪表板进行监视。
每次用户记录一条消息时，我们都会将其转换为二进制字符串，并将其发送给Firebase。 另一个用户使用Firebase侦听器检查数据库中是否出现了任何新消息。
一旦新消息出现在云中，Firebase就会自动将其发送给其他用户。 尽管这可能不是 Firebase的常见用法，但我们对结果感到满意。
通过这种方式发送音频具有两个很酷的优点：
- 它比WebRTC慢。 因此，它有机地引入了用户录制音频的时间与其他用户收到音频之间的延迟。
- Firebase将两个用户发送的所有消息都记录在易于使用的小型音频文件中，而不是连续WebRTC流的大量记录。 由于播放器是通过一键通录制的，因此我们服务器上的所有音频都是信号，而不是WebRTC流中的大量死音或噪音。
正宗的广播音频
对于沉浸式体验，我们无法获得WebAudio通常提供的水晶般清晰的音频。 我们希望我们的无线电传输听起来像来自阿波罗太空任务的经典音频。
为了获得这种效果，我使用了Tuna.js，这是包装WebAudio API的音频处理库。 原始的WebAudio API具有转换音频所需的一切：过载，滤镜和大量其他效果。 但是像Tuna.js这样的库使您的生活更加轻松！
WebAudio API使用一系列连接的节点来处理音频。 您可以定义所需的节点，然后将它们链接在音频源和播放已处理音频的音频上下文之间。 这是一个很好的入门指南。
我使用了过滤器和超速档。
带通滤波器可删除您定义的频段之上和之下的频率。 这会“挖空”声音，使其更接近收音机的有限范围。 然后，我通过过载节点为音频添加了光失真。 这使音频变得粒状且松脆。
过度驱动音频后，信号有点响。 我使用了增益节点来降低音量。
这是处理音频的模块。
最后的润色
我们已经准备好进行最后的润色。 音频现在听起来不错。 让我们在每次无线电传输的末尾添加著名的quindar哔哔声，以表示消息已结束。
此功能处理我们无线电广播的音频播放。 它由完成工作的子功能组成。
我们从Firebase转换原始数据，然后使用我们定义的Tuna.js / WebAudio节点链处理音频。 然后，我们使用audioContext播放转换后的音频。
音频源播放完毕后，我们的事件监听器（“ onended”）将触发DOM中的一个单独的音频节点。 这个音频节点保存着一个小文件，上面有NASA著名的Quindar蜂鸣声。 当我们的信息播放完毕后，将发出Quindar哔哔声。 好戏开始！
就是这个步骤。 如果您有任何疑问，请告诉我。
