在网络游戏中，无论是大逃杀、棋牌类、电子竞技类还是娱乐休闲类小游戏，玩家和玩家之间的互动和语音聊天都是一个必不可少的环节。作为一个通用的技术需求，如果由游戏厂商自己从零开始研发相应的音频技术，既不经济也不具备技术优势，因此市面上有一些厂商提供第三方的游戏音频SDK，让游戏开发商免于重复造轮子的同时，能把更多时间花在提升核心竞争力上。
GME游戏多媒体引擎由腾讯多媒体实验室（即原音视频实验室）提供基础技术方案。腾讯多媒体实验室前身是QQ音视频团队，依托QQ的海量用户平台，在音视频网络通信、音视频直播、图像处理和音视频处理等技术领域积累了十几年的技术和实战经验。「腾讯云大学」邀请腾讯云GME专家工程师 王文涛老师 分享关于“腾讯云GME技术方案介绍”课程的内容。
GME游戏多媒体引擎，主要由实时语音，离线语音与语音分析三大功能模块组成。
实时语音主要解决游戏中两位或多位玩家能够在游戏内通过语音进行沟通的问题。GME的实时语音功能针对不同的游戏类型或者游戏场景有不同的优化：对于时效性要求比较高的游戏比如FPS类游戏，GME提供低延迟的普通音质；对于K歌类游戏，则支持高保真的语音音质；此外对于类似国战等游戏场景则提供十万人超大语音房间满足游戏的语音沟通需求。
离线语音实现类似微信的语音消息功能，为游戏玩家提供了异步化的消息沟通方式。同时，还支持语音转文字功能，并支持多达120种语言。
语音分析功能，主要为游戏开发者和游戏运营方提供各种不良信息的筛选和过滤，维护游戏内生态良性发展。
此外GME还提供一些特色功能，包括：趣味变声、K歌伴奏和3D方位语音。
GME 实时语音提供超低时延、流畅优先的实时语音对讲，适合MOBA中游戏的语音开黑。GME提供的高清音质实时语音，则很适合语音直播类App；此外，GME提供的混音伴奏功能，为线上卡拉OK功能提供了很好的支持；3D语音特效也支持棋牌类游戏，狼人杀以及大逃杀类游戏中听音辨位的能力。
接下来我们将详细介绍一下游戏实时语音引擎。在介绍游戏实时音频引擎之前，先简单介绍一下数字信号是如何传输的。
如图中的数字传输系统模型所示：信源，对我们来说即麦克风采集到声源数据，一般这里会转换为数字信号，接下来经过编码，再经过调制解调通过网络传输到对端，再通过解码后，投递到信宿，就通过扬声器或者耳机等设备将声音渲染出来。几乎所有的音频传输系统都是基于这个模型进行，包括我们将要介绍的游戏实时音频传输引擎。
这其中有个非常重要的编码环节。编码的目的在于减少传输码率和存储量，以提高传输和存储的效率，同时可以在进行编码的同时结合一些音频处理的能力。我们举个例子：1分钟，采样频率为44100Hz,采样深度为16bits,双声音Wav文件大小：60*44100*2*2约10M的数据，经过Mp3 128kbps压缩后：128*60/8=约0.94M,压缩后只有原来10分之一不到。
这里又区分为信源编码和信道编码。信源编码，主要解决有效性问题，通过对信源的压缩、扰动和加密等一系列处理，力求用最少的码率传递最大的信息量，使得信号更易传输和存储。
信道编码，主要解决可靠性问题，即尽量使得处理过的音频信号在传输过程中不出错或者少出错，甚至能对出错进行检测和纠正。
在信源编码中又可以细分为语音或者人声编码，以及音频或者音乐编码。两者针对的分别是人类的两个声音器官即嘴和耳朵，分别对应发音模型与听觉模型进行编码设计。语音编码包括Speex、ISAC以及Silk编码，而音频编码常见的有Celt和AAC等。
信道编码也比较多：比如线性分组码，卷积码，Turbo码，LDPC码以及RS编码等。而且信道编码不只是应用到音频数据传输，其他类型的数据传输也是可以应用到。
实时音频引擎就是在数字传输系统的模型基础上，使用之前提到的音频编码以及音频的特别处理过程构建起来的。实时语音引擎的主要目的是采集发送端用户的音频输入，经过处理和编码后通过网络传递到接送端，并对音频数据进行还原，最终通过扬声器等设备播放出来。
所以一般的语音引擎的一般架构如图所示：通过麦克风等音频采集设备，将声音等模拟信号采集成数字信号；同时，在游戏或者k歌中，我们可能还需要将本地的一些媒体文件与上述用户声音进行混音后进行网络传输，为了能将音频数据传输到对端，需要进行音频编码；端接收到数据之后将对数据进行还原，并通过外放设备进行播放，就完成了整个语音引擎的处理流程。
游戏实时音频需要解决实际应用场景以下几个问题。
首先，回声消除问题，在游戏实时语音过程中，特别是手机场景下，手机的麦克风和扬声器距离较近，导致麦克风不仅采集到近端玩家说话的声音，也同时采集到手机扬声器播放出来的其他玩家的语音，以及游戏自身的背景音乐等声音。这里，麦克采集到扬声器播放的声音称为回声。实时语音通话时，需要消除这种回声，保留纯净的近端讲话人语音，然后传送到对端。对一个至少混合了两个声音的声音流，要把它们各自分开，然后去掉其中一个声音（回声），难度何其之大。就像一瓶蓝墨水和一瓶红墨水倒在一起，然后需要把红墨水提取出来一样，所以回声消除被认为是音频处理中最难的技术之一。
其次，噪声抑制问题也是游戏语音引擎需要解决的一大难题。一般传统社交语音类app通话场景中，通话者一般会选择相对安静的场所，说话也相对比较正式和清晰。而游戏开黑时，玩家所处在商场、大街和地铁等各种嘈杂的环境都有。并且，玩家在玩游戏时说话聊天声音比较随意。此外，双手操作游戏过程中，也容易堵住手机上下端的麦克风拾音孔，游戏过程中游戏本身也伴随背景音效，各种原因导致手机麦克采集到的语音信噪比（近端采集信号和噪声信号能量之比）会很低。因此，要保证游戏语音通话清晰流畅度，游戏场景中的实时语音通话，比一般常规网络社交软件语音通话对于语音引擎具有更高的要求。
再次，还有啸叫问题，我们一般都会对采集到的、比较小的声音做增益处理。如果声音播放端与采集端物理距离比较接近，播放出的声音又被采集进音频信道，进而一并做放大处理，就形成正反馈效应，会听到声音越变越大、越变越尖锐。
此外，为了能更好的对用户的声音进行增益处理以及编码，减少不必要的数据传输，我们只对讲话时进行采集，这就需要检测人声，进而引入人声检测功能。
以上是游戏实时前端的情况，接下来介绍一下后台。
游戏实时音频引擎的后台需要能支持鉴权，转包，流控，转码以及统计等功能。针对大规模音频服务的后台，还需要能支持高并发，低延迟，以及服务的健壮性，弹性可伸缩安全性等。同时为了满足国内外客户的需求，需要能有全球链路保证所有用户都能就近接入。
对于一个游戏实时音频来说，评判其好坏的质量指标包括：音质、延时、码率、频谱、性能和网络抗性。音质一般分为主观评测和客观评测，客观评测可以使用音质测试的专业设备测试端到端音质，并进行打分。使用音质测试设备测试端到端延时，延时越小越好。
GME的整体结构和应用如图所示。GME作为一个整体，由客户端的SDK以及对应的语音后台，存储后台以及识别后台等构成。
GME实施游戏音频引擎的流程：
1. 采集播放：声音信号从麦克风采集、模拟放大、ADC变换得到数字信号进入语音前处理环节。
2. 音频处理：其中包含了回声消除、噪声抑制、音量自动调节、啸叫抑制等等，混音模块混入伴奏 。
3. 进行音频编码以及信道编码，包括包头和FEC编码，主要解决网络抗抖动抗丢包处理。
4. 通过网络接口发送数据。
5. 接收端从网络层收到数据包，按用户id分流为多路不同的数据流，每条数据流都有解码链来处理（包含FEC解码、包头解码、Jitter缓存区中缓存）。
6. 外放设备播放解码后的PCM音频流
7. 为了做回声抑制，会有一路解码数据从播放端传递到回声抑制模块，为回声抑制模块提供参考信号。
从上述介绍中我们可以看到，针对回声消除算法模块需要获得音频渲染端的一个参考信号作为基准。而在实际处理工作有很多工程类问题需要解决：比如在回声消除算法在处理语音信号过程中，面对现网中各种各样手机机型，手机硬件差异较大，特别是有些手机采集语音非线性失真大，且硬件处理效果不佳。即使是硬件较好的手机，在网络不稳定或本身系统CPU资源被其它线程占用时，也会导致采集和播放之间会产生相对延时变化等情况。这些都会造成回声消除算法中线性自适应滤波器的发散，导致经过线性滤波后回声残余依旧很大。
而GME中的回声消除算法模块通过大量验证数据，自适应地解决回声消除线性处理部分，改进了残余回声估计，同时对延时跟踪，双端检测，近端语音存在概率方面做了重新精心打磨。在游戏背景音回声大、手机采集线性失真严重、延时抖动等常见的恶劣场景，缓解了回声残余的问题，且保持良好的近端语音通话质量。其他诸如人声检测，啸叫抑制，噪声抑制等方面，GME提供了基于传统的和基于场景的深度学习算法来解决上述问题。
在网络传输阶段，主要需要解决抗抖动，抗丢包等问题。抗丢包，主要是自适应重传策略，或者冗余编码等方式解决。控制播放延时，通过拉升、加速算法来趋近于目标网络抖动延时，处理过程中不丢弃数据包，减少语音卡顿(整个过程要尽量确保有数据播放)，解决抗抖动问题。这需要大量的测试获得对应的算法参数，而GME也利用了网络实验室的损伤仪，网络模拟器等硬件设备，针对不同场景获得算法参数，并在诸如QQ等腾讯系产品上进行大规模验证。
GME的实时音视频后台大体上分为三个模块：接入层，控制层和数据层。
接入层主要负责对接不同的类型的客户端设备，并对接入客户连接做负载均衡，以及作为安全门户等作用。控制层则主要提供控制信令，包括转包，策略，配置以及统计计费等。而数据层则主要对音频数据进行处理，包括传输或者代理用户的音频数据，并做转码，扫描等。
特别说明一下，这里有H5的接入，因为浏览器的一些能力限制，能支持的RTC功能相对能力较弱，为了能浏览器接入实时语音，同时又不对既有的后台架构做重大调整和适配，所以我们将部分功能移到后台来实现，相当于后台有一个浏览器的代理，接入GME的实时音频后台，进而完成对h5浏览器的实时语音支持。
之前提到了实时语音对延迟要求很高，而腾讯云基础网络设置也很好的支持GME的能力，包括基础设施、网络接入和服务承载方面。
为了保证服务质量，GME后台也支持实时用户数据监控，保证对突发问题能及时预警或者对资源进行自动扩容。
GME构建了一整套质量测试平台，进而对音频质量以及稳定性做出持续的监控。使用思博伦POLQA音质测试设备测试端到端音质。使用全频带音乐样本作为数据，和Adobe Audition查看输出频谱。使用思博伦POLQA音质测试设备测试端到端延时。ios和PC使用wireshark，android连接root手机使用tcpdump命令抓包。以语音样本作为输入，通过损伤仪增加网络损伤。
GME在不同场景下提供不同的音质体验和不同的抗网络损伤技术，实时语音音质在网络无损的场景下的平均MOS分达到4.38（满分5分），平均延时低于200ms；通过先进的丢包恢复技术、丢包补偿算法以及优秀的网络抗性，即使在50%以上丢包、1000ms的网络抖动下，也能保持顺畅的沟通和很好的音质。例如MOBA类游戏中，在保证正常的语音沟通和良好的性能前提下，移动网络模式每分钟流量消耗低于500KB，CPU占用率平均在10%以下等。
在fps类游戏中，枪声、脚步声音效的方位一向是高端玩家非常重要的辅助信息，但当玩家打开游戏内置实时语音功能时，这些为了沉浸体验专门制作的游戏音效会丢失或减弱，整个游戏音质进入到“打电话”级别。原因是一般手机都分为媒体音量和通话音量，媒体音量是为了听音乐等使用的，采样率较高，音质效果较好，但没有音频处理比如回声消除等；通话音量主要为了打电话用，采样率比较低，只保证能听清楚人生，且为了解决回升消除问题，系统提供了回升消除算法。
在我们的场景中，游戏为了高质量音质，使用了媒体音量，但开通实时音频后如果继续用媒体音量，虽然保留了较好的游戏音质，则会有明显的回声，高噪声等问题；所以一般游戏开了实时音频后都会切换到通话音量，利用系统的3A处理来解决回升噪声等问题，但负面效应就是游戏音质下降。所以GME与Wwise提出了联合解决方案，在保证媒体音量的前提下，在实时语音中增加3A算法保证实时语音效果。