共计 1703 个字符，预计需要花费 5 分钟才能阅读完成。
导读：随着古代社会生存形式变动，社交娱乐的形式也在逐步扭转。传统面对面的社交娱乐活动正在逐渐改革，越来越多的交互行为逐步转移到网络上。RTC 技术的提高也推动了网络娱乐模式的变动，单方向信息传递形式如电影、听歌、看视频为主的娱乐形式占比在降落，互动性更强的形式如互动直播、语音通话、在线 KTV 歌等却在逐渐崛起。
音频解决的必要性
作为人类最重要的交换形式之一，声音的解决至关重要。一方面是因为人类对于声音极其敏感，声音的流传受人体生理构造特点的影响，因为视觉受限于光照和方位，不是时刻能够依赖的信息获取起源，很多状况下听觉成为人类对环境信息感知的最重要通道。另一方面声音脱离画面独自存在的交换形式也有独立利用的场景。
RTC 互动交换性能作为极其重要的性能，对音频通话的解决提出了以下要求：
- 超低延时，实时互动零距离
- 超高的通话质量。回声、噪声等影响听感的因素需妥善处理，使通话过程无烦扰
而社交娱乐的特点对音频解决又提出了新的要求。如用户心愿失去 高质量的音乐、好的临场感、趣味性强的音频成果、高质量音频内容共享 等方面。因而，这就要求咱们须要从不同的方面去优化音频，以达到最优成果。明天咱们分享的就是音频共享。
音频共享的概念
音频共享个别是指将设施中音频声音共享给其余参与者，使单方可能听到同一种声音，如一起听歌等。
通话中的用户听到雷同的声音，在某些状况下对于用户的临场感晋升很重要。有一种间接的形式是能够 从麦克风通道让对面的用户听见本端的声音，但很多时候这样的成果不会太好。采集播放环节的失真，麦克风通道针对人声的特定解决都可能会毁坏高质量音频的成果。
提供一个 绕过前端解决环节并且灵便不便应答各种场景的音频共享性能 就变成了事实需要。
网易云信音频共享的实现计划
为了满足用户多个场景下对音频共享的需要，网易云信实现了应用灵便的音频共享计划。
这里提供了多种共享声音起源。能够应用 源文件 ，当然也包含 网络音频源。
通过内置解码器解码后混音，能够兼容常见的 Mp3，AAC 等多种格局数据文件，这是最简略常见的一种形式。
当用户对第三方软件播放的声音很喜爱时怎么办？咱们 基于零碎接口提供了播放数据的抓取和解决，让用户不必苦于无奈获取数据源，使得音频共享的起源更加多样化。
这里的架构和常见的 RTC 架构仿佛有些许不同之处，不光减少了一个 回声打消模块 ，参考信号的起源仿佛也有变动。这就是这个架构非凡的中央，上面一个回声打消模块用于根本通话， 因为共享的声音同时要被本人和对方听到，麦克风采集到的声音里也可能会蕴含这部分信号，须要打消的局部不仅要包含对端的声音，还要包含本端播放的声音。
这里取用理论播出的信号作为参考输出，能够保障本端人声输出更洁净。另外一个额定的回声打消用于打消对端的人声。在 应用第三方播放声音作为共享源的时候，咱们拿到的信号蕴含了播放的全部内容。这样的解决能够在共享源中打消掉对端声音，使得共享过程中仍能保障高质量的音频通话。
音频共享的利用场景
上述音频共享计划是一个对立架构，能够用于 游戏开黑、音频分享、线上 KTV 等场景。涵盖了娱乐办公的多个场景。
有了这个根本解决框架当前，就能够通过灵便设置外部流程，配合适当的内部逻辑实现各项性能。以下图为例：
把下面的第三方音频内容换成游戏、音乐播放器或者浏览器，就能够通过简略操作实现游戏开黑、一起听歌、会议等音频共享场景了。
如果感觉这个例子有些简略，那么以下是一个在线 KTV 独唱实现的例子。
左侧是主唱端，提供伴奏音乐，在本地的人声退出后，通过 RTC 音频流传给副唱。
右侧的演唱者的声音会通过 RTC 流传给主唱，以供两人独唱同步，同时将副唱的人声和主唱侧传过来的蕴含主唱人声的歌曲混合，造成残缺的独唱，推送给直播观众。
以上是一个在线 KTV 的场景实现。当然，在线 KTV 场景的实现波及多个方面，遇到的问题远远不止音频共享这部分。歌词的传递、各端的同步、音频端到端的延时等问题都是须要克服的阻碍，解决好这些问题能力提供更好的体验
总结
网易云信的 SDK 产品提供残缺的音频共享解决方案，反对双声道全频道，能够笼罩包含游戏开黑、一起听歌，在线 KTV 等一系列场景。如有趣味能够登录网易云信官网下载 Demo 进行体验。
