本文内容由“微信多媒体团队”整理发布。
1、引言
广州TIT创意园，这里是腾讯在广州的研发团队所在地，LiveVideoStack采访了微信多媒体内核中心音视频算法高级工程师梁俊斌（Denny）。从华为2012实验室到腾讯，过去十余年梁俊斌一直专注在音频技术。他告诉LiveVideoStack：音频技术还有许多难点需要解决，而作为技术人也延展到应用场景，关注用户需求。本文整理了本次访谈的主要内容，仅供参阅。
学习交流：
- 即时通讯开发交流3群：185926912[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-1828-1-1.html）
2、相关文章
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
Q：Denny你好，先简单介绍下自己的经历，从学生时代到进入职场，过去这段时间的一些关键的经历，以及现在主要做哪些方面的研究？
梁俊斌：现在是2018年，二十年前（1998年）我考进华南理工大学，直到2007年这9年都在华南理工大学完成我的本科、硕士、博士的学业，期间跨越了好几个不同的学科和技术领域，包括机械、电子、自动化、人工智能，这些不同的学科跨度还是蛮大的，和其他的音频同行有不同，他们一开始在学校就专攻音视频多媒体、编解码算法。我在大学期间，在音视频领域是没有较多的积累，只是基本了解一点，实际接触不多。
2007年，从华南理工大学毕业之后加入了华为公司，进入了“2012实验室”多媒体工程能力中心，在这里我开始踏入语音频领域，并从此锁定了自己的职业道路方向，到现在我还在持续做语音相关的技术。期间有过一些其他部门的同事邀请我转行，但我拒绝了，我坚信要做自己认为正确的事情，就必须破釜沉舟把它做深做透。音频这个行业还有很多很不成熟的东西，可能从外界普通用户的角度来说，我们这块已经很成熟了，没什么可做的，但实际上（语音）还有很多尚未解决的难题，需要有人来做。
后来我进入了腾讯公司，加入了微信团队。微信给我最大的触动就是所有人都在用，这种空前的成就感是不言而喻的，所有的亲戚朋友都在用，要是自己做不好的话，尤其是语音通话、语音消息每天都在用，哪天不小心出点Bug，就会影响到很多很多身边的人，所以在享受微信工作带来的满足感的同时做技术每个环节都要求非常严谨。
华为最为神秘的“2012实验室”（据说研究的都是各种黑科技）：
华为的“2012实验室”是华为的总研究组织，据称，该实验室的名字来自于任正非在观看《2012》电影后的畅想，他认为未来信息爆炸会像数字洪水一样，华为要想在未来生存发展就得构造自己的“诺亚方舟”。
华为2012实验室的主要研究的方向有新一代通信、云计算、音频视频分析、数据挖掘、机器学习等。主要面向的是未来5-10年的发展方向。华为官方数据显示，2015年，华为研发投入为596亿元人民币，占2015年销售收入的15.1%，近十年来，华为已经在研发方面投入了超过2400亿元人民币。
2012实验室的二级部门包括：中央硬件工程学院、海思、研发能力中心、中央软件院。今天着重讲述华为很少对外公开，但在2012实验室里有着极高战略地位的研究部门。
Q：音频这个领域，在外人看来已经没有什么可做的，无外乎就是语音，不像视频各种新鲜的产品，360度视频、VR等。那么，音频这块到底还有什么挑战？我们外行所不知道的？
梁俊斌：语音通话是两个或多个人在不同的地点通过手机或者说其他终端完成对话的过程，这里涉及到通话的外界声学环境因素，包括噪声、回声，混响，所有这些环境因素都会影响对方的收听效果，而不同场景环境下问题现象差异较大，如何有效解决这是一个方面。
第二方面，微信是一个超十亿级用户的APP，其中的音视频通话功能是最基础的，我们每天都有几亿人在使用这个功能，这里涉及成千上万款不同厂家不同型号的手机（当然还有PC、Mac等设备），其不同硬件有不同的声学特性，例如频响、不同设备的内置硬件处理后的噪声、杂音等，也有操作系统非实时性的问题，还有各种APP的音频资源冲突等各种状况，我们都需要做相应的适配和有针对性的优化。
另外，网络传输可靠性是非常关键的部分，网络传输存在丢包、抖动、时延等问题，网络越复杂问题更多。语音包到达对方终端后解码、播放。声音传入耳朵的过程是心理声学感知的过程，你能不能感知的到对方传递的声音信息，信息是否干净且易懂。声音传递到大脑，其中的关键信息是否让你有深刻印象还是听了就忘没有痕迹，这些都是很值得研究的课题。而我们微信技术架构部多媒体内核中心自主研发的WAVE（微信音视频引擎）组件正是围绕上述问题不断迭代、持续改进优化，构建高可用性的互联网音视频通话技术基石。
行外人不了解这些细节问题，所以才觉得没什么可做的，然而这个细节问题是必须有人做的，而且需要长期的一丝不苟的投入。做一个能通话的APP不难，但做一个超十亿级用户都认可的通话功能是不简单的。
Q：微信做到这个量级，已经不仅仅是做一个简单产品的问题了，而是要对用户负责，因为这个可能会影响到很多人工作和生活。
梁俊斌：是的，这是一个系统工程，而不仅是一个安装在手机上的应用软件，需要涉及通话双方端到端一环扣一环的质量监控和故障应对体系。我们每天都会积极搜集用户的反馈信息，深入具体case去分析通话问题的原因，尽我们所能帮助用户解决问题。
此外我们拥有功能强大的后台运维系统，该系统能实时对大盘通话质量做端到端的分析，对异常情况会及时报警，保障通话功能的正常使用。虽然微信通话是免费的，但我们身上的责任是巨大的，我们微信技术架构部多媒体内核中心每个同事每天都在为提升改进用户音视频通话体验而不断努力。
Q：在互联网上丢包、抖动是不可控的，需要来应对。另外，如何更清晰和深刻的传达信息，可能涉及到心理学，耳朵的结构特性，这些能简单讲一讲吗？
梁俊斌：是的，互联网是相对不可靠的，在WAVE引擎里面提供了适配不同网络传输特性的抗丢包、抗抖动算法和机制，让通话过程语音更顺畅。
心理声学是研究物理声学与人类听觉感知之间关系的一门边缘学科，心理声学其中一个基本特性就是掩蔽特性，其又分为时域效应和频域效应，这里我们侧重在频域上的掩蔽效应，常规情况下相邻频带能量强的会屏蔽掉能量弱的频带，在通话应用中，例如降噪算法，我们会通过降低噪声频点能量至掩蔽值以下来降低噪声对人耳感知的干扰，同时减少对正常语音的损伤。
除此以外，心理声学还应用到很多技术点上，这里就不一一细说了。
Q：一般我用微信开电话会议会用耳机，用耳机相当于就没有回声了，基本上就可以把回声消除掉了？
梁俊斌：部分手机在耳机模式下由于声屏蔽设计所以基本没有回声，但也有些手机在耳机模式下还是有可能产生回声的，可能是电耦合的电学回声，因为这里耳机产生的回声的线性度比较高，相对声学回声的非线性度高而言是比较容易通过AEC抵消抑制的，所以常规情况下你通过耳机接听基本没有回声问题。
什么是AEC？
AEC是回声消除器（Acoustic Echo Canceller）技术的简称, AEC是对扬声器信号与由它产生的多路径回声的相关性为基础，建立远端信号的语音模型，利用它对回声进行估计，并不断地修改滤波器的系数，使得估计值更加逼近真实的回声。然后，将回声估计值从话筒的输入信号中减去，从而达到消除回声的目的，AEC还将话筒的输入与扬声器过去的值相比较，从而消除延长延迟的多次反射的声学回声。根椐存储器存放的过去的扬声器的输出值的多少，AEC可以消除各种延迟的回声。
Q：其实我们要做得事情是非常多的，设备不断更新。网络情况可能网络会越来越好一点，5G移动网络稳定性会高一点。
梁俊斌：从5G的设计目标是高带宽低时延，但目前还没真正商用，对此我还是有点保留的，因为频率越高传输的距离越有限，网络覆盖应该更小，最终的网络质量还要跟基站建设密度相关，要是做得不好的话，对我们音视频通话是一个挑战。由于纯语音通话本身所占带宽有限，5G的影响相对来说还不是很大，对于视频通话体验应该是有提升的，当然带宽越大、时延越低，我们可以做得技术可以更多。
另外通话双方使用的如果是不同网络或者不同运营商网络，如何适配和确保数据的连接的可靠性，正确性、低时延，这些是比较重要的。
关于移动弱网的文章，可以读一读以下几篇：
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
Q：您从华为开始进入音频领域，我相信这个过程中也有其他的机会和诱惑，为什么还会专注在音频这个领域？相对来说，多媒体技术就已经很窄了，音频会更小众，更孤独。
梁俊斌：刚才提到“孤独”这个词很准确，为什么呢？搞技术的人就必须习惯孤独，享受埋头钻研的“孤独”带来的愉悦，技术人经常面对挫折而无助的局面，每一次失败的尝试让我们感受到了冰冷的绝望，但内心的光明指引着我们砥砺前行。
为什么选择音频？刚开始接触音频的时候，我觉得音频技术可操作性很强。相对于以前在学校里面做的很多底层芯片相关的项目，DSP、ARM、MCU、FPGA等，需要借助别人的专用平台，在别人提供的最小系统板上或自己设计的PCB上开发，硬件制（电路）板周期长。如果工厂制板工艺环节出现什么问题，例如PCB层间有金属丝残留导致短路或不稳定状况，返工还要考虑外面制板工厂的工期以及芯片供货周期，有时候芯片要从国外申购就要等好几周的时间。
而做音频则方便多了，很简单，只要你有一台PC或者手机，你就能录音，你就能做处理，你就能马上听到自己做的东西的效果，整个过程完全可以自己掌控。而且在华为、腾讯公司能够提供相当不错的大平台和优越环境，让我可以沉下心来搞音频，所以我就一直坚持下来了。
Q：我也观察到一个现象，搞多媒体这些技术人，大部分还比较低调的，专注在自己手头的事情，这个可能也跟这个行业对人的修炼有关系吧。
梁俊斌：（搞多媒体开发）就是要不断的积累，积淀越深厚才能看得更高更远。
那时候我在华为做了几年的管理之后反思，因为在大公司里面做管理，大部分时间都是被支配的，没有太多的时间可以专心做自己想做的事情。后来自己就做了决定，还是全身心投入到技术研发，做自己想做的事情，这个是最理想的状态。
Q：音频技术的发展方向在哪里？比如和AI技术的结合。
梁俊斌：我在学校的时候就开始接触AI的理论和算法，例如神经网络、无监督学习和有监督学习等，那时候的机器比现在差太远了，更没有适合并行运算的GPU，跑不了很复杂的东西，耗时很长，而且没有现在那么开放的数据库可供训练，所以当时的AI理论技术没能得到长足发展，也没有成功的实际应用。回到现在，过了那么多年后，以前冷门的技术现在变成热门了。现在AI和语音结合得比较紧密，语音识别、声纹识别、语音合成、AI降噪等等，但处理及存储的开销、时延问题，以及AI算法在实际运行中如何做到可观可控等问题还有待进一步解决。
你提到音频这一块是不是越来越小众了？当下看到的感觉是越来越小，但我们要看未来（的应用）。
目前我们只是做了单声道、双声道的通话应用，未来必然是沉浸式的虚拟现实音视频体验，随着传感器工艺升级，设备体积进一步微型化，网络管道的海量带宽支持，未来我们将可以非常自由的体验与现实世界无异的虚拟现实世界，这里运用到的3D立体音频动态建模，实际环境声场与虚拟声场的融合交互技术。
另外，随着便携传感器的普及，AI对个人和群体的数据分析，AI会比我们自己更了解自己，例如AI根据外界环境状况、个人喜好、当前身体的各项检测指标判别你当下的情绪和心理状况，可以为你提供更适合当前个人心情、场景环境的音乐，让你身心更愉悦或者让你的情绪得到更有效的宣泄。现在也有一些主动降噪的音效设备，放在床边，能够主动抑制你的打鼾的声音，让你和家人能够睡得更好，这些都是音频技术可以看到的未来。
不要局限在自己所做的事情，技术可以在不同的应用场景上得以延展，不同应用场景反过来决定了需要什么样的技术，什么样的算法。所以我并不觉得我们没什么事情可做了，只有我们没有把场景和用户需求理解到位，这反而是我们担心的。倘若我们对用户需求都不理解，对使用场景不理解，那我们确实没什么可做的。如果我们搞清楚了用户的应用场景，我们才能开发出相应的技术，并告知用户这个技术特性是你所需要的。所以要吃透分析用户场景和需求，肯定会有很多事情需要我们做的。
Q：我的体会是这样，我在用英语流利说学英文，非常大的一个难点，就是我在地铁和公交车上，噪声很大，这个时候我说同样的话，评分就会比安静的环境低很多，他没办法根据环境去适应。如果通过阵列麦克风这样的硬件可以做到降噪，但是普通的手机是没办法实现的。
梁俊斌：一般人只有两个耳朵，如果播放单声道音源的时候，你可以理解人只用了一个耳朵，因为他两个耳朵听到的东西是完全一样的。
人在听单声道的信号的时候，单个耳朵就能抽取出自己感兴趣的内容，而忽略干扰信号的部分，这就是鸡尾酒会效应，即在一个很繁杂的环境里人都能快速捕获自己想听的内容。
相比之下，我们目前还需要借助多个麦克风组成阵列，通过阵列算法来增强某个方向的信号衰弱其它方向的信号，如果需要角度分辨度更高，或者立体空间某个角落的声音信号则需要更加多的麦克风和更复杂的阵列布局。
所以这个领域的研究就很有趣了，单个人耳完胜我们目前商用的麦克风阵列。很多大牛都在研究这个，还没有完全攻克，如果这个问题解决了，那普通手机只需要一个麦克风就可以实现人耳相近的效果了。
什么是麦克风阵列？
麦克风阵列(Microphone Array)，从字面上，指的是麦克风的排列。也就是说由一定数目的声学传感器(一般是麦克风)组成，用来对声场的空间特性进行采样并处理的系统。采用该技术，能利用两个麦克风接收到声波的相位之间的差异对声波进行过滤，能最大限度将环境背景声音清除掉，只剩下需要的声波。对于在嘈杂的环境下采用这种配置的设备，能使听者听起来很清晰，无杂音。
附录1：更多音视频技术文章
[1] 开源实时音视频技术WebRTC的文章：
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
《了不起的WebRTC：生态日趋完善，或将实时音视频技术白菜化》
>> 更多同类文章 ……
[2] 实时音视频开发的其它精华资料：
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
《实时视频直播客户端技术盘点：Native、HTML5、WebRTC、微信小程序》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
>> 更多同类文章 ……
附录2：QQ、微信团队的技术分享
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：Android版手机QQ的缓存监控与优化实践》
《微信团队分享：iOS版微信的高性能通用key-value组件技术实践》
《微信团队分享：iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的？》
《腾讯技术分享：Android手Q的线程死锁监控系统技术实践》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
《腾讯TEG团队原创：基于MySQL的分布式数据库TDSQL十年锻造经验分享》
《微信多媒体团队访谈：音视频开发的学习、微信的音视频技术和挑战等》
《了解iOS消息推送一文就够：史上最全iOS Push技术详解》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1828-1-1.html）