技术解析：如何实现K歌App中的实时合唱

以前咱们解析过不少社交直播App中不一样场景的开发，好比在线K歌、小程序直播、多人视频聊天、AR等。

咱们最近在知乎看到了一个问题「为何k歌软件始终没有开发出实时合唱功能？」，咱们只在知乎作了简要解读。在这里咱们详细来解析其中难点，以及实现的方式。

什么是实时合唱

如今大部分K歌应用中，都有“合唱”功能。用户点歌，而后开启合唱功能，本身一我的根据伴奏演唱，完成后点击“上传”，刚才录下的歌声就变成了带有一人歌声的伴奏。其它用户能够选择这个伴奏唱歌，录制完成后，间接的完成了合唱。简单来说，就是作了两次“录制-上传”的操做。

这种“录制合唱”，并非咱们要作的“实时合唱”。

固然不能否认，从技术角度讲，录制合唱有其优势：

• 音质好，开发者能够设置客户端录制和输出的采样率、比特率，保证用户的声音被原本来本地记录和传输；
• 对网络要求低，只有在上传和下载两个过程须要用到网络，合唱的混音在本地完成，所以不存在网络延时问题。

录制合唱的效果也彻底取决于用户自身。其缺憾也显而易见，就是用户并无“合唱”的体验，仍然是一我的在唱歌。

而咱们要作的“实时合唱”的体验并不是如此。实时合唱的流程体验以下：

• 发起人点歌，并发起合唱；
• 邀请好友进行合唱；
• 合唱伴奏经过网络同时发送给两位歌手；
• 两位歌手同时在线合唱，并能听到彼此的声音。

在实时合唱的场景下，用户再也不是一我的唱，而是在本身演唱的同时，能够听到好友合唱的声音。实时合唱能让用户像得到线下同样的体验，极大的提高沉浸感。

新场景带来的技术挑战

既然实时合唱更能给用户带来参与感，为何却不常见呢？与重复“录制-上传”的合唱不一样，实时合唱的体验给技术提出了更高的要求，主要包含两方面。

1、合唱同步

这里的同步指的是两个歌手的歌声与伴奏三者之间的同步。咱们先假设咱们的唱歌的两位用户都是专业级的，踩不许节奏的问题彻底不存在。如上述场景描述，因为伴奏是同时发送给两个用户，那么关键就在于二者的歌声是否能同步。影响合唱同步的主要因素就是延时。

那么延时会带来多大的影响呢？为了方便你们理解，咱们能够以一个非音乐科班生的角度简单计算一下。以歌曲《稻香》为例，它的钢琴乐谱是4/4拍，标准乐曲速度为80拍/分钟。副歌部分大约每一个音乐小节唱8到12个字，且主要以八分音符和十六分音符组成，基本上每一个音符对应歌词中的一个字。粗略计算的话，大约200 - 300ms左右唱出一个字。

不考虑伴奏的状况下，假设上图中的A和B之间的端到端延时为100ms。从声音传输流程上来讲：

A先唱，B听到A的歌声。此时产生100ms延时；

B在听到A的歌声后开始加入合唱，歌声传到A端。此时又产生100ms延时；

那么 A听到B的歌声永远延时200ms。根据以前唱每一个字所用时间的计算，听感上会至少慢半个字，是错位的。

若是要考虑伴奏的传输，以及伴奏与歌声的混音，状况将更加复杂。因此，实时合唱场景下的延时越低越好。通常端到端延时只要低于150ms，听者是感知不到的。因此唱《稻香》这种速度的歌，延时低于80ms能够完美合唱，演唱者的体验也是好的。若是唱更快速、歌词更密集的歌，延时要求更低，不然合唱时两人永远也对不许拍子，演唱者的体验也很是糟糕。

那么，如何下降延时呢？这个场景下的延时包括两部分：设备端的延时和端到端的延时，咱们须要针对不一样阶段的延时，来分析如何下降延时。

音频在采集端、播放端的延时

这张图咱们曾在《详解音视频直播中的低延时》中分享过。在这里，音频=歌声，或音频=歌声+伴奏。这取决于你如何传输歌声与伴奏，咱们在讲解解决之道时会详细说明。

设备端上的延时包括采集端的采集、前处理、编码，播放端的接收、解码、后处理过程产生的延时，以及两端在编码后和解码前产生端网络延时。

端上的延时主要与硬件性能、采用的编解码算法、音视频数据量相关，设备端上的延时可达到 30~200ms，甚至更高。

音频在设备端上的延时还能够细分为如下几点：

• 音频采集延时：采集后的音频首先会通过声卡进行信号转换，声卡自己会产生延时；
• 编解码延时：随后音频进入前处理、编码的阶段，若是采用 OPUS 标准编码，最低算法延时大约须要 2.5~60ms；
• 音频播放延时：这部分延时与播放端设备性能相关；
• 音频处理延时：先后处理，包括 AEC，ANS，AGC 等先后处理算法都会带来算法延时，一般这里的延时就是滤波器阶数；
• 端网络延时：这部分延时主要出如今解码以前的 jitter buffer 内。

另外，合唱场景一般会为用户提供各类KTV音效，即人声在编码传输前会增长一步前处理，这还会加大音频在端上的延时。

若想下降音频在端上的延时，就须要针对不一样机型进行编解码算法的优化，以下降音频采集、编解码、音频处理带来的延时。端上延时还与设备性能、系统紧密相关，若是歌手中有一方的设备性能较差，也会影响合唱效果。

端到服务器之间的延时

除了端上的延时，音频数据在端到服务器、服务器到服务器之间的传输过程也会产生较大延时，这也是阻碍“实时合唱”功能落地的重要因素。

影响采集端与服务器、服务器与播放端的延时的有如下主几个因素：客户端同服务间的物理距离、客户端和服务器的网络运营商、终端网络的网速、负载和网络类型等。若是服务器就近部署在服务区域、服务器与客户端的网络运营商一致时，影响上下行网络延时的主要因素就是终端网络的负载和网络类型。通常来讲，无线网络环境下的传输延时波动较大，传输延时一般在 10~100ms不定。而有线宽带网络下，同城的传输延时能较稳定的低至 5ms~10ms。可是在国内有不少中小运营商，以及一些交叉的网络环境、跨国传输，那么延时会更高。

服务器间的延时

在此咱们要要考虑两种状况，第一种，两端都链接着同一个边缘节点，那么做为最优路径，数据直接经过边缘节点进行转发至播放端；第二种，采集端与播放端并不在同一个边缘节点覆盖范围内，那么数据会经由“靠近”采集端的边缘节点传输至主干网络，而后再发送至“靠近”播放端的边缘节点，但这时服务器之间的传输、排队还会产生延时。

在实时合唱的场景中，要解决网络不佳、网络抖动，须要在采集设备端、服务器、播放端增设缓冲策略。一旦触发缓冲策略就会产生延时。若是卡顿状况多，延时会慢慢积累。要解决卡顿、积累延时，就须要优化整个网络情况。

2、高音质

唱歌的人都有一个共同的心理需求，就是但愿别人夸本身唱得好听。音质在合唱场景下就显得尤其重要了。而影响实时合唱音质的因素主要包括：音频采样率、码率、延时。

采样率：是每秒从连续信号中提取并组成离散信号的采样个数。采样率越高，音频听起来越接近真实声音。

码率：它是指通过编码（压缩）后的音频数据每秒钟传输所表示的数据量（比特）。码率越高，意味着每一个采样的信息量就越大，对这个采样的描述就越精确，音质越好。

假设网络状态稳定不变，那么采样率越高、码率越高，音质就越好，可是相应单个采样信息量就越大，传输时间可能会相对更长。也就是说，高音质也可能会影响延时。

敲黑板：解题思路

以前咱们提到，因解决方案的不一样，“音频”有这不一样的含义，这与你的实现逻辑有关。

1.音频=歌声+伴奏

在采集端，咱们传输的音频若是是包括歌声与伴奏。那么就意味着是这样的逻辑，以下图。

• 歌手A先得到伴奏；
• A 将歌声与伴奏在本地混音后传输给 B；
• B 根据A的音频进行演唱，这时 B 能够听到合唱的效果；
• B 将合唱后的混音传输给 A，A 就能够听到合唱效果了。

在这种传输方式下，若是要保证 A 能听到合唱效果，会有两段“端到端延时”，即第二、3步产生的。因为B听到的是A的歌声与伴奏，因此该方案能保证 B 的体验。但因为伴奏传输给 B，B 的歌声又须要再传输回到 A，A 听到的伴奏与B的声音其实之间有很大延时。若是按照上文的延时推断，你须要付出更多的努力，才能让端到端的延时下降到歌手A能接受的程度。

2.音频=歌声

在这里，并非说不要伴奏了。为了解决伴奏、歌声之间的延时问题，咱们还有一种方法，就是经过云端将伴奏同时传输给A和B，那么基本能够保证二者能在同一秒听到同一个音符。接下来要解决的就只是歌声的传输了。基本实现逻辑以下，也是咱们本身的实现方式：

• 声网从服务器或本地获取合唱伴奏；
• 声网经过 SD-RTN™ 将伴奏，实时同步发送给歌手 A 和 B；
• 歌手 A 和 B 会同时听到伴奏，而后根据伴奏开始本身的演唱；
• SD-RTN™ 会实时的将A的歌声传给B端，一样，B 的歌声也会被实时的传输到 A 端；
• 歌手A和B都能实时听到伴奏和对方的歌声；
• 同时，观众能够实时听到两个歌手的合唱效果。

这种实现逻辑的好处在于，A、B几乎同时听到伴奏，同时演唱，二者能够实时听到对方的声音。要解决的问题就是下降各自歌声传输到对方的这段端到端延时了。相对来说，更加简单。

如上文所说，咱们要作的就是优化编解码算法，并对各个机型进行适配。同时，优化网络传输策略，增长节点部署等。

你们能够尝试本身开发，也能够在声网开发者中心阅读咱们详细开发文档，获取咱们在 Github 开放的 demo 源码。