CN118113249A - 一种音频数据处理方法、相关装置、设备以及存储介质 - Google Patents

Abstract

本申请公开了一种音频数据处理方法、装置、设备及存储介质，应用场景至少包括各类终端，如：手机、电脑、车载终端等。本申请方法包括：获取来源于第一对象的第一语音数据；响应于第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息；根据场景关联信息，获取针对第一语音数据的第一调整数据，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项；采用第一调整数据，对第一语音数据进行处理，得到第一音频数据；实现对第一音频数据的播放。本申请将语音组件插件化之后引入到终端本地的音频引擎中，从而为开发者提供了设计沉浸式语音的工具，由此，实现跟随场景变化的沉浸式语音效果。

Description

一种音频数据处理方法、相关装置、设备以及存储介质

技术领域

本申请涉及多媒体技术领域以及云技术领域，尤其涉及一种音频数据处理方法、相关装置、设备以及存储介质。

背景技术

游戏社交化是近年来游戏行业发展的重要趋势，实时互动的实现和社交平台的能力是游戏社交化的两大关键。随着游戏语音越来越普及，游戏内的语音交流已成为玩家们的刚需。无论是交友还是沟通游戏内的战术内容，语音交互都起到了关键的作用。

为了在游戏中加入语音能力，在业界通用的相关技术中，开发者单独接入语音平台即服务(Platform as a Sevice，PaaS)提供的软件开发工具包(Software DevelopmentKit，SDK)，通过SDK提供的基础应用程序编程接口(application programming Interface，API)实现各种游戏内语音的业务场景。

发明人发现目前的方案中至少存在如下问题，由于语音SDK接入方案是独立于游戏音效设计的。因此，游戏的语音逻辑和处理脱离了游戏场景，导致提供给玩家的语音体验千篇一律，限制了语音体验。针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种音频数据处理方法、相关装置、设备以及存储介质。通过将语音组件插件化之后引入到终端本地的音频引擎中，从而为开发者提供了设计沉浸式语音的工具，由此，实现跟随场景变化的沉浸式语音效果。

有鉴于此，本申请一方面提供一种音频数据处理方法，应用于第一终端，包括：

获取来源于第一对象的第一语音数据；

响应于第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，第一虚拟对象为第一对象控制的虚拟对象，场景关联信息包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

根据场景关联信息，获取针对第一语音数据的第一调整数据，其中，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，音频属性参数用于对语音数据的播放效果，伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

采用第一调整数据，对第一语音数据进行处理，得到第一音频数据；

实现对第一音频数据的播放。

本申请另一方面提供一种音频数据处理装置，应用于第一终端，音频数据处理装置包括：

获取模块，用于获取来源于第一对象的第一语音数据；

获取模块，还用于响应于第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，第一虚拟对象为第一对象控制的虚拟对象，场景关联信息包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

获取模块，还用于根据场景关联信息，获取针对第一语音数据的第一调整数据，其中，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，音频属性参数用于对语音数据的播放效果，伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

处理模块，用于采用第一调整数据，对第一语音数据进行处理，得到第一音频数据；

播放模块，用于实现对第一音频数据的播放。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于通过音频输入设备采集来源于第一对象的原始语音数据；

对原始语音数据进行语音前处理，得到第一处理语音数据，其中，语音前处理包括降噪处理，回声消除处理，音量均衡处理以及啸叫抑制处理中的至少一项；

对第一处理语音数据进行音频帧转换处理，得到第一语音数据，其中，音频帧转换处理包括采样率转换处理，声道转换处理、采样深度转换处理以及音频帧长处理中的至少一项。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

获取模块，具体用于对第一处理语音数据进行音频帧转换处理，得到第一音频帧序列，其中，第一音频帧序列包括至少一个第一音频帧；

对第一音频帧序列进行采样，得到每个第一音频帧的第一采样点数据集合，其中，第一采样点数据集合包括M个采样点数据，M为大于1的整数；

将每个第一音频帧的第一采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第二采样点数据集合，其中，每个第二采样点数据集合包括N个采样点数据，N为大于1的整数；

根据至少一个第二采样点数据集合，生成第一语音数据，其中，第一语音数据包括至少一个第二音频帧，每个第二音频帧对应于一个第二采样点数据集合。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，场景关联信息包括位置信息，第一调整数据包括音频属性参数；

获取模块，具体用于根据位置信息确定第一虚拟对象在虚拟场景中的空间类型；

若空间类型属于第一空间类型，则确定针对第一语音数据的音频属性参数包括混响调整参数，其中，第一空间类型表示在虚拟场景中小于或等于空间尺寸阈值的虚拟空间；

若空间类型属于第二空间类型，则确定针对第一语音数据的音频属性参数包括回声调整参数，其中，第二空间类型表示在虚拟场景中大于空间尺寸阈值的虚拟空间。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，场景关联信息包括环境信息，第一调整数据包括伴随音频数据；

获取模块，具体用于若环境信息指示第一虚拟对象处于室内环境，则确定针对第一语音数据的伴随音频数据包括基于室内环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于户外环境，则确定针对第一语音数据的伴随音频数据包括基于户外环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于天气环境，则确定针对第一语音数据的伴随音频数据包括基于天气环境录制得到的音频数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，场景关联信息包括情绪信息，第一调整数据包括音频属性参数；

获取模块，具体用于若情绪信息指示第一虚拟对象处于第一情绪状态，则确定针对第一语音数据的音频属性参数包括时域调整参数、第一频域调整参数以及升调调整参数中的至少一项，其中，时域调整参数用于提高语音音头，第一频域调整参数用于增强语音高频分量；

若情绪信息指示第一虚拟对象处于第二情绪状态，则确定针对第一语音数据的音频属性参数包括语速调整参数以及周期调整参数中的至少一项，其中，语速调整参数用于减慢语速，周期调整参数用于周期性地改变语调；

若情绪信息指示第一虚拟对象处于第三情绪状态，则确定针对第一语音数据的音频属性参数包括第二频域调整参数以及降调调整参数中的至少一项，其中，第二频域调整参数用于增强语音数据的低频分量。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，场景关联信息包括角色信息，第一调整数据包括音频属性参数；

获取模块，具体用于若角色信息指示第一虚拟对象属于目标角色类型，则确定针对第一语音数据的音频属性参数包括音高调整参数、音色调整参数以及共振峰调整参数。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，第一调整数据包括音频属性参数以及伴随音频数据；

处理模块，具体用于采用音频属性参数，对第一语音数据进行调整，得到目标语音数据；

对目标语音数据进行语音后处理，得到第二处理语音数据，其中，语音后处理包括语音增强处理，频段增益处理以及调音处理中的至少一项；

将伴随音频数据与第二处理语音数据进行叠加，得到第一音频数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

播放模块，具体用于响应于音频播放操作，通过音频输出设备播放第一音频数据。

或者，

播放模块，具体用于向第二终端发送第一音频数据，以使第二终端通过音频输出设备播放第一音频数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

播放模块，具体用于获取语音场景类型；

若语音场景类型属于第一场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为单声道的音频数据，且，第一音频数据采用第一采样率；

若语音场景类型属于第二场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为立体声道的音频数据，且，第一音频数据采用第二采样率，第二采样率高于第一采样率。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

播放模块，具体用于对第一音频数据进行分帧处理，得到第二音频帧序列，其中，第二音频帧序列包括至少一个第三音频帧；

对第二音频帧序列进行采样，得到每个第三音频帧的第三采样点数据集合，其中，第三采样点数据集合包括P个采样点数据，P为大于1的整数；

将每个第三音频帧的第三采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第四采样点数据集合，其中，每个第四采样点数据集合包括Q个采样点数据，Q为大于1的整数；

对至少一个第四采样点数据集合进行音频帧转换处理，并向第二终端发送处理后的第一音频数据，其中，第一音频数据包括至少一个第四音频帧，每个第四音频帧对应于一个第四采样点数据集合。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，音频数据处理装置还包括接收模块；

接收模块，用于接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

播放模块，还用于播放第二音频数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

播放模块，具体用于对第二音频数据进行分帧处理，得到第三音频帧序列，其中，第三音频帧序列包括至少一个第五音频帧；

对第三音频帧序列进行采样，得到每个第五音频帧的第五采样点数据集合，其中，第五采样点数据集合包括X个采样点数据，X为大于1的整数；

将每个第五音频帧的第五采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第六采样点数据集合，其中，每个第六采样点数据集合包括Y个采样点数据，Y为大于1的整数；

对至少一个第六采样点数据集合进行音频帧转换处理，并播放处理后的第二音频数据，其中，第二音频数据包括至少一个第六音频帧，每个第六音频帧对应于一个第六采样点数据集合。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

接收模块，还用于接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

获取模块，还用于响应于第二音频数据，根据第一虚拟对象与第二虚拟对象在对虚拟场景中的位置信息，获取对象关联信息；

获取模块，还用于根据对象关联信息，获取针对第二音频数据的第三调整数据；

处理模块，还用于采用第三调整数据，对第二音频数据进行处理，得到第三音频数据；

播放模块，还用于播放第三音频数据。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

播放模块，具体用于对第三音频数据进行分帧处理，得到第四音频帧序列，其中，第四音频帧序列包括至少一个第七音频帧；

对第四音频帧序列进行采样，得到每个第七音频帧的第七采样点数据集合，其中，第七采样点数据集合包括S个采样点数据，S为大于1的整数；

将每个第七音频帧的第七采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第八采样点数据集合，其中，每个第八采样点数据集合包括R个采样点数据，R为大于1的整数；

对至少一个第八采样点数据集合进行音频帧转换处理，并播放处理后的第三音频数据，其中，第三音频数据包括至少一个第八音频帧，每个第八音频帧对应于一个第八采样点数据集合。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，

接收模块，具体用于基于数据传输策略，接收第二终端发送的第二音频数据，其中，数据传输策略包括前向纠错策略、丢包补偿策略、自动重传策略以及缓存抗抖动策略中的至少一种，前向纠错策略用于纠正数据传输过程中出现的错误码，丢包补偿策略用于补偿缺失的音频帧，自动重传策略用于请求重传音频帧，缓存抗抖动策略用于在数据传输过程中采用动态缓存。

本申请另一方面提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述各方面的方法。

本申请的另一方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各方面的方法。

本申请的另一个方面，提供了一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述各方面的方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请实施例中，提供了一种音频数据处理方法，响应于获取到的第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，该第一虚拟对象为第一对象控制的虚拟对象，场景关联信息包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项。然后，根据场景关联信息，获取针对第一语音数据的第一调整数据。于是，采用第一调整数据，对第一语音数据进行处理，得到第一音频数据。由此，可实现对第一音频数据的播放。通过上述方式，将语音组件插件化之后引入到终端本地的音频引擎中，能够把语音数据直接送入到音频引擎中进行处理。即，根据虚拟对象在虚拟场景的场景关联信息，生成符合当前场景效果的调整数据。利用调整数据对实时的语音数据进行处理，以达到丰富的声音处理效果，实现随场景变化的沉浸式语音效果。

附图说明

图1为本申请实施例中音频数据处理方法的一个实施环境示意图；

图2为本申请实施例中音频数据处理方法的另一个实施环境示意图；

图3为本申请实施例中音频数据处理方法的一个流程示意图；

图4为本申请实施例中语音数据与音频引擎交互的一个架构示意图；

图5为本申请实施例中语音数据与音频引擎交互的另一个架构示意图；

图6为本申请实施例中采集插件的一个工作流程示意图；

图7为本申请实施例中发送插件的一个工作流程示意图；

图8为本申请实施例中接收插件的一个工作流程示意图；

图9为本申请实施例中播放插件的一个工作流程示意图；

图10为本申请实施例中基于音频引擎实现端到端语音处理的一个示意图；

图11为本申请实施例中音频数据处理装置的一个示意图；

图12为本申请实施例中终端的一个结构示意图。

具体实施方式

本申请实施例提供了一种音频数据处理方法、相关装置、设备以及存储介质。通过将语音组件插件化之后引入到终端本地的音频引擎中，从而为开发者提供了设计沉浸式语音的工具，由此，实现跟随场景变化的沉浸式语音效果。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“对应”于以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了在应用程序(application，APP)里加入语音能力，目前业界通用的做法是，开发者接入语音PaaS服务商提供的SDK，通过SDK提供的基础API实现各种语音业务场景，例如，游戏同组队友的频道语音，不同队伍之间的范围语音，语音黑名单和白名单等功能。除了这些基本的语音功能API，还提供一些进阶API实现其他业务，例如，三维空间的语音聊天和语音变声能力。可见，APP中赋予的语音体验取决于SDK能力，而传统的语音SDK方案接入过程是独立于APP音效设计的，所以音效设计中的各种专业设计和控制无法用在语音处理上。

基于此，本申请提出了一种音频数据处理方法，用于将语音数据流直接送入到音频引擎中进行处理，使其作为一种特殊的音效，并融合进APP的音频设计中，让APP的开发者和音频师等，可以把丰富的声音处理效果以及声音控制与实时语音进行结合，实现随虚拟场景变化的沉浸式语音效果。通常，开发者设计APP中的音效一般需要使用音频引擎，开发者较为熟悉音频引擎的操作，因此，基于音频引擎的插件化方案，能够让语音的设计流程和其它的APP中音效的设计流程类似。本申请提供的音频引擎插件化方案相比于接入语音SDK的传统方案，无需开发者投入额外的时间去了解这个语音SDK，因此，节省了接入语音的工作量。与此同时，本申请提供的音频引擎插件化方案支持语音的沉浸式设计，即，音频引擎丰富的能力可用于处理语音。而音频引擎是游戏开发者常用的音效工具，因此，给予开发者更大的语音设计空间。

针对本申请提供的音频数据处理方法，在应用时包括如下场景中的至少一种。

一、录制场景；

在一些互动游戏中，用户可以与非玩家角色(non-player character，NPC)进行对话，并且对游戏过程进行录制，以便后续观看或者分享等。示例性地，用户通过终端录制语音数据，该语音数据是用户为虚拟对象在虚拟场景(例如，游戏场景)中与NPC对话的数据。基于此，终端调用音频引擎，基于虚拟场景的场景关联信息获取相应的调整数据，并使用调整数据对录制的语音数据进行处理，得到音频数据。

二、配音场景；

由于声音信号能够有效地补充和增强人的视觉感知内容，因此，可以将本申请提供的音频数据处理方法应用于动画电影的配音，计算机游戏音效制作以及虚拟现实音效制作等。示例性地，用户通过终端录制语音数据，该语音数据是用户替虚拟对象(例如，动画角色)在虚拟场景(例如，动画场景)配音的数据。基于此，终端调用音频引擎，基于虚拟场景的场景关联信息获取相应的调整数据，并使用调整数据对录制的语音数据进行处理，得到音频数据。

三、游戏语音场景；

结合音效师的设计，在集成了音频引擎插件化方案的游戏应用中，用户之间的相互语音可以随着游戏的虚拟场景变动而处理。除了三维空间处理之外，用户控制的虚拟对象处在不同的游戏场景中进行对话，例如，在空旷的山谷或者狭小的屋子会有不同的混响效果，用户感受到的语音效果与场景相适应。又例如，两个正在对话的用户所控制的虚拟角色分别处在虚拟场景中的两个房间里，如果虚拟场景中的房门开与关，用户也会感受到声音的变化。可见，语音效果与游戏中的虚拟场景相适应，达到元宇宙的效果。

需要说明的是，上述应用场景仅为示例，本实施例提供音频数据处理方法还可以应用于其他场景中，此处不做限定。

可以理解的是，本申请可涉及云游戏(cloud gaming)，其中，云游戏又可称为游戏点播(gaming on demand)，是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏。在云游戏场景下，游戏并不在玩家游戏终端，而是在云端服务器中运行，并由云端服务器将游戏场景渲染为视频音频流，通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力，仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

本申请提供的方法可应用于图1或图2所示的实施环境，图1所示的实施环境包括第一终端110，其中，第一终端110中部署有音频引擎。图2所示的实施环境包括第一终端110，服务器120，通信网络130以及第二终端140。其中，第一终端110和服务器120之间通过通信网络130连接，第二终端140和服务器120之间通过通信网络130连接。通信网络130使用标准通信技术和/或协议，通常为因特网，但也可以是任何网络，包括但不限于蓝牙、局域网(local area network，LAN)、城域网(metropolitan area network，MAN)、广域网(widearea network，WAN)、移动、专用网络或者虚拟专用网络的任何组合)。在一些实施例中，可使用定制或专用数据通信技术取代或者补充上述数据通信技术。

本申请涉及的终端(即，第一终端110和第二终端140)包括但不限于手机、电脑、游戏主机、智能语音交互设备、智能家电、车载终端、飞行器等。其中，客户端部署于终端上，客户端可以通过浏览器的形式运行于终端110上，也可以通过独立的APP的形式运行于终端上等。本申请涉及的服务器120可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(content deliverynetwork，CDN)、以及大数据和AI平台等基础云计算服务的云服务器。

结合图1所示的实施环境，用户A通过第一终端110录制第一语音数据。第一终端110根据第一虚拟对象针对虚拟场景的场景关联信息，确定第一调整数据。其中，第一虚拟对象是用户A控制的虚拟对象。基于此，第一终端110通过音频引擎，采用第一调整数据对第一语音数据进行处理，得到第一音频数据。由第一终端110播放第一音频数据。

结合图2所示的实施环境，用户A通过第一终端110录制第一语音数据。第一终端110根据第一虚拟对象针对虚拟场景的场景关联信息，确定第一调整数据。其中，第一虚拟对象是用户A控制的虚拟对象。基于此，第一终端110通过音频引擎，采用第一调整数据对第一语音数据进行处理，得到第一音频数据。第一终端110通过通信网络130向服务器120发送第一音频数据，再由服务器120通过通信网络130向第二终端140发送第一音频数据。于是，用户B可以听到第二终端140播放的第一音频数据。

类似地，用户B通过第二终端140录制第二语音数据。第二终端140根据第二虚拟对象针对虚拟场景的场景关联信息，确定第二调整数据。其中，第二虚拟对象是用户B控制的虚拟对象。基于此，第二终端140通过音频引擎，采用第二调整数据对第二语音数据进行处理，得到第二音频数据。第二终端140通过通信网络130向服务器120发送第二音频数据，再由服务器120通过通信网络130向第一终端110发送第二音频数据。于是，用户A可以听到第一终端110播放的第二音频数据。

可以理解的是，基于用户A控制的虚拟对象和用户B控制的虚拟对象之间的相对情况(例如，相对位置，方向，是否存在障碍物阻挡等情况)，第一终端110利用音频引擎对第一语音数据进行处理。由此，用户B可以听到相应的第一音频数据。类似地，第二终端140利用音频引擎对第二语音数据进行处理。由此，用户A可以听到相应的第二音频数据。

鉴于本申请涉及到一些与专业领域相关的术语，为了便于理解，下面将进行解释。

(1)游戏多媒体引擎(game multimedia engine，GME)；是一个语音通信PaaS服务，产品是以SDK的形式存在，开发者需要把GME集成到APP代码中，从而使APP可以实现语音相关能力。

(2)音频引擎：音效师用来设计和创作音频的软件，利用音频引擎可以大大加快APP中声音的设计效率，提升音频创作的专业性和创造性。

(3)实时通信(real-time communication)：本申请是指实时语音通信技术。

(4)平台即服务(Platform as a Sevice，PaaS)：本申请是指语音服务器平台构建的实时语音服务。

(5)响应于：表示执行操作所依赖的条件或状态，当满足一定的条件或状态时，可执行一个或多个操作。这些操作可以是实时的，也可以具有一定的延迟。

(6)自适应回声消除(auto echo cancellation，AEC)：使用一个自适应滤波器对未知的回声信道进行参数辨识，根据扬声器信号与产生的多路回声的相关性为基础，建立远端信号模型模拟回声路径。通过自适应算法调整，使其冲击响应和真实回声路径相逼近。然后将麦克风接收到的信号减去估计值，即可实现回声消除。

(7)噪声抑制(noise suppression，NS)：通过滤波操作实现降噪目的。

(8)自动增益控制(automatic gain control，AGC)：利用线性放大和压缩放大的有效组合对输出信号进行调整。当弱信号输入时，线性放大电路工作，保证输出信号的强度。当输入信号达到一定强度时，启动压缩放大电路，使输出幅度降低。也就是说，AGC功能可以通过改变输入输出压缩比例自动控制增益的幅度。

(9)语音活动检测(voice activity detection，VAD))：目的是从声音信号流里识别和消除长时间的静音期，以达到在不降低业务质量的情况下节省话路资源的作用，减少用户感觉到的端到端的时延。

(10)不连续传输(discontinuous transmission，DTX)：用于检测静音传输时，自动降低码率节省带宽。

结合上述介绍，下面将对本申请中音频数据处理方法进行介绍，请参阅图3，本申请实施例中音频数据处理方法可以由终端独立完成，也可以由终端与服务器配合完成，本申请提供的方法包括：

210、获取来源于第一对象的第一语音数据；

在一个或多个实施例中，第一终端通过音频输入设备采集来源于第一对象的语音，由此，得到第一语音数据。其中，第一对象的语音可以指用户通话的语音或者录制的语音。

可以理解的是，音频输入设备可以内置或外置于第一终端。音频输入设备包含但不仅限于麦克风、乐器数字接口(musical Instrument digital interface，MIDI)键盘或者其他数字乐器等。第一对象可以是APP的使用者或者游戏玩家等。

220、响应于第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，第一虚拟对象为第一对象控制的虚拟对象，场景关联信息包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

在一个或多个实施例中，第一终端响应于获取到的第一语音数据，并获取第一对象控制的第一虚拟对象在虚拟场景中的场景关联信息。其中，场景关联信息用于描述第一虚拟对象在虚拟场景中的状态，包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项。此外，场景关联信息还可以包括第一虚拟对象与其他虚拟对象(例如，第二虚拟对象)之间的相对关系，例如，方向，距离以及是否存在阻挡物。

230、根据场景关联信息，获取针对第一语音数据的第一调整数据，其中，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，音频属性参数用于对语音数据的播放效果，伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

在一个或多个实施例中，结合场景关联信息生成第一调整数据，其中，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项。音频属性参数用于对第一语音数据进行调整。伴随音频数据用于提供背景音乐和/或背景音效。

240、采用第一调整数据，对第一语音数据进行处理，得到第一音频数据；

在一个或多个实施例中，第一终端调用本地的音频引擎，采用第一调整数据，对第一语音数据进行处理，得到第一音频数据。以游戏应用为例，GME以插件化形式集成在音频引擎中，而音频引擎集成在游戏应用中。

250、实现对第一音频数据的播放。

在一个或多个实施例中，第一种情况为，在第一终端生成第一音频数据之后，可直接播放第一音频数据。第二种情况为，在第一终端生成第一音频数据之后，可将第一音频数据发送至服务器，由服务器发送给至少一个第二终端，这些第二终端可直接播放第一音频数据，或者，对第一音频数据进行进一步处理后进行播放。

具体地，以第一种情况为例，请参阅图4，图4为本申请实施例中语音数据与音频引擎交互的一个架构示意图，如图所示，第一终端中的语音采集模块将采集到的语音传递给音频引擎，由音频引擎进行处理之后传递给第一终端中的语音播放模块。以第二种情况为例，请参阅图5，图5为本申请实施例中语音数据与音频引擎交互的另一个架构示意图，如图所示，第一终端中的语音采集模块将采集到的语音传递给音频引擎，由音频引擎进行处理之后传递给第一终端中的语音发送模块。语音发送模块将处理后的音频数据发送至服务器，通过服务器将音频数据发送至第二终端的语音接收模块，基于此，由第二终端的语音播放模块进行音频数据的播放。

本申请实施例中，提供了一种音频数据处理方法。通过上述方式，将语音组件插件化之后引入到终端本地的音频引擎中，能够把语音数据直接送入到音频引擎中进行处理。即，根据虚拟对象在虚拟场景的场景关联信息，生成符合当前场景效果的调整数据。利用调整数据对实时的语音数据进行处理，以达到丰富的声音处理效果，实现随场景变化的沉浸式语音效果。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，获取来源于第一对象的第一语音数据，具体可以包括：

通过音频输入设备采集来源于第一对象的原始语音数据；

对原始语音数据进行语音前处理，得到第一处理语音数据，其中，语音前处理包括降噪处理，回声消除处理，音量均衡处理以及啸叫抑制处理中的至少一项；

对第一处理语音数据进行音频帧转换处理，得到第一语音数据，其中，音频帧转换处理包括采样率转换处理，声道转换处理、采样深度转换处理以及音频帧长处理中的至少一项。

在一个或多个实施例中，介绍了一种对语音数据进行处理的方式。由前述实施例可知，第一终端通过应用程序编程接口(application programming interface，API)获取由音频输入设备采集第一对象的本地语音，即，得到原始语音数据。由此，第一终端对原始语音数据进行语音前处理以及音频帧转换处理，以此得到第一语音数据。

具体地，语音前处理中的降噪处理主要用于去除原始语音数据中的噪声。

语音前处理中的回声消除处理主要用于去除原始语音数据中的回声。回声消除处理算法需要将当前扬声器播放的声音作为参考信号，因此，前处理模块需要和播放插件进行数据交换。因为播放插件作用在音频总线的末端，所以可以得到待播放的音频信号信息，从而为回声消除处理算法提供参考播放信号。

语音前处理中的音量均衡处理用于对原始语音数据进行要音量响度的调整。

语音前处理中的啸叫抑制处理主要用于抑制原始语音数据中的啸叫。其中，啸叫抑制处理方法主要包括移频移相法、陷波抑制法和自适应反馈抵消法。

基于此，对原始语音数据进行语音前处理之后可得到第一处理语音数据。于是，需要进一步对第一处理语音数据进行音频帧转换处理，得到第一语音数据。示例性地，第一处理语音数据的语音参数可包括：16千赫兹(kHz)的采样率，单声道，采样深度为16比特定点/采样点(bit-int)，20毫秒(ms)的帧长。示例性地，第一语音数据的语音参数可包括：48kHz的采样率，双声道，采样深度为32比特浮点/采样点(bit-float)，21.3ms的帧长。

需要说明的是，第一语音数据的采样率可采用44.1kHz，或者，可采用96kHz等，以达到高保真的效果，上述示例以采样率为48kHz为例进行介绍，但不应理解为对本申请的限定。

其次，本申请实施例中，提供了一种对语音数据进行处理的方式。通过上述方式，对于采集到的用户语音数据进行语音前处理，使得处理后的语音数据更能代表语音的本质特征，从而达到更好的音频处理效果。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，对第一处理语音数据进行音频帧转换处理，得到第一语音数据，具体可以包括：

对第一处理语音数据进行音频帧转换处理，得到第一音频帧序列，其中，第一音频帧序列包括至少一个第一音频帧；

对第一音频帧序列进行采样，得到每个第一音频帧的第一采样点数据集合，其中，第一采样点数据集合包括M个采样点数据，M为大于1的整数；

将每个第一音频帧的第一采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第二采样点数据集合，其中，每个第二采样点数据集合包括N个采样点数据，N为大于1的整数；

根据至少一个第二采样点数据集合，生成第一语音数据，其中，第一语音数据包括至少一个第二音频帧，每个第二音频帧对应于一个第二采样点数据集合。

在一个或多个实施例中，提供了一种得到第一语音数据的方式。由前述实施例可知，音频引擎包括采集插件，在采集插件中，可对APP语音系统(例如，GME)输出的第一处理语音数据进行音频帧转换处理，得到包括至少一个第一音频帧的第一音频帧序列。由于APP语音系统与音频引擎的帧长不同，因此，无法将第一音频帧直接作为音频引擎中的一个音频帧进行处理。基于此，可引入环形缓冲区(ring buffer)来处理。

具体地，为了便于理解，请参阅图6，图6为本申请实施例中采集插件的一个工作流程示意图，如图所示，首先，对第一处理语音数据(即，语音系统的音频数据帧)进行音频帧转换处理，得到第一音频帧序列，其中，第一处理语音数据的语音参数可包括：16kHz的采样率，单声道，采样深度为16bit-int，20ms的帧长。第一音频帧序列的语音参数可包括：48kHz的采样率，双声道，采样深度为32bit-float，第一音频帧的帧长为20ms。可以理解的是，APP语音系统(例如，GME)对第一音频帧序列进行采样，得到每个第一音频帧的第一采样点数据集合。第一采样点数据集合包括M个采样点数据。

需要说明的是，本申请以M为960，N为1024为例进行说明，但不应理解为对本申请的限定。

基于此，APP语音系统(例如，GME)充当生产者的角色，将每个第一音频帧的第一采样点数据集合写入环形缓冲区。例如，APP语音系统(例如，GME)每次写入960个采样点数据。而音频引擎充当消费者的角色，从环形缓冲区中读取至少一个第二采样点数据集合。例如，音频引擎每次读取1024个采样点数据。于是，将每次读取采样点数据作为一个第二采样点数据集合，并将一个第二采样点数据集合作为一个第二音频帧。由此，得到由各个第二音频帧组成的第一语音数据(即，音频引擎的音频数据帧)。其中，第一语音数据的语音参数可包括：48kHz的采样率，双声道，采样深度为32bit-float，第二音频帧的帧长为21.3ms。

可以理解的是，上述语音参数均为一个示意，不应理解为对本申请的限定。

再次，本申请实施例中，提供了一种得到第一语音数据的方式。通过上述方式，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，场景关联信息包括位置信息，第一调整数据包括音频属性参数；

根据场景关联信息，获取针对第一语音数据的第一调整数据，具体可以包括：

根据位置信息确定第一虚拟对象在虚拟场景中的空间类型；

若空间类型属于第一空间类型，则确定针对第一语音数据的音频属性参数包括混响调整参数，其中，第一空间类型表示在虚拟场景中小于或等于空间尺寸阈值的虚拟空间；

若空间类型属于第二空间类型，则确定针对第一语音数据的音频属性参数包括回声调整参数，其中，第二空间类型表示在虚拟场景中大于空间尺寸阈值的虚拟空间。

在一个或多个实施例中，介绍了一种基于位置信息确定音频属性参数的方式。由前述实施例可知，场景关联信息包括第一虚拟角色在虚拟场景中的位置信息，基于该位置信息可生成对应的音频属性参数。

具体地，根据位置信息确定第一虚拟对象在虚拟场景中的空间类型，示例性地，如果第一虚拟对象在虚拟场景中的“房间”，则确定第一虚拟对象所在虚拟空间属于第一空间类型。基于此，音频属性参数包括混响调整参数。通过混响调整参数提供混响效果。示例性地，如果第一虚拟对象在虚拟场景中的“山谷”，则确定第一虚拟对象所在虚拟空间属于第二空间类型。基于此，音频属性参数包括回声调整参数。通过回声调整参数提供回声效果。

需要说明的是，第一空间类型为小于或等于空间尺寸阈值的虚拟空间，第二空间类型为大于空间尺寸阈值的虚拟空间。属于第一空间类型的虚拟空间包含但不仅限于小木屋、房间、教室等，属于第二空间类型的虚拟空间包含但不仅限于大堂、山谷、草原等。

在虚拟场景中，为了让用户能够拥有更加沉浸的语音体验，就需要通过数字信号处理(digital signal processing，DSP)算法来仿真实现这种混响效果。根据混响产生的物理原理，通常可以通过两种方式对原始语音信号来处理，下面将分别进行介绍。

(1)一种方式为，可通过算法模拟空间的模型。例如，根据空间尺寸和材料等属性来调节延迟、衰减和散射等参数，从而对原始信号滤波达到不同的质地不同的空间大小产生的混响效果。该方法本质就是复制多路原始信号进行滤波，然后多路延迟衰减之后再叠加播放。对于第一空间类型的虚拟空间而言，反射路径和延迟不需要很多，因此，利用混响调整参数实现滤波，通过滤波达到温暖柔和的感觉。对于第二空间类型的虚拟空间而言，需要反射路径多一些，延迟大一些，因此，利用回声调整参数实现滤波，通过滤波达到适当提升高频分量的目标，从而实现空旷高大的回声效果。

(2)另一种方式为，通过对空间实测的滤波器来实现。即，通过搭建和虚拟场景一样的实物空间来测量此空间的冲击响应(Impulse response，IR)，相当于是通过原始信号和录制出来的信号来计算声音在实物空间的传递函数。在虚拟场景中，通过对原始语音来卷积该传递函数就即可实现对应环境的听觉效果，从而达到沉浸式的交流体验。对于第一空间类型的虚拟空间而言，将其对应实物空间的传递函数中的参数作为混响调整参数。对于第二空间类型的虚拟空间而言，将其对应实物空间的传递函数中的参数作为回声调整参数。

其次，本申请实施例中，提供了一种基于位置信息确定音频属性参数的方式。通过上述方式，结合虚拟对象在虚拟场景中的位置信息，能够模拟用户在现实环境下感知到的语音效果。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，场景关联信息包括环境信息，第一调整数据包括伴随音频数据；

根据场景关联信息，获取针对第一语音数据的第一调整数据，具体可以包括：

若环境信息指示第一虚拟对象处于室内环境，则确定针对第一语音数据的伴随音频数据包括基于室内环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于户外环境，则确定针对第一语音数据的伴随音频数据包括基于户外环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于天气环境，则确定针对第一语音数据的伴随音频数据包括基于天气环境录制得到的音频数据。

在一个或多个实施例中，介绍了一种基于环境信息确定音频属性参数的方式。由前述实施例可知，场景关联信息包括第一虚拟角色在虚拟场景中的环境信息，基于该位置信息可获取对应的伴随音频数据。由于APP语音系统(例如，GME)和音频引擎的交互，因此，伴随音频数据也可以增加语音聊天的沉浸感。现实世界的一个声音传递到用户耳朵里，不仅和用户所处物理环境的混响有关，还和周围的声音环境有关。

下面将分别结合环境类型进行介绍。

一、室内环境；

具体地，如果第一虚拟对象处于室内环境，则需要把对应室内环境的伴随音频数据叠加到第一语音数据音中。其中，伴随音频数据包括基于室内环境录制得到的音频数据。室内环境可以是地铁站，咖啡厅或者酒吧等。

二、户外环境；

具体地，如果第一虚拟对象处于户外环境，则需要把对应户外环境的伴随音频数据叠加到第一语音数据音中。其中，伴随音频数据包括基于户外环境录制得到的音频数据。户外环境可以是站台、道路或者公园等。

三、天气环境；

具体地，如果第一虚拟对象处于天气环境，则需要把对应天气环境的伴随音频数据叠加到第一语音数据音中。其中，伴随音频数据包括基于天气环境录制得到的音频数据。天气环境可以是下雨、刮风或者打雷等。

可以理解的是，为了让用户在虚拟场景的语音聊天或语音录制也能体验沉浸式效果，通过叠加预先录制的伴随音频数据表明用户所处环境的室内因素、户外因素和天气因素等，这样作为听者的用户就可以体验出和沉浸在游戏中的语音效果。

其次，本申请实施例中，提供了一种基于环境信息确定音频属性参数的方式。通过上述方式，结合虚拟对象在虚拟场景中的环境信息，能够模拟用户在现实环境下感知到的语音效果。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，场景关联信息包括情绪信息，第一调整数据包括音频属性参数；

根据场景关联信息，获取针对第一语音数据的第一调整数据，具体可以包括：

若情绪信息指示第一虚拟对象处于第一情绪状态，则确定针对第一语音数据的音频属性参数包括时域调整参数、第一频域调整参数以及升调调整参数中的至少一项，其中，时域调整参数用于提高语音音头，第一频域调整参数用于增强语音高频分量；

若情绪信息指示第一虚拟对象处于第二情绪状态，则确定针对第一语音数据的音频属性参数包括语速调整参数以及周期调整参数中的至少一项，其中，语速调整参数用于减慢语速，周期调整参数用于周期性地改变语调；

若情绪信息指示第一虚拟对象处于第三情绪状态，则确定针对第一语音数据的音频属性参数包括第二频域调整参数以及降调调整参数中的至少一项，其中，第二频域调整参数用于增强语音数据的低频分量。

在一个或多个实施例中，介绍了一种基于情绪信息确定音频属性参数的方式。由前述实施例可知，场景关联信息包括第一虚拟角色在虚拟场景中的情绪信息，基于该情绪信息可获取对应的音频属性参数。人们在现实世界说话时，同一句话在不同的情绪下会表现出不同的效果。对于虚拟角色而言，为了提升语音的沉浸性，同样需要通过DSP的方式来模拟这些效果。

下面将分别结合情绪类型进行介绍。

一、第一情绪状态；

具体地，第一情绪状态用于表示第一虚拟对象处于兴奋或激动的情绪状态。示例性地，如果第一虚拟对象在虚拟场景中拾取了珍贵物件，则采用时域调整参数、第一频域调整参数以及升调调整参数中的至少一项对第一语音数据进行调整。

其中，时域调整参数用于适当的提高语音数据中每个字的音头。第一频域调整参数用于对语音数据进行高通滤波处理，即，对语音数据低频部分进行衰减，并保留高频部，使得频域上突出高频分量。升调调整参数用于提升语音数据的音调，即，达到高声调的目的。

二、第二情绪状态；

具体地，第二情绪状态用于表示第一虚拟对象处于恐惧或受伤的情绪状态。示例性地，如果第一虚拟对象在虚拟场景中受到攻击后掉血量，则采用语速调整参数以及周期调整参数中的至少一项对第一语音数据进行调整。

其中，语速调整参数用于对语音数据进行适当的慢速处理。周期调整参数用于通过周期的预定改变产生颤音的效果。

三、第三情绪状态；

具体地，第三情绪状态用于表示第一虚拟对象处于生气或发怒的情绪状态。示例性地，如果第一虚拟对象在虚拟场景中出现冲突，则采用第二频域调整参数以及降调调整参数中的至少一项对第一语音数据进行调整。

其中，第二频域调整参数用于对语音数据进行对语音数据低频部分进行增强，来表达低沉而震撼语音效果。降调调整参数用于提升语音数据的音量。

需要说明的是，考虑到到虚拟场景具有娱乐属性，因此，音效设计师可以根据语音的玩法需求，对语音数据进行更大幅度的处理来表达用户的心里状态。

其次，本申请实施例中，提供了一种基于情绪信息确定音频属性参数的方式。通过上述方式，结合虚拟对象在虚拟场景中的情绪信息，能够模拟用户在现实环境下的情绪，体现出虚拟对象的性格和状态。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，场景关联信息包括角色信息，第一调整数据包括音频属性参数；

根据场景关联信息，获取针对第一语音数据的第一调整数据，具体可以包括：

若角色信息指示第一虚拟对象属于目标角色类型，则确定针对第一语音数据的音频属性参数包括音高调整参数、音色调整参数以及共振峰调整参数。

在一个或多个实施例中，介绍了一种基于角色信息确定音频属性参数的方式。由前述实施例可知，场景关联信息包括第一虚拟角色在虚拟场景中的角色信息，基于该角色信息可获取对应的音频属性参数。在一些情况下，用户还可以为虚拟对象进行配音，因此，结合角色信息所指示的目标角色类型(例如，小女孩或者老人)，基于变声参数或者基于AI模型实现特定语音变声。

示例性地，音高调整参数用于对语音数据的“波动率”调快或调慢，以升高或降低声音的音高。音高调整参数越低，输出的声音就越低沉，例如，男低音的声音。音高调整参数越高，输出的声音就越尖细，例如，婴儿、女孩、男孩、女性的声音。

示例性地，音色调整参数用于对语音数据的音色进行调整。音色调整参数越低，输出的声音会比较低沉浑厚，例如，年老男子的声音。音色调整参数越高，输出的声音就会越轻快，例如，小孩子的声音。

示例性地，共振峰调整参数用于为语音数据输出一个更为自然的语音质量。在不影响其它项质量的情况下配置语音数据的音高。共振峰调整参数越低，共振峰动点就越低，变声后的声音就越低沉。共振峰调整参数越高，共振峰动点就越高，变声后的声音就越尖细。

其次，本申请实施例中，提供了一种基于角色信息确定音频属性参数的方式。通过上述方式，结合虚拟对象在虚拟场景中的角色信息，能够模拟出符合角色信的特定语音变声效果。从而增加趣味性，并适用于特定使用场景(例如，对特定声优配音等)。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，第一调整数据包括音频属性参数以及伴随音频数据；

采用第一调整数据，对第一语音数据进行处理，得到第一音频数据，具体可以包括：

采用音频属性参数，对第一语音数据进行调整，得到目标语音数据；

对目标语音数据进行语音后处理，得到第二处理语音数据，其中，语音后处理包括语音增强处理，频段增益处理以及调音处理中的至少一项；

将伴随音频数据与第二处理语音数据进行叠加，得到第一音频数据。

在一个或多个实施例中，介绍了一种处理得到第一音频数据的方式。由前述实施例可知，第一调整数据包括音频属性参数以及伴随音频数据

具体地，首先，使用音频属性参数对第一语音数据进行调整，得到目标语音数据。其中，目标语音数据即为变化后的语音数据。于是，可以对目标语音数据进行语音后处理，得到第二处理语音数据。语音后处理是指对语音数据在渲染前进行的一些信号处理，从而使语音数据在终端播放时更加清晰。语音后处理包括语音增强处理，频段增益处理以及调音处理中的至少一项，以满足用户的个性设置。例如，调整各个频段增益的均衡器，或者针对终端的扬声器特性做一些调音，例如，采用频率响应曲线补偿技术。最后，将伴随音频数据与第二处理语音数据进行叠加，从而得到第一音频数据。

需要说明的是，当有用户说话的时候，混音的焦点应该落到语音数据上，而不是伴随音频数据。基于此，类似收音机电台的做法，在播放语音数据的时候，需要将伴随音频数据的音量降低一些，等语音数据播放完成之后，再恢复伴随音频数据的音量。

其次，本申请实施例中，提供了一种处理得到第一音频数据的方式。通过上述方式，实现了将语音设计融合到了APP音效设计中，开阔了音效设计师设计语音的思路。基于此，有利于发展语音端到端处理的生态，使得其它专业处理算法和中间件也可以加入到生态中，共同提升用户的语音体验。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，实现对第一音频数据的播放，具体可以包括：

响应于音频播放操作，通过音频输出设备播放第一音频数据。

或者，

实现对第一音频数据的播放，具体可以包括：

向第二终端发送第一音频数据，以使第二终端通过音频输出设备播放第一音频数据。

在一个或多个实施例中，介绍了一种播放第一音频数据的方式。由前述实施例可知，在得到第一音频数据之后，可以由第一终端的音频输出设备(例如，扬声器)播放第一音频数据，或者，由第二终端音频输出设备(例如，扬声器)播放第一音频数据。下面将结合具体场景进行介绍。

一、本地播放第一音频数据；

具体地，以配音场景为例，用户录制第一语音数据，经过处理之后得到第一音频数据。其中，第一音频数据表示配音后的音频内容。如果用户需要听一下配音效果，则可以触发音频播放操作，由此，第一终端通过音频输出设备播放第一音频数据。

二、远端播放第一音频数据；

具体地，以游戏内交流场景为例，用户录制第一语音数据，经过处理之后得到第一音频数据。其中，第一音频数据表示局内的音频内容。于是，第一终端将第一音频数据发送到服务器，由服务器将第一音频数据发送至第二终端。基于此，第二终端可直接播放第一音频数据，或者，调用第二终端中的音频引擎对第一音频数据进行处理后进行播放。

其次，本申请实施例中，提供了一种播放第一音频数据的方式。通过上述方式，不仅支持本地终端播放第一音频数据，还支持远端终端播放第一音频数据。因此，增加了语音数据播放的灵活性和多样性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，向第二终端发送第一音频数据，具体可以包括：

获取语音场景类型；

若语音场景类型属于第一场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为单声道的音频数据，且，第一音频数据采用第一采样率；

若语音场景类型属于第二场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为立体声道的音频数据，且，第一音频数据采用第二采样率，第二采样率高于第一采样率。

在一个或多个实施例中，介绍了一种对第一音频数据进行信源与信道编码的方式。由前述实施例可知，基于网际互联协议的语音传输(voice over internet protocol，VoIP)的核心是数字化编码的信号在网络上进行传输，从第一终端录制语音数据到第二终端播放音频数据，通常需要若干处理算法。此外，网络可能会出现丢包或者抖动等，因此，还会引入一定的延迟，延迟大小和信号传输的带宽是相对的。也就是说，如果为了减小延迟就需要减少信号占用的带宽，如果为了传输高带宽的信号就会引入相对大的延迟。基于此，可根据语音场景类型选择相应的网络策略。下面将结合示例进行介绍。

一、第一场景类型；

具体地，第一场景类型为实时性较强的场景，例如，游戏场景以及直播场景等。这类场景需要低延迟且流畅的音频数据。因此，可传输单声道且第一采样率的第一音频数据，还可以对第一音频数据采用有损声音编码(opus)。其中，第一采样率为低采样率，例如，16kHz。由此，第一音频数据的数据量较少，占用带宽小，所以延迟就很小。

二、第二场景类型；

具体地，第一场景类型为实时性较低的场景，例如，个人语音电台场景以及在线演唱会场景等。这类场景通常是主播在说话，与听众没有频繁的互动沟通，因此，对延迟的要求不大，但是对音频质量有一定要求。因此，可传输立体声道且第二采样率的第一音频数据。其中，第二采样率为高采样率，例如，48kHz。

需要说明的是，还可以进一步定义语音房间的类型，示例性地，第一场景类型的语音房间属于“流畅房间类型”，第二场景类型的语音房间属于“高清房间类型”。基于不同的语音场景类型可适用于不同的应用场景。

再次，本申请实施例中，提供了一种对第一音频数据进行信源与信道编码的方式。通过上述方式，可基于语音场景类型，对音频数据进行信源和信道编码，以节约网络传输带宽，并增加弱网络鲁棒性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，向第二终端发送第一音频数据，具体可以包括：

对第一音频数据进行分帧处理，得到第二音频帧序列，其中，第二音频帧序列包括至少一个第三音频帧；

对第二音频帧序列进行采样，得到每个第三音频帧的第三采样点数据集合，其中，第三采样点数据集合包括P个采样点数据，P为大于1的整数；

将每个第三音频帧的第三采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第四采样点数据集合，其中，每个第四采样点数据集合包括Q个采样点数据，Q为大于1的整数；

对至少一个第四采样点数据集合进行音频帧转换处理，并向第二终端发送处理后的第一音频数据，其中，第一音频数据包括至少一个第四音频帧，每个第四音频帧对应于一个第四采样点数据集合。

在一个或多个实施例中，介绍了一种得到第一音频数据的方式。由前述实施例可知，音频引擎包括发送插件，在发送插件中，可对音频引擎输出的第一音频数据进行分帧处理，得到包括至少一个第三音频帧的第二音频帧序列。由于音频引擎与APP语音系统的帧长不同，因此，无法将第三音频帧直接作为APP语音系统中的一个音频帧进行处理。基于此，可引入环形缓冲区来处理。

具体地，为了便于理解，请参阅图7，图7为本申请实施例中发送插件的一个工作流程示意图，如图所示，首先，对第一音频数据(即，音频引擎的音频数据帧)进行分帧处理，得到第二音频帧序列，其中，第二音频帧序列的语音参数可包括：48kHz的采样率，双声道，采样深度为32bit-float，第三音频帧的帧长为21.3ms。可以理解的是，音频引擎对第二音频帧序列进行采样，得到每个第三音频帧的第三采样点数据集合。第三采样点数据集合包括P个采样点数据。

需要说明的是，本申请以P为1024，Q为960为例进行说明，但不应理解为对本申请的限定。

基于此，音频引擎充当生产者的角色，将每个第三音频帧的第三采样点数据集合写入环形缓冲区。例如，音频引擎每次写入1024个采样点数据。而APP语音系统(例如，GME)充当消费者的角色，从环形缓冲区中读取至少一个第四采样点数据集合。例如，APP语音系统(例如，GME)每次读取960个采样点数据。于是，将每次读取采样点数据作为一个第四采样点数据集合，并基于各个第四采样点数据集合进行音频帧转换处理，得到由各个第四音频帧组成的处理后的第一音频数据(即，语音系统的音频数据帧)。其中，处理后的第一音频数据的语音参数可包括：16kHz的采样率，单声道，采样深度为16bit-int，第四音频帧的帧长为20ms。

可以理解的是，上述语音参数均为一个示意，不应理解为对本申请的限定。

再次，本申请实施例中，提供了一种得到第一音频数据的方式。通过上述方式，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

播放第二音频数据。

在一个或多个实施例中，介绍了一种播放远端音频数据的方式。由前述实施例可知，音频引擎包括发送插件，在发送插件中，可对APP语音系统(例如，GME)输入的音频数据进行音频帧转换处理，得到转换后的音频帧。由于音频引擎与APP语音系统的帧长不同，因此，无法将转换后的音频帧作为音频系统中的一个音频帧进行处理。基于此，可引入环形缓冲区来处理。

具体地，为了便于理解，请参阅图8，图8为本申请实施例中接收插件的一个工作流程示意图，如图所示，首先，APP语音系统(例如，GME)输入的音频数据(即，语音系统的音频数据帧)进行音频帧转换处理。由此，得到16kHz的采样率，单声道，采样深度为16bit-int，帧长为20ms的音频帧序列。

基于此，APP语音系统(例如，GME)充当生产者的角色，将音频帧序列写入环形缓冲区。例如，APP语音系统(例如，GME)每次写入960个采样点数据。音频引擎充当消费者的角色，每次从环形缓冲区中读取1024个采样点数据，由此，得到第二音频数据。

可以理解的是，第二终端采集来源于第二对象的第二语音数据，其中，第二对象控制第二虚拟对象。于是，根据第二虚拟对象针对虚拟场景的场景关联信息确定第二调整数据。再采用第二调整数据对第二语音数据进行处理，以得到第二音频数据。具体处理流程与得到第一音频数据的流程类似，此处不做赘述。

其次，本申请实施例中，提供了一种播放远端音频数据的方式。通过上述方式，可直接播放远端传输过来的音频数据。由于该音频数据也是跟随虚拟场景变化而变化的，因此，能够使得用户听到的语音具有更强的氛围感，从而提升用户体验。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，播放第二音频数据，具体可以包括：

对第二音频数据进行分帧处理，得到第三音频帧序列，其中，第三音频帧序列包括至少一个第五音频帧；

对第三音频帧序列进行采样，得到每个第五音频帧的第五采样点数据集合，其中，第五采样点数据集合包括X个采样点数据，X为大于1的整数；

将每个第五音频帧的第五采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第六采样点数据集合，其中，每个第六采样点数据集合包括Y个采样点数据，Y为大于1的整数；

对至少一个第六采样点数据集合进行音频帧转换处理，并播放处理后的第二音频数据，其中，第二音频数据包括至少一个第六音频帧，每个第六音频帧对应于一个第六采样点数据集合。

在一个或多个实施例中，介绍了一种播放第二音频数据的方式。由前述实施例可知，音频引擎包括播放插件，在播放插件中，可对音频引擎输出的第二音频数据进行分帧处理，得到包括至少一个第五音频帧的第三音频帧序列。由于音频引擎与APP语音系统的帧长不同，因此，无法将第五音频帧直接作为APP语音系统中的一个音频帧进行处理。基于此，可引入环形缓冲区来处理。

具体地，为了便于理解，请参阅图9，图9为本申请实施例中播放插件的一个工作流程示意图，如图所示，首先，对第二音频数据(即，音频引擎的音频数据帧)进行分帧处理，得到第三音频帧序列，其中，第三音频帧序列的语音参数可包括：48kHz的采样率，双声道，采样深度为32bit-float，第五音频帧的帧长为21.3ms。可以理解的是，音频引擎对第三音频帧序列进行采样，得到每个第五音频帧的第五采样点数据集合。第五采样点数据集合包括X个采样点数据。

需要说明的是，本申请以X为1024，Y为960为例进行说明，但不应理解为对本申请的限定。

基于此，音频引擎充当生产者的角色，将每个第五音频帧的第五采样点数据集合写入环形缓冲区。例如，音频引擎每次写入1024个采样点数据。而APP语音系统(例如，GME)充当消费者的角色，从环形缓冲区中读取至少一个第六采样点数据集合。例如，APP语音系统(例如，GME)每次读取960个采样点数据。于是，将每次读取采样点数据作为一个第六采样点数据集合，并基于各个第六采样点数据集合进行音频帧转换处理，得到由各个第六音频帧组成的处理后的第二音频数据(即，语音系统的音频数据帧)。其中，处理后的第二音频数据的语音参数可包括：16kHz的采样率，单声道，采样深度为16bit-int，第六音频帧的帧长为20ms。

可以理解的是，上述语音参数均为一个示意，不应理解为对本申请的限定。

需要说明的是，由于播放插件处在音频引擎处理数据的最末一环，因此，需要处理的数据不仅包括语音数据，还包括APP中的音频数据。音频设计师会根据音频素材设计各种可能的音频表现格式，例如，多声道音频和对象音频等。这些非默认格式信号需要利用下混算法(downmix)或者对象音频渲染算法(OAR)先转成双声道的音频。

再次，本申请实施例中，提供了一种播放第二音频数据的方式。通过上述方式，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，还可以包括：

接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

响应于第二音频数据，根据第一虚拟对象与第二虚拟对象在对虚拟场景中的位置信息，获取对象关联信息；

根据对象关联信息，获取针对第二音频数据的第三调整数据；

采用第三调整数据，对第二音频数据进行处理，得到第三音频数据；

播放第三音频数据。

在一个或多个实施例中，介绍了另一种播放远端音频数据的方式。由前述实施例可知，第二终端采集来源于第二对象的第二语音数据，其中，第二对象控制第二虚拟对象。于是，根据第二虚拟对象针对虚拟场景的场景关联信息确定第二调整数据。再采用第二调整数据对第二语音数据进行处理，以得到第二音频数据。具体处理流程与得到第一音频数据的流程类似，此处不做赘述。

具体地，虚拟场景中包括第一虚拟对象和第二虚拟对象，因此，还可以根据第一虚拟对象与第二虚拟对象在对虚拟场景中的位置信息，获取对象关联信息。其中，对象关联信息包括虚拟对象之间的距离信息、方向信息以及阻挡物信息。基于此，在第一终端接收第二终端发送的第二音频数据之后，可根据对象关联信息获取针对第二音频数据的第三调整数据。再使用第三调整数据对第二音频数据进行处理，得到第三音频数据，最后，第一终端播放第三音频数据。

示例性地，基于对象关联信息所包括的距离信息生成第三调整数据，其中，该第三调整数据包括距离衰减参数。距离衰减参数可调节音频数据的响度。

示例性地，基于对象关联信息所包括的方向信息生成第三调整数据，其中，该第三调整数据包括3D参数。音频数据通过3D参数的调节，能够使得声音传达到第一对象的效果与第二虚拟对象在第一虚拟对象的方向信息相关。

示例性地，基于对象关联信息所包括的阻挡物信息生成第三调整数据，如果阻挡物信息指示第一虚拟对象与第二虚拟对象之间具有阻挡物，则第三调整数据包括声音反射参数。通过声音反射参数反映声音在不同空间的反射衍射效果。

需要说明的是，第二音频数据的处理流程可参阅图8所描述的实施例，此处不做赘述。

其次，本申请实施例中，提供了另一种播放远端音频数据的方式。通过上述方式，可对远端传输过来的音频数据作进一步优化。由此，音频数据不仅能够跟随虚拟场景变化而变化，而且还考虑到虚拟对象之间的相对位置，从而使得用户听到的语音具有更强的真实感，以提升用户体验。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，播放第三音频数据，具体可以包括：

对第三音频数据进行分帧处理，得到第四音频帧序列，其中，第四音频帧序列包括至少一个第七音频帧；

对第四音频帧序列进行采样，得到每个第七音频帧的第七采样点数据集合，其中，第七采样点数据集合包括S个采样点数据，S为大于1的整数；

将每个第七音频帧的第七采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第八采样点数据集合，其中，每个第八采样点数据集合包括R个采样点数据，R为大于1的整数；

对至少一个第八采样点数据集合进行音频帧转换处理，并播放处理后的第三音频数据，其中，第三音频数据包括至少一个第八音频帧，每个第八音频帧对应于一个第八采样点数据集合。

在一个或多个实施例中，介绍了一种播放第三音频数据的方式。由前述实施例可知，音频引擎包括播放插件，在播放插件中，可对音频引擎输出的第三音频数据进行分帧处理，得到包括至少一个第七音频帧的第四音频帧序列。由于音频引擎与APP语音系统的帧长不同，因此，无法将第七音频帧直接作为APP语音系统中的一个音频帧进行处理。基于此，可引入环形缓冲区来处理。

具体地，为了便于理解，请再次参阅图9，如图所示，首先，对第三音频数据(即，音频引擎的音频数据帧)进行分帧处理，得到第四音频帧序列，其中，第四音频帧序列的语音参数可包括：48kHz的采样率，双声道，采样深度为32bit-float，第七音频帧的帧长为21.3ms。可以理解的是，音频引擎对第四音频帧序列进行采样，得到每个第七音频帧的第七采样点数据集合。第七采样点数据集合包括S个采样点数据。

需要说明的是，本申请以S为1024，R为960为例进行说明，但不应理解为对本申请的限定。

基于此，音频引擎充当生产者的角色，将每个第七音频帧的第七采样点数据集合写入环形缓冲区。例如，音频引擎每次写入1024个采样点数据。而APP语音系统(例如，GME)充当消费者的角色，从环形缓冲区中读取至少一个第八采样点数据集合。例如，APP语音系统(例如，GME)每次读取960个采样点数据。于是，将每次读取采样点数据作为一个第八采样点数据集合，并基于各个第八采样点数据集合进行音频帧转换处理，得到由各个第八音频帧组成的处理后的第三音频数据(即，语音系统的音频数据帧)。其中，处理后的第三音频数据的语音参数可包括：16kHz的采样率，单声道，采样深度为16bit-int，第八音频帧的帧长为20ms。

可以理解的是，上述语音参数均为一个示意，不应理解为对本申请的限定。

需要说明的是，由于播放插件处在音频引擎处理数据的最末一环，因此，需要处理的数据不仅包括语音数据，还包括APP中的音频数据。音频设计师会根据音频素材设计各种可能的音频表现格式，例如，多声道音频和对象音频等。这些非默认格式信号需要利用下混算法(downmix)或者对象音频渲染算法(OAR)先转成双声道的音频。

再次，本申请实施例中，提供了一种播放第三音频数据的方式。通过上述方式，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图3对应的各个实施例的基础上，本申请实施例提供的另一个可选实施例中，接收第二终端发送的第二音频数据，具体可以包括：

基于数据传输策略，接收第二终端发送的第二音频数据，其中，数据传输策略包括前向纠错策略、丢包补偿策略、自动重传策略以及缓存抗抖动策略中的至少一种，前向纠错策略用于纠正数据传输过程中出现的错误码，丢包补偿策略用于补偿缺失的音频帧，自动重传策略用于请求重传音频帧，缓存抗抖动策略用于在数据传输过程中采用动态缓存。

在一个或多个实施例中，介绍了一种基于数据传输策略接收第二音频数据的方式。由前述实施例可知，音频数据在网络上传输需要应对网络的各种问题，常见的问题是网络丢包和网络抖动，基于此，APP语音系统(例如，GME)需要采用数据传输策略增加对弱网络的抗性。下面将介绍第一终端基于数据传输策略接收第二音频数据的方式。

一、前向纠错(forward error correction，FEC)策略；

具体地，FEC策略是一种差错控制的策略。它是指信号在被送入传输信道之前预先按一定的算法进行编码处理，加入带有信号本身特征的冗码，在接收端按照相应算法对接收到的信号进行解码，从而找出在传输过程中产生的错误码并将其纠正。

二、丢包补偿(packet loss concealment，PLC)策略；

具体地，PLC策略是利用所有可得到的信息，对丢失帧进行恰当的估计补偿，以便隐藏丢失帧，使之不易被察觉，进而达到改善音频质量的目的。

三、自动重传(automatic repeat request，ARQ)策略；

具体地，从接收端向发射端发送指示所接收的分组不包含差错的确认(acknowledge character，ACK)信号，或者，指示所接收的分组包含差错的非确认(negative acknowledge character，NACK)信号，并且进行自动请求重发。

四、缓存抗抖动(Jitter)策略；

具体地，利用抖动缓冲区对数据包丢失、乱序、延迟到达等情况进行处理，平滑的向解码模块输出音频帧，抵抗各种弱网情况对播放或渲染造成的影响，降低卡顿。

再次，本申请实施例中，提供了一种基于数据传输策略接收第二音频数据的方式。通过上述方式，能够当出现弱网络情况时，仍然能够在接收端保持较好的通信质量。

结合上述实施例，下面将结合图示介绍端到端的处理流程。请参阅图10，图10为本申请实施例中基于音频引擎实现端到端语音处理的一个示意图，如图所示，以APP语音系统为GME作为示例，基于音频引擎的插件化解决方案主要涉及客户端的集成，服务端的能力以GME语音服务器集群来表示。音频引擎标根据具体功能分为四个类型的插件，分别是采集插件、发送插件、接收插件和播放插件，这四个插件充当语音SDK和音频引擎交换数据的桥梁。其中，采集插件和接收插件用于将语音信号推送入音频引擎进行后续处理，而发送插件和播放插件用于从音频引擎将语音信号输出到SDK。此外，音频引擎内置处理能力和音频控制能力，音效师利用这些处理能力和控制能力来实现APP内的各种声音效果。由此，将语音数据也送入了音频引擎，因此，音频的处理能力同样适用于语音处理。

基于这种插件化的音频引擎处理方案，语音数据从接收到发送的处理流程包括如下：

(1)语音前处理：GME通过系统API获取音频输入设备采集的本地用户语音，前处理技术去除掉录音数据中的回声和噪声，并进行音量均衡和啸叫抑制等处理。

(2)本地用户语音：经过前处理的语音信号通过采集插件之后，可作为音源信号送入到音频引擎。音频引擎内置的处理能力和控制能力可以用来处理送入的语音数据流，并实现和虚拟场景相关联的沉浸式语音音效。经过音频引擎内置能力处理后的语音数据通过发送插件从音频引擎输出到GME语音SDK继续进行下一步处理。

(3)伴随音频数据：通过发送插件还可以把APP本地的音效和/或音乐作为伴随音频数据，并输出到GME语音SDK。经过下一步处理后分享到语音聊天房，音频设计师可基于这个能力设计出有趣和多样的语音玩法。

(4)信源与信道编码：根据语音场景类型，对发送插件输出到GME语音SDK的语音流或者其它音频流进行信源和信道编码，以节约网络传输带宽，并增加弱网络鲁棒性，经过编码的数据将发送至GME语音服务器集群。

(5)GME语音服务器集群：客户端所有的语音需要发送到GME语音服务器，GME语音服务器根据语音聊天房的成员列表，给相应的终端转发目标语音流。GME语音服务器采用鉴权机制保证只有合法的客户端可以连接到GME语音服务器。后台的服务质量(quality ofservice，QoS)策略保证客户端可以连接最近的GME语音服务器，并且提供可靠质量的语音服务。

(6)网络策略与解码：语音在网络上传输需要应对网络的各种问题，基于此，可采用FEC策略、PLC策略、ARQ策略以及缓存抗抖动策略增加对弱网络的抗性。此外，还可以对编码后的语音流解码，然后将解码后的脉冲编码调制(pulse code modulation，PCM)语音流送到下一个环节来处理。

(7)语音混音：GME客户端收到GME语音服务器转发过来的各路用户发送的语音流，这些语音流会在GME客户端进行混音，即，将多路语音流混音成一路语音流。

(8)每路玩家语音流：为了实现和虚拟场景相关联的沉浸式语音音效，需要对每一路接收到的语音流进行单独处理。例如，对每路语音流进行3D处理，距离衰减或者模拟声音反射的处理。经过解码后的每一路语音流通过接收插件作为音源信号送入到音频引擎，音频引擎内置的各种处理能力和控制能力可以处理送入的语音流，以实现和虚拟场景相关联的沉浸式语音音效，处理后的语音数据输出到音频引擎总线和音频引擎的其它音效进行混音。

(9)混音后语音流：如果不需要对每一路语音流进行处理，也可以将在第7步已经进行混音的语音数据通过接收插件作为音源信号送入到音频引擎处理管线，处理后的语音数据输出到音频引擎总线和音频引擎的其它音效进行混音。

(10)所有本地音效或音乐：音频设计师使用音频引擎设计和处理常规声音，包括游戏中非语音的其他声音。

(11)音频流总线：通过音频引擎处理后的声音都会经过音频流总线，再送入到音频输出设备进行播放。音频引擎会根据音频输出设备的声道数，采样频率和格式(即，基于声道的音频或者基于对象的音频)进行相应的混音和采样率转化。

(12)播放插件：音频引擎处理后的声音数据会送入到播放插件，播放插件除了做一些鉴权相关的配置工作，还会将音频引擎输出的所有声音数据旁路给GME的回声消除模块。回声消除模块根据参考信号来消除掉音频输入设备(例如，麦克风)录音信号中的回声，这个回声是指音频输入设备录制的从音频输出设备(例如，扬声器)中播放的任何本地音频，从而使待发送到语音房间的信号只含有本地用户的语音。

(13)语音后处理：在语音渲染前进行的一些信号处理，从而使语音在具体的设备播放时更加清晰。

下面对本申请中的音频数据处理装置进行详细描述，请参阅图11，图11为本申请实施例中音频数据处理装置的一个实施例示意图，音频数据处理装置30包括：

获取模块310，用于获取来源于第一对象的第一语音数据；

获取模块310，还用于响应于第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，第一虚拟对象为第一对象控制的虚拟对象，场景关联信息包括第一虚拟对象在虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

获取模块310，还用于根据场景关联信息，获取针对第一语音数据的第一调整数据，其中，第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，音频属性参数用于对语音数据的播放效果，伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

处理模块320，用于采用第一调整数据，对第一语音数据进行处理，得到第一音频数据；

播放模块330，用于实现对第一音频数据的播放。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，将语音组件插件化之后引入到终端本地的音频引擎中，能够把语音数据直接送入到音频引擎中进行处理。即，根据虚拟对象在虚拟场景的场景关联信息，生成符合当前场景效果的调整数据。利用调整数据对实时的语音数据进行处理，以达到丰富的声音处理效果，实现随场景变化的沉浸式语音效果。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

获取模块310，具体用于通过音频输入设备采集来源于第一对象的原始语音数据；

对原始语音数据进行语音前处理，得到第一处理语音数据，其中，语音前处理包括降噪处理，回声消除处理，音量均衡处理以及啸叫抑制处理中的至少一项；

对第一处理语音数据进行音频帧转换处理，得到第一语音数据，其中，音频帧转换处理包括采样率转换处理，声道转换处理、采样深度转换处理以及音频帧长处理中的至少一项。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，对于采集到的用户语音数据进行语音前处理，使得处理后的语音数据更能代表语音的本质特征，从而达到更好的音频处理效果。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

获取模块310，具体用于对第一处理语音数据进行音频帧转换处理，得到第一音频帧序列，其中，第一音频帧序列包括至少一个第一音频帧；

对第一音频帧序列进行采样，得到每个第一音频帧的第一采样点数据集合，其中，第一采样点数据集合包括M个采样点数据，M为大于1的整数；

将每个第一音频帧的第一采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第二采样点数据集合，其中，每个第二采样点数据集合包括N个采样点数据，N为大于1的整数；

根据至少一个第二采样点数据集合，生成第一语音数据，其中，第一语音数据包括至少一个第二音频帧，每个第二音频帧对应于一个第二采样点数据集合。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，场景关联信息包括位置信息，第一调整数据包括音频属性参数；

获取模块310，具体用于根据位置信息确定第一虚拟对象在虚拟场景中的空间类型；

若空间类型属于第一空间类型，则确定针对第一语音数据的音频属性参数包括混响调整参数，其中，第一空间类型表示在虚拟场景中小于或等于空间尺寸阈值的虚拟空间；

若空间类型属于第二空间类型，则确定针对第一语音数据的音频属性参数包括回声调整参数，其中，第二空间类型表示在虚拟场景中大于空间尺寸阈值的虚拟空间。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，结合虚拟对象在虚拟场景中的位置信息，能够模拟用户在现实环境下感知到的语音效果。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，场景关联信息包括环境信息，第一调整数据包括伴随音频数据；

获取模块310，具体用于若环境信息指示第一虚拟对象处于室内环境，则确定针对第一语音数据的伴随音频数据包括基于室内环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于户外环境，则确定针对第一语音数据的伴随音频数据包括基于户外环境录制得到的音频数据；

若环境信息指示第一虚拟对象处于天气环境，则确定针对第一语音数据的伴随音频数据包括基于天气环境录制得到的音频数据。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，结合虚拟对象在虚拟场景中的环境信息，能够模拟用户在现实环境下感知到的语音效果。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，场景关联信息包括情绪信息，第一调整数据包括音频属性参数；

获取模块310，具体用于若情绪信息指示第一虚拟对象处于第一情绪状态，则确定针对第一语音数据的音频属性参数包括时域调整参数、第一频域调整参数以及升调调整参数中的至少一项，其中，时域调整参数用于提高语音音头，第一频域调整参数用于增强语音高频分量；

若情绪信息指示第一虚拟对象处于第二情绪状态，则确定针对第一语音数据的音频属性参数包括语速调整参数以及周期调整参数中的至少一项，其中，语速调整参数用于减慢语速，周期调整参数用于周期性地改变语调；

若情绪信息指示第一虚拟对象处于第三情绪状态，则确定针对第一语音数据的音频属性参数包括第二频域调整参数以及降调调整参数中的至少一项，其中，第二频域调整参数用于增强语音数据的低频分量。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，结合虚拟对象在虚拟场景中的情绪信息，能够模拟用户在现实环境下的情绪，体现出虚拟对象的性格和状态。从而能够更加接近真实环境下声音的传播，为用户提供沉浸式语音的效果。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，场景关联信息包括角色信息，第一调整数据包括音频属性参数；

获取模块310，具体用于若角色信息指示第一虚拟对象属于目标角色类型，则确定针对第一语音数据的音频属性参数包括音高调整参数、音色调整参数以及共振峰调整参数。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，结合虚拟对象在虚拟场景中的角色信息，能够模拟出符合角色信的特定语音变声效果。从而增加趣味性，并适用于特定使用场景(例如，对特定声优配音等)。

在一种可能的设计中，在本申请实施例的另一方面的另一种实现方式中，第一调整数据包括音频属性参数以及伴随音频数据；

处理模块320，具体用于采用音频属性参数，对第一语音数据进行调整，得到目标语音数据；

对目标语音数据进行语音后处理，得到第二处理语音数据，其中，语音后处理包括语音增强处理，频段增益处理以及调音处理中的至少一项；

将伴随音频数据与第二处理语音数据进行叠加，得到第一音频数据。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，实现了将语音设计融合到了APP音效设计中，开阔了音效设计师设计语音的思路。基于此，有利于发展语音端到端处理的生态，使得其它专业处理算法和中间件也可以加入到生态中，共同提升用户的语音体验。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

播放模块330，具体用于响应于音频播放操作，通过音频输出设备播放第一音频数据。

或者，

播放模块330，具体用于向第二终端发送第一音频数据，以使第二终端通过音频输出设备播放第一音频数据。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，不仅支持本地终端播放第一音频数据，还支持远端终端播放第一音频数据。因此，增加了语音数据播放的灵活性和多样性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

播放模块330，具体用于获取语音场景类型；

若语音场景类型属于第一场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为单声道的音频数据，且，第一音频数据采用第一采样率；

若语音场景类型属于第二场景类型，则向第二终端发送第一音频数据，其中，第一音频数据为立体声道的音频数据，且，第一音频数据采用第二采样率，第二采样率高于第一采样率。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，可基于语音场景类型，对音频数据进行信源和信道编码，以节约网络传输带宽，并增加弱网络鲁棒性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

播放模块330，具体用于对第一音频数据进行分帧处理，得到第二音频帧序列，其中，第二音频帧序列包括至少一个第三音频帧；

对第二音频帧序列进行采样，得到每个第三音频帧的第三采样点数据集合，其中，第三采样点数据集合包括P个采样点数据，P为大于1的整数；

将每个第三音频帧的第三采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第四采样点数据集合，其中，每个第四采样点数据集合包括Q个采样点数据，Q为大于1的整数；

对至少一个第四采样点数据集合进行音频帧转换处理，并向第二终端发送处理后的第一音频数据，其中，第一音频数据包括至少一个第四音频帧，每个第四音频帧对应于一个第四采样点数据集合。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，音频数据处理装置还包括接收模块340；

接收模块340，用于接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

播放模块330，还用于播放第二音频数据。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，可直接播放远端传输过来的音频数据。由于该音频数据也是跟随虚拟场景变化而变化的，因此，能够使得用户听到的语音具有更强的氛围感，从而提升用户体验。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

播放模块330，具体用于对第二音频数据进行分帧处理，得到第三音频帧序列，其中，第三音频帧序列包括至少一个第五音频帧；

对第三音频帧序列进行采样，得到每个第五音频帧的第五采样点数据集合，其中，第五采样点数据集合包括X个采样点数据，X为大于1的整数；

将每个第五音频帧的第五采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第六采样点数据集合，其中，每个第六采样点数据集合包括Y个采样点数据，Y为大于1的整数；

对至少一个第六采样点数据集合进行音频帧转换处理，并播放处理后的第二音频数据，其中，第二音频数据包括至少一个第六音频帧，每个第六音频帧对应于一个第六采样点数据集合。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

接收模块340，还用于接收第二终端发送的第二音频数据，其中，第二音频数据为第二终端采用第二调整数据对第二语音数据进行处理后得到的，第二语音数据来源于第二对象，第二调整数据为根据第二虚拟对象针对虚拟场景的场景关联信息得到的，第二虚拟对象为第二对象控制的虚拟对象；

获取模块310，还用于响应于第二音频数据，根据第一虚拟对象与第二虚拟对象在对虚拟场景中的位置信息，获取对象关联信息；

获取模块310，还用于根据对象关联信息，获取针对第二音频数据的第三调整数据；

处理模块320，还用于采用第三调整数据，对第二音频数据进行处理，得到第三音频数据；

播放模块330，还用于播放第三音频数据。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，可对远端传输过来的音频数据作进一步优化。由此，音频数据不仅能够跟随虚拟场景变化而变化，而且还考虑到虚拟对象之间的相对位置，从而使得用户听到的语音具有更强的真实感，以提升用户体验。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

播放模块330，具体用于对第三音频数据进行分帧处理，得到第四音频帧序列，其中，第四音频帧序列包括至少一个第七音频帧；

对第四音频帧序列进行采样，得到每个第七音频帧的第七采样点数据集合，其中，第七采样点数据集合包括S个采样点数据，S为大于1的整数；

将每个第七音频帧的第七采样点数据集合写入环形缓冲区；

从环形缓冲区中读取至少一个第八采样点数据集合，其中，每个第八采样点数据集合包括R个采样点数据，R为大于1的整数；

对至少一个第八采样点数据集合进行音频帧转换处理，并播放处理后的第三音频数据，其中，第三音频数据包括至少一个第八音频帧，每个第八音频帧对应于一个第八采样点数据集合。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，考虑到APP语音系统与音频引擎都是用于处理数字音频信号的，且，两个系统处理的音频信号处理参数可能不一样。因此，为了让两部分系统能够交互音频数据，可在数据交换时进行转换和统一，由此，保证了音频处理的可行性和可操作性。

可选地，在上述图11所对应的实施例的基础上，本申请实施例提供的音频数据处理装置30的另一实施例中，

接收模块340，具体用于基于数据传输策略，接收第二终端发送的第二音频数据，其中，数据传输策略包括前向纠错策略、丢包补偿策略、自动重传策略以及缓存抗抖动策略中的至少一种，前向纠错策略用于纠正数据传输过程中出现的错误码，丢包补偿策略用于补偿缺失的音频帧，自动重传策略用于请求重传音频帧，缓存抗抖动策略用于在数据传输过程中采用动态缓存。

本申请实施例中，提供了一种音频数据处理装置。采用上述装置，能够当出现弱网络情况时，仍然能够在接收端保持较好的通信质量。

本申请实施例还提供了一种终端，如图12参照本申请实施例方法部分。在本申请实施例中，以终端为手机为例进行说明：

图12示出的是与本申请实施例提供的终端相关的手机的部分结构的框图。参考图12，手机包括：射频(radio frequency，RF)电路410、存储器420、输入单元430、显示单元440、传感器450、音频电路460、无线保真(wireless fidelity，WiFi)模块470、处理器480、以及电源490等部件。本领域技术人员可以理解，图12中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图12对手机的各个构成部件进行具体的介绍：

RF电路410可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器480处理；另外，将设计上行的数据发送给基站。通常，RF电路410包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(low noiseamplifier，LNA)、双工器等。此外，RF电路410还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(globalsystem of mobile communication，GSM)、通用分组无线服务(general packet radioservice，GPRS)、码分多址(code division multiple access，CDMA)、宽带码分多址(wideband code division multiple access,WCDMA)、长期演进(long term evolution，LTE)、电子邮件、短消息服务(short messaging service，SMS)等。

存储器420可用于存储软件程序以及模块，处理器480通过运行存储在存储器420的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器420可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器420可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元430可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元430可包括触控面板431以及其他输入设备432。触控面板431，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板431上或在触控面板431附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板431可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器480，并能接收处理器480发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板431。除了触控面板431，输入单元430还可以包括其他输入设备432。具体地，其他输入设备432可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、鼠标、操作杆等中的一种或多种。

显示单元440可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元440可包括显示面板441，可选的，可以采用液晶显示器(liquid crystaldisplay，LCD)、有机发光二极管(organic light-emitting diode，OLED)等形式来配置显示面板441。进一步的，触控面板431可覆盖显示面板441，当触控面板431检测到在其上或附近的触摸操作后，传送给处理器480以确定触摸事件的类型，随后处理器480根据触摸事件的类型在显示面板441上提供相应的视觉输出。虽然在图12中，触控面板431与显示面板441是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板431与显示面板441集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器450，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板441的亮度，接近传感器可在手机移动到耳边时，关闭显示面板441和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路460、扬声器461，传声器462可提供用户与手机之间的音频接口。音频电路460可将接收到的音频数据转换后的电信号，传输到扬声器461，由扬声器461转换为声音信号输出；另一方面，传声器462将收集的声音信号转换为电信号，由音频电路460接收后转换为音频数据，再将音频数据输出处理器480处理后，经RF电路410以发送给比如另一手机，或者将音频数据输出至存储器420以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块470可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图12示出了WiFi模块470，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器480是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器420内的软件程序和/或模块，以及调用存储在存储器420内的数据，执行手机的各种功能和处理数据。可选的，处理器480可包括一个或多个处理单元；可选的，处理器480可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器480中。

手机还包括给各个部件供电的电源490(比如电池)，可选的，电源可以通过电源管理系统与处理器480逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

上述实施例中由终端所执行的步骤可以基于该图12所示的终端结构。

本申请实施例中还提供一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，该处理器执行计算机程序时，实现前述各个实施例描述方法的步骤。

本申请实施例中还提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现前述各个实施例描述方法的步骤。

本申请实施例中还提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时，实现前述各个实施例描述方法的步骤。

可以理解的是，在本申请的具体实施方式中，涉及到用户语音数据等相关的数据，当本申请以上实施例运用到具体产品或技术中时，需要获得用户许可或者同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是服务器或终端等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储计算机程序的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (20)

1.一种音频数据处理方法，其特征在于，应用于第一终端，所述方法包括：

获取来源于第一对象的第一语音数据；

响应于所述第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，所述第一虚拟对象为所述第一对象控制的虚拟对象，所述场景关联信息包括所述第一虚拟对象在所述虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，其中，所述第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，所述音频属性参数用于对语音数据的播放效果，所述伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

采用所述第一调整数据，对所述第一语音数据进行处理，得到第一音频数据；

实现对所述第一音频数据的播放。

2.根据权利要求1所述的方法，其特征在于，所述获取来源于第一对象的第一语音数据，包括：

通过音频输入设备采集来源于所述第一对象的原始语音数据；

对所述原始语音数据进行语音前处理，得到第一处理语音数据，其中，所述语音前处理包括降噪处理，回声消除处理，音量均衡处理以及啸叫抑制处理中的至少一项；

对所述第一处理语音数据进行音频帧转换处理，得到所述第一语音数据，其中，所述音频帧转换处理包括采样率转换处理，声道转换处理、采样深度转换处理以及音频帧长处理中的至少一项。

3.根据权利要求2所述的方法，其特征在于，所述对所述第一处理语音数据进行音频帧转换处理，得到所述第一语音数据，包括：

对所述第一处理语音数据进行音频帧转换处理，得到第一音频帧序列，其中，所述第一音频帧序列包括至少一个第一音频帧；

对所述第一音频帧序列进行采样，得到每个第一音频帧的第一采样点数据集合，其中，所述第一采样点数据集合包括M个采样点数据，所述M为大于1的整数；

将所述每个第一音频帧的所述第一采样点数据集合写入环形缓冲区；

从所述环形缓冲区中读取至少一个第二采样点数据集合，其中，每个第二采样点数据集合包括N个采样点数据，所述N为大于1的整数；

根据所述至少一个第二采样点数据集合，生成所述第一语音数据，其中，所述第一语音数据包括至少一个第二音频帧，每个第二音频帧对应于一个第二采样点数据集合。

4.根据权利要求1所述的方法，其特征在于，所述场景关联信息包括所述位置信息，所述第一调整数据包括所述音频属性参数；

所述根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，包括：

根据所述位置信息确定所述第一虚拟对象在所述虚拟场景中的空间类型；

若所述空间类型属于第一空间类型，则确定针对所述第一语音数据的所述音频属性参数包括混响调整参数，其中，所述第一空间类型表示在所述虚拟场景中小于或等于空间尺寸阈值的虚拟空间；

若所述空间类型属于第二空间类型，则确定针对所述第一语音数据的所述音频属性参数包括回声调整参数，其中，所述第二空间类型表示在所述虚拟场景中大于所述空间尺寸阈值的虚拟空间。

5.根据权利要求1所述的方法，其特征在于，所述场景关联信息包括所述环境信息，所述第一调整数据包括所述伴随音频数据；

所述根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，包括：

若所述环境信息指示所述第一虚拟对象处于室内环境，则确定针对所述第一语音数据的所述伴随音频数据包括基于所述室内环境录制得到的音频数据；

若所述环境信息指示所述第一虚拟对象处于户外环境，则确定针对所述第一语音数据的所述伴随音频数据包括基于所述户外环境录制得到的音频数据；

若所述环境信息指示所述第一虚拟对象处于天气环境，则确定针对所述第一语音数据的所述伴随音频数据包括基于所述天气环境录制得到的音频数据。

6.根据权利要求1所述的方法，其特征在于，所述场景关联信息包括所述情绪信息，所述第一调整数据包括所述音频属性参数；

所述根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，包括：

若所述情绪信息指示所述第一虚拟对象处于第一情绪状态，则确定针对所述第一语音数据的所述音频属性参数包括时域调整参数、第一频域调整参数以及升调调整参数中的至少一项，其中，所述时域调整参数用于提高语音音头，所述第一频域调整参数用于增强语音高频分量；

若所述情绪信息指示所述第一虚拟对象处于第二情绪状态，则确定针对所述第一语音数据的所述音频属性参数包括语速调整参数以及周期调整参数中的至少一项，其中，所述语速调整参数用于减慢语速，所述周期调整参数用于周期性地改变语调；

若所述情绪信息指示所述第一虚拟对象处于第三情绪状态，则确定针对所述第一语音数据的所述音频属性参数包括第二频域调整参数以及降调调整参数中的至少一项，其中，所述第二频域调整参数用于增强语音数据的低频分量。

7.根据权利要求1所述的方法，其特征在于，所述场景关联信息包括所述角色信息，所述第一调整数据包括所述音频属性参数；

所述根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，包括：

若所述角色信息指示所述第一虚拟对象属于目标角色类型，则确定针对所述第一语音数据的所述音频属性参数包括音高调整参数、音色调整参数以及共振峰调整参数。

8.根据权利要求1所述的方法，其特征在于，所述第一调整数据包括所述音频属性参数以及所述伴随音频数据；

所述采用所述第一调整数据，对所述第一语音数据进行处理，得到第一音频数据，包括：

采用所述音频属性参数，对所述第一语音数据进行调整，得到目标语音数据；

对所述目标语音数据进行语音后处理，得到第二处理语音数据，其中，所述语音后处理包括语音增强处理，频段增益处理以及调音处理中的至少一项；

将所述伴随音频数据与所述第二处理语音数据进行叠加，得到所述第一音频数据。

9.根据权利要求1所述的方法，其特征在于，所述实现对所述第一音频数据的播放，包括：

响应于音频播放操作，通过音频输出设备播放所述第一音频数据；

或者，

所述实现对所述第一音频数据的播放，包括：

向第二终端发送所述第一音频数据，以使所述第二终端通过音频输出设备播放所述第一音频数据。

10.根据权利要求9所述的方法，其特征在于，所述向第二终端发送所述第一音频数据，包括：

获取语音场景类型；

若所述语音场景类型属于第一场景类型，则向第二终端发送所述第一音频数据，其中，所述第一音频数据为单声道的音频数据，且，所述第一音频数据采用第一采样率；

若所述语音场景类型属于第二场景类型，则向第二终端发送所述第一音频数据，其中，所述第一音频数据为立体声道的音频数据，且，所述第一音频数据采用第二采样率，所述第二采样率高于所述第一采样率。

11.根据权利要求9所述的方法，其特征在于，所述向第二终端发送所述第一音频数据，包括：

对所述第一音频数据进行分帧处理，得到第二音频帧序列，其中，所述第二音频帧序列包括至少一个第三音频帧；

对所述第二音频帧序列进行采样，得到每个第三音频帧的第三采样点数据集合，其中，所述第三采样点数据集合包括P个采样点数据，所述P为大于1的整数；

将所述每个第三音频帧的所述第三采样点数据集合写入环形缓冲区；

从所述环形缓冲区中读取至少一个第四采样点数据集合，其中，每个第四采样点数据集合包括Q个采样点数据，所述Q为大于1的整数；

对所述至少一个第四采样点数据集合进行音频帧转换处理，并向所述第二终端发送处理后的所述第一音频数据，其中，所述第一音频数据包括至少一个第四音频帧，每个第四音频帧对应于一个第四采样点数据集合。

12.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收第二终端发送的第二音频数据，其中，所述第二音频数据为所述第二终端采用第二调整数据对第二语音数据进行处理后得到的，所述第二语音数据来源于第二对象，所述第二调整数据为根据第二虚拟对象针对所述虚拟场景的场景关联信息得到的，所述第二虚拟对象为所述第二对象控制的虚拟对象；

播放所述第二音频数据。

13.根据权利要求12所述的方法，其特征在于，所述播放所述第二音频数据，包括：

对所述第二音频数据进行分帧处理，得到第三音频帧序列，其中，所述第三音频帧序列包括至少一个第五音频帧；

对所述第三音频帧序列进行采样，得到每个第五音频帧的第五采样点数据集合，其中，所述第五采样点数据集合包括X个采样点数据，所述X为大于1的整数；

将所述每个第五音频帧的所述第五采样点数据集合写入环形缓冲区；

从所述环形缓冲区中读取至少一个第六采样点数据集合，其中，每个第六采样点数据集合包括Y个采样点数据，所述Y为大于1的整数；

对所述至少一个第六采样点数据集合进行音频帧转换处理，并播放处理后的所述第二音频数据，其中，所述第二音频数据包括至少一个第六音频帧，每个第六音频帧对应于一个第六采样点数据集合。

14.根据权利要求1所述的方法，其特征在于，所述方法还包括：

接收第二终端发送的第二音频数据，其中，所述第二音频数据为所述第二终端采用第二调整数据对第二语音数据进行处理后得到的，所述第二语音数据来源于第二对象，所述第二调整数据为根据第二虚拟对象针对所述虚拟场景的场景关联信息得到的，所述第二虚拟对象为所述第二对象控制的虚拟对象；

响应于所述第二音频数据，根据所述第一虚拟对象与所述第二虚拟对象在对所述虚拟场景中的位置信息，获取对象关联信息；

根据所述对象关联信息，获取针对所述第二音频数据的第三调整数据；

采用所述第三调整数据，对所述第二音频数据进行处理，得到第三音频数据；

播放所述第三音频数据。

15.根据权利要求14所述的方法，其特征在于，所述播放所述第三音频数据，包括：

对所述第三音频数据进行分帧处理，得到第四音频帧序列，其中，所述第四音频帧序列包括至少一个第七音频帧；

对所述第四音频帧序列进行采样，得到每个第七音频帧的第七采样点数据集合，其中，所述第七采样点数据集合包括S个采样点数据，所述S为大于1的整数；

将所述每个第七音频帧的所述第七采样点数据集合写入环形缓冲区；

从所述环形缓冲区中读取至少一个第八采样点数据集合，其中，每个第八采样点数据集合包括R个采样点数据，所述R为大于1的整数；

对所述至少一个第八采样点数据集合进行音频帧转换处理，并播放处理后的所述第三音频数据，其中，所述第三音频数据包括至少一个第八音频帧，每个第八音频帧对应于一个第八采样点数据集合。

16.根据权利要求12至15中任一项所述的方法，其特征在于，所述接收第二终端发送的第二音频数据，包括：

基于数据传输策略，接收所述第二终端发送的所述第二音频数据，其中，所述数据传输策略包括前向纠错策略、丢包补偿策略、自动重传策略以及缓存抗抖动策略中的至少一种，所述前向纠错策略用于纠正数据传输过程中出现的错误码，所述丢包补偿策略用于补偿缺失的音频帧，所述自动重传策略用于请求重传音频帧，所述缓存抗抖动策略用于在数据传输过程中采用动态缓存。

17.一种音频数据处理装置，其特征在于，应用于第一终端，所述音频数据处理装置包括：

获取模块，用于获取来源于第一对象的第一语音数据；

所述获取模块，还用于响应于所述第一语音数据，获取第一虚拟对象针对虚拟场景的场景关联信息，其中，所述第一虚拟对象为所述第一对象控制的虚拟对象，所述场景关联信息包括所述第一虚拟对象在所述虚拟场景中的位置信息、环境信息、情绪信息以及角色信息中的至少一项；

所述获取模块，还用于根据所述场景关联信息，获取针对所述第一语音数据的第一调整数据，其中，所述第一调整数据包括音频属性参数以及伴随音频数据中的至少一项，所述音频属性参数用于对语音数据的播放效果，所述伴随音频数据用于提供背景音乐以及背景音效中的至少一项；

处理模块，用于采用所述第一调整数据，对所述第一语音数据进行处理，得到第一音频数据；

播放模块，用于实现对所述第一音频数据的播放。

18.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至16中任一项所述的方法的步骤。

19.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至16中任一项所述的方法的步骤。

20.一种计算机程序产品，包括计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至16中任一项所述的方法的步骤。