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

2023-12-05 22:10

本文主要是介绍技术解析:如何实现K歌App中的实时合唱,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

之前我们解析过很多社交直播App中不同场景的开发,比如在线K歌、小程序直播、多人视频聊天、AR等。

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

什么是实时合唱

现在大部分K歌应用中,都有“合唱”功能。用户点歌,然后开启合唱功能,自己一个人根据伴奏演唱,完成后点击“上传”,刚才录下的歌声就变成了带有一人歌声的伴奏。其它用户可以选择这个伴奏唱歌,录制完成后,间接的完成了合唱。简单来讲,就是做了两次“录制-上传”的操作。

这种“录制合唱”,并不是我们要做的“实时合唱”。

当然不可否认,从技术角度讲,录制合唱有其优点:

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

录制合唱的效果也完全取决于用户自身。其缺憾也显而易见,就是用户并没有“合唱”的体验,仍然是一个人在唱歌。

而我们要做的“实时合唱”的体验并非如此。实时合唱的流程体验如下:

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

在实时合唱的场景下,用户不再是一个人唱,而是在自己演唱的同时,可以听到好友合唱的声音。实时合唱能让用户像获得线下一样的体验,极大的提升沉浸感。

新场景带来的技术挑战

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

一、合唱同步

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

那么延时会带来多大的影响呢?为了方便大家理解,我们可以以一个非音乐科班生的角度简单计算一下。以歌曲《稻香》为例,它的钢琴曲谱是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。但是在国内有很多中小运营商,以及一些交叉的网络环境、跨国传输,那么延时会更高。

服务器间的延时

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

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

二、高音质

唱歌的人都有一个共同的心理需求,就是希望别人夸自己唱得好听。音质在合唱场景下就显得尤为重要了。而影响实时合唱音质的因素主要包括:音频采样率、码率、延时。

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

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

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

敲黑板:解题思路

之前我们提到,因解决方案的不同,“音频”有这不同的含义,这与你的实现逻辑有关。

1.音频=歌声+伴奏

在采集端,我们传输的音频如果是包括歌声与伴奏。那么就意味着是这样的逻辑,如下图。

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

在这种传输方式下,如果要保证 A 能听到合唱效果,会有两段“端到端延时”,即第2、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 源码。

这篇关于技术解析:如何实现K歌App中的实时合唱的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/459334

相关文章

网页解析 lxml 库--实战

lxml库使用流程 lxml 是 Python 的第三方解析库,完全使用 Python 语言编写,它对 XPath表达式提供了良好的支 持,因此能够了高效地解析 HTML/XML 文档。本节讲解如何通过 lxml 库解析 HTML 文档。 pip install lxml lxm| 库提供了一个 etree 模块,该模块专门用来解析 HTML/XML 文档,下面来介绍一下 lxml 库

hdu1043(八数码问题,广搜 + hash(实现状态压缩) )

利用康拓展开将一个排列映射成一个自然数,然后就变成了普通的广搜题。 #include<iostream>#include<algorithm>#include<string>#include<stack>#include<queue>#include<map>#include<stdio.h>#include<stdlib.h>#include<ctype.h>#inclu

【专题】2024飞行汽车技术全景报告合集PDF分享(附原数据表)

原文链接: https://tecdat.cn/?p=37628 6月16日,小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞,这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示,公司准备量产,并计划今年四季度开启预售小鹏汇天分体式飞行汽车,探索分体式飞行汽车城际通勤。阅读原文,获取专题报告合集全文,解锁文末271份飞行汽车相关行业研究报告。 据悉,业内人士对飞行汽车行业

【C++】_list常用方法解析及模拟实现

相信自己的力量,只要对自己始终保持信心,尽自己最大努力去完成任何事,就算事情最终结果是失败了,努力了也不留遗憾。💓💓💓 目录   ✨说在前面 🍋知识点一:什么是list? •🌰1.list的定义 •🌰2.list的基本特性 •🌰3.常用接口介绍 🍋知识点二:list常用接口 •🌰1.默认成员函数 🔥构造函数(⭐) 🔥析构函数 •🌰2.list对象

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全栈,前后端开发,小程序开发,人工智能,js逆向,App逆向,网络系统安全,数据分析,Django,fastapi

让树莓派智能语音助手实现定时提醒功能

最初的时候是想直接在rasa 的chatbot上实现,因为rasa本身是带有remindschedule模块的。不过经过一番折腾后,忽然发现,chatbot上实现的定时,语音助手不一定会有响应。因为,我目前语音助手的代码设置了长时间无应答会结束对话,这样一来,chatbot定时提醒的触发就不会被语音助手获悉。那怎么让语音助手也具有定时提醒功能呢? 我最后选择的方法是用threading.Time

Android实现任意版本设置默认的锁屏壁纸和桌面壁纸(两张壁纸可不一致)

客户有些需求需要设置默认壁纸和锁屏壁纸  在默认情况下 这两个壁纸是相同的  如果需要默认的锁屏壁纸和桌面壁纸不一样 需要额外修改 Android13实现 替换默认桌面壁纸: 将图片文件替换frameworks/base/core/res/res/drawable-nodpi/default_wallpaper.*  (注意不能是bmp格式) 替换默认锁屏壁纸: 将图片资源放入vendo

C#实战|大乐透选号器[6]:实现实时显示已选择的红蓝球数量

哈喽,你好啊,我是雷工。 关于大乐透选号器在前面已经记录了5篇笔记,这是第6篇; 接下来实现实时显示当前选中红球数量,蓝球数量; 以下为练习笔记。 01 效果演示 当选择和取消选择红球或蓝球时,在对应的位置显示实时已选择的红球、蓝球的数量; 02 标签名称 分别设置Label标签名称为:lblRedCount、lblBlueCount

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略

Kubernetes PodSecurityPolicy:PSP能实现的5种主要安全策略 1. 特权模式限制2. 宿主机资源隔离3. 用户和组管理4. 权限提升控制5. SELinux配置 💖The Begin💖点点关注,收藏不迷路💖 Kubernetes的PodSecurityPolicy(PSP)是一个关键的安全特性,它在Pod创建之前实施安全策略,确保P

金融业开源技术 术语

金融业开源技术  术语 1  范围 本文件界定了金融业开源技术的常用术语。 本文件适用于金融业中涉及开源技术的相关标准及规范性文件制定和信息沟通等活动。