CN111596885A - 音频数据处理方法、服务器及存储介质 - Google Patents

Abstract

本申请实施例公开了一种音频数据处理方法、服务器及存储介质，属于计算机技术领域。方法应用于服务器，服务器包括云应用程序、系统框架、中转程序和音频采集程序，方法包括：将云应用程序的第一音频数据输入至系统框架；通过系统框架对第一音频数据进行处理，得到第二音频数据，将第二音频数据发送至中转程序；通过中转程序，根据中转程序与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序，音频采集程序用于将第二音频数据发送至终端本地的应用程序。在云服务器中，通过中转程序直接将系统框架处理后的第二音频数据发送至音频采集程序，减少了音频数据的传输链路，减小了云服务器下发音频数据的延时。

Description

音频数据处理方法、服务器及存储介质

技术领域

本申请涉及计算机技术领域，特别涉及一种音频数据处理方法、服务器及存储介质。

背景技术

云应用程序是指在服务器上运行的应用程序，服务器运行云应用程序，生成相应的音频数据，将该音频数据下发至终端本地的应用程序进行播放，终端本地的应用程序只需对该音频数据进行播放即可。

目前，服务器为音频采集程序提供AudioRecord（音频录制）接口。在云应用程序运行过程中服务器会通过录制线程来录制音频数据，音频采集程序即可调用AudioRecord接口，从录制线程中读取录制的音频数据，然后发送给终端本地的应用程序。

由于上述过程需要先对音频数据进行录制再进行读取，耗费的时间较长，造成了较大的延时。

发明内容

本申请实施例提供了一种音频数据处理方法、服务器及存储介质，能够减小服务器下发音频数据的延时。所述技术方案如下所示。

一方面，提供了一种音频数据处理方法，所述方法应用于服务器，所述服务器包括云应用程序、系统框架、中转程序和音频采集程序，所述方法包括：将所述云应用程序的第一音频数据输入至所述系统框架；通过所述系统框架对所述第一音频数据进行处理，得到第二音频数据，将所述第二音频数据发送至所述中转程序；通过所述中转程序，根据所述中转程序与所述音频采集程序之间的通信连接，将所述第二音频数据发送至所述音频采集程序，所述音频采集程序用于将所述第二音频数据发送至终端本地的应用程序。

可选地，所述中转程序为重采样程序，所述通过所述系统框架，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据之前，所述方法还包括：通过所述系统框架从所述重采样程序获取所述音频参数，所述重采样程序配置有所述音频参数。

另一方面，提供了一种延时获取方法，所述方法应用于服务器，所述服务器包括检测应用程序、系统框架、中转程序和音频采集程序，所述方法包括：将所述检测应用程序的第一检测音频数据输入至所述系统框架，记录所述第一检测音频数据的发送时间；通过所述系统框架对所述第一检测音频数据进行处理，得到第二检测音频数据，将所述第二检测音频数据发送至所述中转程序；通过所述中转程序，根据所述中转程序与所述音频采集程序之间的通信连接，将所述第二检测音频数据发送至所述音频采集程序，记录所述音频采集程序接收所述第二检测音频数据的第一接收时间，所述音频采集程序用于将所述第二检测音频数据发送至终端本地的应用程序；获取所述发送时间和所述第一接收时间之间的第一时间差，所述第一时间差表示检测音频数据从所述检测应用程序传输至所述音频采集程序的延时。

可选地，所述中转程序为硬件抽象层；或者，所述中转程序为重采样程序。

另一方面，提供了一种服务器，所述服务器包括应用运行模块、框架运行模块、中转模块和采集模块；所述应用运行模块，用于将云应用程序的第一音频数据输入至所述框架运行模块；所述框架运行模块，用于对所述第一音频数据进行处理，得到第二音频数据，将所述第二音频数据发送至所述中转模块；所述中转模块，用于根据所述中转模块与所述采集模块之间的通信连接，将所述第二音频数据发送至所述采集模块，所述采集模块用于将所述第二音频数据发送至终端本地的应用程序。

可选地，所述框架运行模块，用于若所述中转模块与所述采集模块已建立通信连接，则将所述第二音频数据发送至所述中转模块；所述框架运行模块，用于若所述中转模块还未与所述采集模块建立通信连接，则控制所述中转模块与所述采集模块建立通信连接，在所述中转模块与所述采集模块成功建立通信连接的情况下，将所述第二音频数据发送至所述中转模块。

可选地，所述框架运行模块，用于对所述第一音频数据进行混音处理，得到第三音频数据，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据。

可选地，所述框架运行模块用于执行以下至少一项：所述音频参数包括目标采样率，按照所述目标采样率对所述第三音频数据进行重采样处理，得到所述第二音频数据；所述音频参数包括目标通道数，按照所述目标通道数对所述第三音频数据进行通道数转换处理，得到所述第二的音频数据；所述音频参数包括目标采样深度，按照所述目标采样深度对所述第三音频数据进行重采样处理，得到所述第二音频数据。

可选地，所述框架运行模块包括处理单元，所述处理单元，用于对所述第一音频数据进行混音处理，得到所述第三音频数据；所述处理单元，还用于按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据。

可选地，所述中转模块为硬件抽象层运行模块，所述框架运行模块，用于从所述硬件抽象层运行模块获取所述音频参数，所述硬件抽象层运行模块存储有所述音频参数。

可选地，所述中转模块为硬件抽象层运行模块，所述框架运行模块，用于调用所述硬件抽象层运行模块的写入接口，将所述第二音频数据写入所述硬件抽象层运行模块。

可选地，所述中转模块为重采样模块，所述框架运行模块，还用于从所述重采样模块获取所述音频参数，所述重采样模块配置有所述音频参数。

可选地，所述中转模块为重采样模块；所述重采样模块，还用于对所述第二音频数据进行重采样处理，得到处理后的第二音频数据；所述重采样模块，用于根据所述重采样模块与所述采集模块之间的通信连接，将所述处理后的第二音频数据发送至所述采集模块。

可选地，所述框架运行模块包括录制单元；所述重采样模块，用于将所述第二音频数据发送至所述录制单元；所述录制单元，用于对所述第二音频数据进行录制，得到第三音频数据；所述采集模块，用于调用音频录制接口，从所述录制单元中读取所述第三音频数据。

可选地，所述采集模块，用于丢弃所述第三音频数据，将所述第二音频数据发送至所述终端本地的应用程序。

一方面，提供了一种服务器，所述服务器包括应用运行模块、框架运行模块、中转模块、采集模块、记录模块和获取模块，所述应用运行模块，用于将检测应用程序的第一检测音频数据输入至所述框架运行模块；所述记录模块，用于记录所述第一检测音频数据的发送时间；所述框架运行模块，用于对所述第一检测音频数据进行处理，得到第二检测音频数据，将所述第二检测音频数据发送至所述中转模块；所述中转模块，用于根据所述中转模块与所述采集模块之间的通信连接，将所述第二检测音频数据发送至所述采集模块，所述采集模块用于将所述第二检测音频数据发送至终端本地的应用程序；所述记录模块，还用于记录所述采集模块接收所述第二检测音频数据的第一接收时间；所述获取模块，用于获取所述发送时间和所述第一接收时间的第一时间差，所述第一时间差表示检测音频数据从所述应用运行模块传输至所述采集模块的延时。

可选地，所述记录模块，还用于记录所述中转模块接收所述第二检测音频数据的第二接收时间；所述获取模块，用于获取所述发送时间与所述第二接收时间之间的第二时间差，所述第二时间差表示检测音频数据从所述应用运行模块传输至所述中转模块的延时。

可选地，所述中转模块为硬件抽象层运行模块；或者，所述中转模块为重采样模块。

另一方面，提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行以实现如上述方面所述的音频数据处理方法中所执行的操作；或者，以实现如上述方面所述的延时获取方法中所执行的操作。

再一方面，提供了一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机程序代码，所述计算机程序代码存储在计算机可读存储介质中。计算机设备的处理器从所述计算机可读存储介质读取所述计算机程序代码，所述处理器执行所述计算机程序代码，使得所述计算机设备实现如上述方面所述的音频数据处理方法中所执行的操作；或者，实现如上述方面所述的延时获取方法中所执行的操作。

本申请实施例提供的技术方案带来的有益效果至少包括：

本申请实施例提供的音频数据处理方法、服务器及存储介质，在系统框架和音频采集程序之间设置了中转程序，且建立了中转程序与音频采集程序之间的通信连接，通过该通信连接能够直接将系统框架处理后的音频数据发送至该音频采集程序。与音频采集程序通过调用音频录制接口从录制线程中读取音频数据相比，上述通过通信连接直接发送音频数据的方式，减少了音频数据的传输链路，缩短了音频采集程序获取到音频数据的时长，减小了服务器下发音频数据的延时。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种实施环境的示意图；

图2是本申请实施例提供的分布式系统应用于区块链系统的一个可选的结构示意图；

图3是本申请实施例提供的一种音频数据处理方法的流程图；

图4是本申请实施例提供的一种服务器向终端下发音频数据过程中，音频数据的传输流程图；

图5是本申请实施例提供的一种音频数据处理方法的流程图；

图6是本申请实施例提供的一种硬件抽象层将音频数据发送至音频采集程序的流程图；

图7是本申请实施例提供的一种服务器向终端下发音频数据过程中，音频数据的传输流程图；

图8是本申请实施例提供的一种音频数据处理方法的流程图；

图9是本申请实施例提供的一种延时获取方法的流程图；

图10是本申请实施例提供的一种延时获取方法的流程图；

图11是本申请实施例提供的一种检测应用程序输出的多个音频数据示意图；

图12是本申请实施例提供的一种服务器中多个程序获取音频数据的延时示意图；

图13是本申请实施例提供的一种延时获取方法的流程图；

图14是本申请实施例提供的一种服务器中多个程序获取音频数据的延时示意图；

图15是本申请实施例提供的一种服务器中多个程序获取音频数据的延时示意图；

图16是本申请实施例提供的一种音频数据处理装置的结构示意图；

图17是本申请实施例提供的另一种音频数据处理装置的结构示意图；

图18是本申请实施例提供的另一种音频数据处理装置的结构示意图；

图19是本申请实施例提供的一种延时获取装置的结构示意图；

图20是本申请实施例提供的一种终端的结构框图；

图21是本申请实施例提供的一种服务器的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

可以理解，本申请所使用的术语“第一”、“第二”等可在本文中用于描述各种概念，但除非特别说明，这些概念不受这些术语限制。这些术语仅用于将一个概念与另一个概念区分。举例来说，在不脱离本申请的范围的情况下，可以将第一音频数据称为第二音频数据，且类似地，可将第二音频数据称为第一音频数据。

在对本申请实施例进行详细说明之前，先对涉及到的概念进行如下解释说明。

1、云应用程序：在服务器中运行的应用程序，可选地，该云应用程序为游戏类应用程序或者音频处理类应用程序等。

2、容器：容器封装了运行应用程序所必需的相关细节，例如操作系统等，一台服务器能够运行多个容器，每个容器里能够运行云应用程序和操作系统，其中，操作系统为任一操作系统，如安卓操作系统、iOS（iPhone Operation System，苹果操作系统）等。

3、硬件抽象层（AudioHal）：处于系统框架和硬件驱动之间，负责接收系统框架下发的音频数据，将该音频数据通过硬件驱动输出到硬件。

4、系统框架：操作系统中提供的一个框架，可选地，为操作系统中的音频处理框架（AudioFlinger）。

5、重采样程序（RemoteSubmix）：操作系统中的一个模块，用于将操作系统中的音频进行混音处理之后通过网络发送到远端。

6、音频采集程序：用于从服务器的操作系统中采集音频数据的程序，能够将采集的音频数据发送至编码模块（WebrtcProxy），由编码模块对该音频数据进行编码后下发至终端的应用程序，可选地，在云应用程序为云游戏程序时，该音频采集程序为CloudGame云游戏后端。

7、音频录制接口（AudioRecord）：操作系统中音频数据采集的接口，音频数据的来源是麦克风、RemoteSubmix等。

8、混音线程（MixerThread）：系统框架中负责混音的线程。

9、录制线程（RecordThread）：系统框架中负责录音的线程。

图1是本申请实施例提供的一种实施环境的示意图，参见图1，该实施环境包括：终端101和服务器102，终端101与服务器102能够通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

其中，终端101是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等设备，但并不局限于此。可选地，服务器102是独立的物理服务器；可选地，服务器102是多个物理服务器构成的服务器集群或者分布式系统；可选地，服务器102是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN（Content Delivery Network，内容分发网络）、以及大数据和人工智能平台等基础云计算服务的云服务器。

其中，服务器102中运行有云应用程序，在云应用程序的运行过程中，云应用程序生成音频数据，服务器102将该音频数据发送至终端101，以使终端101无需运行应用程序，也能够播放应用程序生成的音频数据。

可选地，终端101安装有本地应用程序，用户能够通过本地应用程序向服务器102发送控制指令，服务器102中的云应用程序按照该控制指令运行，生成该控制指令对应的音频数据，服务器102将该音频数据下发至终端101，以使用户通过终端101上的本地应用程序播放音频数据。

可选地，本申请实施例涉及的终端和服务器连接形成分布式系统。以分布式系统为区块链系统为例，参见图2，图2是本申请实施例提供的分布式系统200应用于区块链系统的一个可选的结构示意图，由多个节点201（接入网络中的任意形式的计算设备，如服务器、终端）和客户端202形成，节点之间形成组成的点对点（P2P，Peer To Peer）网络，P2P 协议是一个运行在传输控制协议（TCP，Transmission Control Protocol ）协议之上的应用层协议。在分布式系统中，任何机器如服务器、终端都可以加入而成为节点。

参见图2示出的区块链系统中各节点的功能，涉及的功能包括：

（1）路由，节点具有的基本功能，用于支持节点之间的通信。

节点除具有路由功能外，还可以具有以下功能：

（2）应用，用于部署在区块链中，根据实际业务需求而实现特定业务，记录实现功能相关的数据形成记录数据，在记录数据中携带数字签名以表示任务数据的来源，将记录数据发送到区块链系统中的其他节点，供其他节点在验证记录数据来源以及完整性成功时，将记录数据添加到临时区块中。

例如，多个服务器中分别运行有云应用程序，每个服务器为区块链中的一个节点，该多个服务器运行云应用程序得到的数据同步。

本申请实施例能够应用于云游戏的场景下：

例如，用户通过终端控制云游戏运行，采用本申请实施例提供的音频数据处理方法，将云游戏运行过程中生成的音频数据发送至终端，由终端播放该音频数据，使用户在游戏过程中能够收听音频数据。

由于采用本申请实施例提供的音频数据处理方法，服务器能够更快地将音频数据发送至终端，减小了音频数据的延时，使得用户能够更快地收听到音频数据。

本申请实施例还能够应用于其他由服务器运行云应用程序的场景，本申请实施例对应用场景不做限定。

图3是本申请实施例提供的一种音频数据处理方法的流程图。本申请实施例的执行主体为服务器，参见图3，该方法包括以下步骤。

301、将云应用程序的第一音频数据输入至系统框架。

其中，云应用程序是在服务器中运行的任一应用程序，可选地，该云应用程序为游戏类应用程序，或者，该云应用程序为音频处理类应用程序等。本申请实施例对云应用程序的类型不做限定。第一音频数据为云应用程序在运行过程中生成的音频数据。

302、通过系统框架对第一音频数据进行处理，得到第二音频数据，将第二音频数据发送至中转程序。

系统框架为操作系统中的框架，用于对音频数据进行处理。中转程序为系统框架与音频采集程序之间的程序，用于将系统框架处理的音频数据传输至音频采集程序，该中转程序具有转发音频数据的功能，可选地，中转程序还能够具有其他功能，本申请实施例对此不做限定。

303、通过中转程序，根据中转程序与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序，音频采集程序用于将第二音频数据发送至终端本地的应用程序。

其中，中转程序与音频采集程序之间建立有通信连接，中转程序通过该通信连接，能够直接将第二音频数据发送至音频采集程序。

终端上安装有本地应用程序，该本地应用程序为支持终端与服务器进行交互的应用程序，音频采集程序在接收到第二音频数据之后，将第二音频数据发送至终端的本地应用程序，以使终端播放该第二音频数据，其中，该本地应用程序为步骤303中的终端本地的应用程序。

本申请实施例提供的音频数据处理方法，在系统框架和音频采集程序之间设置了中转程序，且建立了中转程序与音频采集程序之间的通信连接，通过该通信连接能够直接将系统框架处理后的音频数据发送至该音频采集程序。与音频采集程序通过调用音频录制接口从录制线程中读取音频数据相比，上述通过通信连接直接发送音频数据的方式，减少了音频数据的传输链路，缩短了音频采集程序获取到音频数据的时长，减小了服务器下发音频数据的延时。

需要说明的是，上述步骤302和步骤303中的中转程序为硬件抽象层；或者为操作系统中原有的重采样程序；或者，为其他程序，本申请实施例对此不做限定。

首先，本申请实施例以中转程序为硬件抽象层为例，对服务器进行说明。如图4所示，该服务器400包括云应用程序401、系统框架402、硬件抽象层403和音频采集程序404。

其中，云应用程序401能够调用系统框架402的接口，将音频数据写入系统框架402中，系统框架402能够调用硬件抽象层403的接口，将音频数据写入硬件抽象层403中。硬件抽象层403与音频采集程序404之间建立有通信连接，能够将音频数据发送至音频采集程序404。

需要说明的是，上述云应用程序401、系统框架402、硬件抽象层403和音频采集程序404均运行在服务器400的操作系统容器中。

可选地，该服务器400还包括编码程序405，音频采集程序404将音频数据发送至编码程序405，由编码程序405将该音频数据进行编码，并将编码后的音频数据发送至终端本地的应用程序。

在上述图4所示的服务器的基础上，本申请实施例还提供了一种音频数据处理方法，图5是本申请实施例提供的一种音频数据处理方法的流程图，本申请实施例的执行主体为图4所示的服务器，参见图5，该方法包括以下步骤。

501、将云应用程序的第一音频数据输入至系统框架。

其中，云应用程序为服务器中运行的应用程序，本地应用程序为终端安装的应用程序，该本地应用程序为支持终端与服务器进行交互的应用程序，服务器能够将云应用程序运行过程中生成的数据发送至终端的本地应用程序，以使终端展示该数据，因此终端无需运行该云应用程序，也能够获取云应用程序生成的数据。

可选地，用户还能够通过终端的本地应用程序向服务器发送指令，服务器根据该指令运行云应用程序，并将云应用程序生成的数据发送至终端的本地应用程序，使得终端能够控制服务器中云应用程序的运行，并且终端还能够获取云应用程序运行后生成的数据，因此终端无需安装和运行云应用程序，也能使用该云应用程序。

例如，用户在终端的本地应用程序中触发虚拟角色A释放技能a的操作，终端的本地应用程序响应于该操作，向服务器中的云应用程序发送技能释放指令，该技能释放指令携带虚拟角色A的虚拟标识和技能a对应的技能标识，云应用程序在接收到技能释放指令之后，根据该技能释放指令渲染虚拟角色A释放技能a的视频数据，将该视频数据发送至终端的本地应用程序中，由终端的本地应用程序展示该视频数据，以使用户观看到虚拟角色A释放技能a的画面。由此可知，本申请实施例中是通过服务器中的云应用程序和终端的本地应用程序相互配合来实现虚拟角色A释放技能a的操作。

其中，在云应用程序的运行过程中，该云应用程序会生成音频数据，服务器能够将该音频数据发送至终端的本地应用程序，以使终端播放该音频数据或者存储该音频数据等。

例如，云应用程序根据该技能释放指令中的虚拟标识和技能标识，获取第一音频数据，将第一音频数据发送至终端的本地应用程序中，该第一音频数据为虚拟角色A释放技能a对应的技能释放音效，终端的本地应用程序在接收到第一音频数据后，播放该第一音频数据，以使用户听到虚拟角色A释放技能a的技能释放音效。

可选地，该云应用程序存储有多种类型的音频数据，该多种类型的音频数据包括如下类型。

背景音乐：该背景音乐为伴随云应用程序的运行而播放的音频数据，可选地，该云应用程序存储有一个背景音乐，该背景音乐随着云应用程序的运行而循环播放；可选地，该云应用程序存储有多个背景音乐，该多个背景音乐随着云应用程序的运行而循环播放，或者，不同的背景音乐适用于不同的运行阶段，云应用程序根据运行阶段从多个背景音乐中，选取该运行阶段对应的背景音乐进行循环播放。可选地，该云应用程序在运行过程中，还能够渲染视频数据，云应用程序根据渲染的视频数据，从多个背景音乐中，选择该视频数据对应的背景音乐进行循环播放。

音频系统通知：该音频系统通知为云应用程序运行过程中，向终端发送的音频通知消息，例如，云应用程序为游戏类应用程序时，该音频系统通知为“敌方还有XX秒达到站场”、“我方队友XXX被围攻”等，终端接收该音频系统通知后，播放该音频系统通知。

操作音效：该操作音效为伴随操作而播放的音频数据，以使用户有身临其境的感受。例如，用户操作虚拟角色A释放技能，则播放释放技能的音效，使得用户明确感知到自己进行了释放技能的操作，从而使用户产生身临其境的感受。

需要说明的是，上述背景音乐、音频系统通知、操作音效仅是对多种类型的音频数据进行示例性说明，而不对该多种类型的音频数据造成限定。

其中，在云应用程序的运行过程中，云应用程序能够根据当前的运行状态从多种类型的音频数据中选择与当前的运行状态对应的音频数据发送至终端，该第一音频数据为与当前的运行状态对应的音频数据。其中，云应用程序的运行状态包括：云应用程序的启动状态、云应用程序执行操作指令的状态或者云应用程序的加载场景状态等。

可选地，云应用程序在启动过程中，云应用程序从多种类型的音频数据中选择启动状态对应的音频数据，该音频数据即为第一音频数据。其中，云应用程序的启动过程是指：该云应用程序已经启动，但是还未完成启动，此时，云应用程序能够实现部分功能，例如，获取音频数据、下发音频数据等。可选地，启动状态对应的音频数据为背景音乐的音频数据。

例如，云应用程序为游戏类应用程序，对于一些比较大型的游戏应用程序，启动过程会耗费一定的时间，因此，在云应用程序的启动过程中，向终端发送音频数据，由终端播放该音频数据，以避免用户等待过程产生无聊的情绪。

可选地，云应用程序在运行过程中，接收到终端的本地应用程序发送的操作指令，该云应用程序响应于该操作指令，执行该操作指令对应的操作，从多种类型的音频数据中选择该操作指令对应的音频数据，该音频数据即为第一音频数据。

例如，云应用程序为游戏类应用程序，该云应用程序在运行过程中，接收到终端发送的技能释放指令，该技能释放指令携带虚拟角色标识和技能标识，云应用程序响应于该技能释放指令，根据该技能释放指令中的虚拟角色标识和技能标识，控制相应的虚拟角色释放相应的技能，从多种类型的音频数据中选择该技能释放对应的音频数据。

可选地，云应用程序中包括一个或多个音频源，该多种类型的音频数据存储在该一个或者多个音频源中。可选地，每个音频源存储一种类型的音频数据，不同音频源存储的音频数据的类型不同。

相应地，云应用程序能够根据当前的运行状态从多种类型的音频数据中选择与当前的运行状态对应的第一音频数据发送至终端，包括：云应用程序从任一音频源中，读取与当前的运行状态对应的第一音频数据发送至终端；或者，云应用程序根据当前的运行状态，确定目标音频源，从目标音频源中读取与当前的运行状态对应的第一音频数据发送至终端。

另外，云应用程序在将第一音频数据下发至终端的过程中，会先将第一音频数据输入至系统框架中进行处理。

502、通过系统框架，对第一音频数据进行混音处理，得到第三音频数据。

其中，系统框架是操作系统中的框架，该操作系统为安卓系统或者IOS（iPhoneOperation System，苹果操作系统）等，可选地，该系统框架为音频处理框架（AudioFlinger）。

可选地，第一音频数据包括多路音频数据，将第一音频数据进行混音处理，是将该多路音频数据混合成一路音频数据，则混音处理得到的第三音频数据为一路音频数据。

例如，第一音频数据包括背景音乐对应的音频数据和操作音效对应的音频数据，也就是说，第一音频数据包括两路音频数据，为了使终端播放的音频数据更加流畅，因此，将该背景音乐对应的音频数据与操作音效对应的音频数据混合成一路音频数据，得到第三音频数据，以便后续用户听到的第三音频数据更加流畅，保证了用户的听觉效果。

另外，如果第一音频数据中包括多路音频数据，可能会存在用户更加关注其中某一路音频数据的情况，例如，第一音频数据包括背景音乐对应的音频数据和操作音效对应的音频数据，由于背景音乐是随着云应用程序的运行一直播放的音频数据，而操作音效为伴随着用户操作而播放的音频数据，因此，用户可能更加关注操作音效对应的音频数据。因此，第一音频数据包括多路音频数据，对第一音频数据进行混音处理，得到第三音频数据，包括：确定第一音频数据中每一路音频数据的权重，根据每一路音频数据的权重，将该多路音频数据混合成一路音频数据，得到第三音频数据。

可选地，每一路音频数据的权重，根据该音频数据的类型确定，例如，系统通知的权重最大，操作音效的权重次之，背景音乐的权重最小；或者，操作音效的权重最大、系统通知的权重次之，背景音乐的权重最小。

可选地，系统框架包括处理线程，则通过系统框架，对第一音频数据进行混音处理，得到第三音频数据包括：通过处理线程对第一音频数据进行混音处理，得到第三音频数据。可选地，该处理线程为混音线程。

503、通过系统框架从硬件抽象层获取音频参数，该硬件抽象层存储有音频参数。

本申请实施例定制化了硬件抽象层，该硬件抽象层与终端上的硬件抽象层不同，终端上的硬件抽象层用于调用扬声器等硬件的接口，将音频数据输入至硬件中进行播放，而本申请实施例中的硬件抽象层不与硬件连接，而是与音频采集程序建立通信连接，将音频数据发送至音频采集程序。

需要说明的是，音频采集程序配置有音频参数，该音频参数指示该音频采集程序接收的音频数据需要满足该音频参数，例如，音频参数为24KHz（千赫兹）双通道，指示音频采集程序被配置为接收24KHz双通道的音频数据。

如果硬件抽象层发送的音频数据的音频参数不符合音频采集程序的要求，那么音频采集程序可能无法顺利接收该音频数据，可选地，该硬件抽象层中存储有音频参数，该音频参数根据音频采集程序的需求设置，这样，系统框架能够从硬件抽象层中获取音频参数，生成满足该音频参数的音频数据，以使硬件抽象层成功将音频数据发送至音频采集程序。

例如，音频采集程序接收24KHz（千赫兹）的音频数据，该音频参数包括：采样率为24KHz。

可选地，该音频参数包括目标采样率、目标通道数或者目标采样深度中的至少一项。

另外，需要说明的是，可选地，该步骤503在步骤502之前执行，或者，该步骤503与步骤502同时执行，或者该步骤503在步骤502之后执行。

可选地，在云应用程序的运行过程中，该步骤503仅执行一次，或者，系统框架每次处理音频数据时，均需执行该步骤503，本申请实施例对此不做限定。

504、通过系统框架，按照该音频参数对第三音频数据进行处理，得到第二音频数据。

为了使系统框架输出的音频数据的音频参数满足音频采集程序的需求，可以按照硬件抽象层中的音频参数，对第三音频数据进行处理，得到第二音频数据，以使第二音频数据的音频参数与硬件抽象层中的音频参数一致，使得第二音频数据的音频参数满足音频采集程序的需求。也就是说，通过系统框架，按照该音频参数对第三音频数据进行处理，得到第二音频数据，相当于调整了音频数据的音频参数。

可选地，音频参数包括目标采样率、目标通道数或者目标采样深度中的至少一项；通过系统框架，按照该音频参数对第三音频数据进行处理，得到第二音频数据，包括以下（1）至（3）中的至少一项。

（1）音频参数包括目标采样率，通过系统框架，按照目标采样率对第三音频数据进行重采样处理，得到第二音频数据。

例如，如果目标采样率为24KHz，第三音频数据的采样率为48 KHz，则对第三音频数据进行重采样处理，得到采样率为24KHz的第二音频数据。

（2）音频参数包括目标通道数，通过系统框架，按照目标通道数对第三音频数据进行通道数转换处理，得到第二音频数据。

例如，如果目标通道数为双通道，而第三音频数据为单通道音频数据，则对第三音频数据进行通道数转换处理，得到双通道的第二音频数据。

（3）音频参数包括目标采样深度，通过系统框架，按照目标采样深度对第三音频数据进行重采样处理，得到第二音频数据。

例如，如果目标采样深度为8bit，而第三音频数据的采样深度为16bit，则对第三音频数据进行重采样处理，得到采样深度为8bit的第二音频数据。

可选地，系统框架包括处理线程，通过系统框架，按照该音频参数对第三音频数据进行处理，得到第二音频数据包括：通过处理线程，按照音频参数对第三音频数据进行处理，得到第二音频数据。在系统框架中，对第一音频数据进行混音处理，以及按照音频参数对第三音频数据进行处理，均是通过同一个线程完成的，无需多个线程来分别处理，减少了音频数据在处理过程中的传输，进而加快了音频数据的处理速度。

可选地，该处理线程为混音线程。

505、通过系统框架，将第二音频数据发送至硬件抽象层。

通过系统框架，将第二音频数据发送至硬件抽象层，硬件抽象层会将该第二音频数据发送至音频采集程序，但是若音频采集程序还未启动，或者硬件抽象层与音频采集程序未建立通信连接，即便将第二音频数据发送至硬件抽象层，硬件抽象层也无法将第二音频数据发送至音频采集程序，因此，通过系统框架，在硬件抽象层与音频采集程序成功建立通信连接的情况下，将第二音频数据发送至硬件抽象层。

在一种可能实现方式中，通过系统框架，将第二音频数据发送至硬件抽象层，包括：若硬件抽象层与音频采集程序已建立通信连接，则通过系统框架将第二音频数据发送至硬件抽象层；若硬件抽象层还未与音频采集程序建立通信连接，则控制硬件抽象层与音频采集程序建立通信连接，在硬件抽象层与音频采集程序成功建立通信连接的情况下，通过系统框架，将第二音频数据发送至硬件抽象层。

其中，控制硬件抽象层与音频采集程序建立通信连接，包括：控制硬件抽象层向音频采集程序发送通信连接建立请求，若音频采集程序侦听到该通信连接建立请求，则建立硬件抽象层与音频采集程序之间的通信连接。

但是若音频采集程序未侦听到硬件抽象层发送的通信连接建立请求，则硬件抽象层与音频采集程序未能成功建立通信连接，则系统框架丢弃该第二音频数据，不再将该第二音频数据发送至硬件抽象层。

其中，音频采集程序未侦听到硬件抽象层发送的通信连接建立请求，可能是是因为音频采集程序还未启动成功。在一种可能实现方式中，该音频采集程序不仅用于将云应用程序生成的音频数据发送至终端的本地应用程序，还用于将云应用程序生成的视频数据发送至终端的本地应用程序。如果音频采集程序还未启动成功，该音频采集程序也不会将云应用程序生成的视频数据发送至终端的本地应用程序，从而终端无法根据视频数据渲染云应用程序的画面，此时即便丢弃云应用程序的第二音频数据，也不会对用户造成影响。

可选地，硬件抽象层包括写入接口，将第二音频数据发送至硬件抽象层，包括：通过系统框架调用硬件抽象层的写入接口，将第二音频数据写入硬件抽象层。

例如，系统框架会周期性地调用硬件抽象层的写入接口，在该写入接口中确定硬件抽象层是否与音频采集程序建立了通信连接，如果已经建立了通信连接，则将第二音频数据写入硬件抽象层，如果未建立通信连接，则控制硬件抽象层尝试与音频采集程序建立通信连接，通过通信连接建立成功，则将第二音频数据写入硬件抽象层，如果通信连接建立失败，则丢弃该第二音频数据。

506、通过硬件抽象层，根据硬件抽象层与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序，音频采集程序用于将第二音频数据发送至终端本地的应用程序。

其中，硬件抽象层与音频采集程序之间建立有通信连接，该通信连接可以是任一种形式的通信连接。

可选地，硬件抽象层与音频采集程序之间的通信连接为socket（套接字）连接。

其中，如图6所示，硬件抽象层601作为socket的客户端，音频采集程序602作为socket的服务端，在音频采集程序602中，存在一个单独的线程与socket绑定，在该线程上进行侦听，socket的accept（接收）函数调用是一个阻塞调用，会一直等到有socket客户端连接上来，在硬件抽象层601与音频采集程序602建立socket连接后，音频采集程序602会调用socket的read（读取）函数，该read函数被配置为一个阻塞函数，会一直等待硬件抽象层601将音频数据发送过来。由于硬件抽象层601和音频采集程序602均在同一容器中运行，因此，通过硬件抽象层601将第二音频数据发送至音频采集程序602相当于本机发送，延时是微秒级别的，极大地减少了第二音频数据的传输时长，缩短了服务器获取音频数据的延时。

可选地，硬件抽象层与音频采集程序之间的通信连接为：共享内存连接。其中，以程序A和程序B为例，共享内存连接是指：程序A与程序B共享一个内存，程序A将数据存储到该内存中，程序B能够从该内存中将数据读取出来，实现了程序A与程序B的连接，也实现了程序A将数据发送至程序B的效果。

在一种可能实现方式中，通过系统框架，将第二音频数据发送至硬件抽象层，包括：通过系统框架，将第二音频数据发送至硬件抽象层的目标内存中，该目标内存为硬件抽象层与音频采集程序的共享内存。因此，通过硬件抽象层，根据硬件抽象层与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序，包括：音频采集程序从目标内存中读取第二音频数据。

需要说明的是，硬件抽象层与音频采集程序之间可以建立任一种通信连接，本申请实施例对二者之间的通信连接方式不做限定，且本申请实施例仅以socket连接和共享内存进行示例性说明，而不对二者的通信连接方式造成限制。

可选地，音频采集程序在获取到第二音频数据之后，将第二音频数据发送至编码程序，由编码程序对第二音频数据进行编码，之后，由编码程序将编码后的第二音频数据发送至终端本地的应用程序。

可选地，编码程序与终端能够建立通信连接，根据该通信连接，将编码后的第二音频数据发送至终端本地的应用程序，由终端本地的应用程序进行解码并播放。可选地，该通信连接为webrtc对等连接。

需要说明的是，本申请实施例仅是以云应用程序输出第一音频数据，音频采集程序获取到第二音频数据为例，对音频数据在服务器中的多个程序之间的处理过程和传输过程进行示例性说明，在一种可能实现方式中，在云应用程序的运行过程，云应用程序能够一直生成音频数据，或者多次生成音频数据，每次音频数据从云应用程序传输至音频采集程序的过程与上述步骤501至步骤506的过程类似，本申请实施例在此不再一一赘述。

需要说明的是，如果云应用程序持续输出音频数据，该云应用程序会周期性输出目标大小的音频数据。可选地，该音频数据的目标大小取决于终端音频数据缓存的大小，可选地，该音频数据的目标大小取决于系统框架、硬件抽象层、或者音频采集程序中缓存的大小。例如，该音频数据为播放时长为10ms的音频数据。

本申请实施例提供的音频数据处理方法，在系统框架和音频采集程序之间设置了中转程序，且建立了中转程序与音频采集程序之间的通信连接，通过该通信连接能够直接将系统框架处理后的音频数据发送至该音频采集程序。与音频采集程序通过调用音频录制接口从录制线程中读取音频数据相比，上述通过通信连接直接发送音频数据的方式，减少了音频数据的传输链路，缩短了音频采集程序获取到音频数据的时长，减小了服务器下发音频数据的延时。

另外，由于系统框架中进行混音处理的线程和按照音频参数进行处理的线程均为处理线程，通过一个线程能够进行两次处理，减少音频数据的传输，从而缩短了硬件抽象层获取到音频数据的时间，进一步减小了服务器下发音频数据的延时。

另外，由于硬件抽象层与音频采集程序之间的通信连接建立失败，硬件抽象层无法将第二音频数据发送至音频采集程序，系统框架将第二音频数据发送至硬件抽象层时，会确定硬件抽象层与音频采集程序是否建立了通信连接，若硬件抽象层与音频采集程序还未建立通信连接，则控制硬件抽象层尝试与音频采集程序建立通信连接，在通信连接建立成功的情况下，才会将第二音频数据发送至硬件抽象层，在通信连接建立失败的情况下，会丢弃第二音频数据，减少了无用数据的发送，为服务器减轻了负担。

在一种可能实现方式中，中转程序为重采样程序，如图7所示，该服务器700包括云应用程序701、系统框架702、重采样程序703和音频采集程序704。

其中，云应用程序701能够调用系统框架702的接口，将音频数据写入系统框架702中，系统框架702在对音频数据处理后，将得到的音频数据发送至重采样程序703。重采样程序703与音频采集程序704之间建立有通信连接，能够直接将音频数据发送至音频采集程序704。

需要说明的是，上述云应用程序701、系统框架702、重采样程序703和音频采集程序704均运行在服务器700的操作系统容器中。

可选地，该服务器700还包括编码程序705，音频采集程序704将音频数据发送至编码程序705，由编码程序705将该音频数据进行编码，并将编码后的音频数据发送至终端本地的应用程序。

在上述图7所示的服务器的基础上，本申请实施例还提供了一种音频数据处理方法，图8是本申请实施例提供的一种音频数据处理方法的流程图，本申请实施例的执行主体为图7所示的服务器，参见图8，该方法包括以下步骤。

801、将云应用程序的第一音频数据输入至系统框架。

该步骤801与上述步骤501类似，在此不再一一赘述。

802、通过系统框架对第一音频数据进行混音处理，得到第三音频数据。

该步骤802与上述步骤502类似，在此不再一一赘述。

803、通过系统框架从重采样程序获取音频参数。

其中，重采样程序中配置有音频参数，该音频参数指示该重采样程序接收的音频数据需要满足该音频参数，例如，音频参数为48 KHz双通道，指示该重采样程序被配置为接收48 KHz双通道的音频数据。因此，系统框架会从重采样程序中获取音频数据，以生成符合重采样程序需求的音频数据。

804、通过系统框架，按照该音频参数对第三音频数据进行处理，得到第二音频数据。

该步骤804与上述步骤504类似，在此不再一一赘述。

805、通过系统框架，将第二音频数据发送至重采样程序。

其中，通过系统框架，将第二音频数据发送至重采样程序，重采样程序会将该第二音频数据发送至音频采集程序，但是若音频采集程序还未启动，或者重采样程序与音频采集程序未建立通信连接，即便将第二音频数据发送至重采样程序，重采样程序也无法将第二音频数据发送至音频采集程序，可选地，通过系统框架，在重采样程序与音频采集程序成功建立通信连接的情况下，将第二音频数据发送至重采样程序。

在一种可能实现方式中，通过系统框架，将第二音频数据发送至重采样程序，包括：若重采样程序与音频采集程序已建立通信连接，则通过系统框架将第二音频数据发送至重采样程序；若重采样程序还未与音频采集程序建立通信连接，则控制重采样程序与音频采集程序建立通信连接，在重采样程序与音频采集程序成功建立通信连接的情况下，通过系统框架，将第二音频数据发送至重采样程序。

其中，控制重采样程序与音频采集程序建立通信连接，包括：控制重采样程序向音频采集程序发送通信连接建立请求，若音频采集程序侦听到该通信连接建立请求，则建立重采样程序与音频采集程序之间的通信连接。

但是若音频采集程序未侦听到重采样程序发送的通信连接建立请求，则重采样程序与音频采集程序未能成功建立通信连接，则系统框架丢弃该第二音频数据，不再将该第二音频数据发送至重采样程序。

其中，音频采集程序未侦听到重采样程序发送的通信连接建立请求，可能是是因为音频采集程序还未启动成功。在一种可能实现方式中，该音频采集程序不仅用于将云应用程序生成的音频数据发送至终端的本地应用程序，还用于将云应用程序生成的视频数据发送至终端的本地应用程序。如果音频采集程序还未启动成功，该音频采集程序也不会将云应用程序生成的视频数据发送至终端的本地应用程序，从而终端无法根据视频数据渲染云应用程序的画面，此时即便丢弃云应用程序的第二音频数据，也不会对用户造成影响。

需要说明的是，本申请实施例仅是以系统框架在重采样程序与音频采集程序成功建立通信连接的情况下，将第二音频数据发送至重采样程序为例，对音频数据在服务器中的传输过程进行示例性说明，而在另一实施例中，无论重采样程序与音频采集程序是否建立通信连接，系统框架均会将第二音频数据发送至重采样程序。

可选地，重采样程序包括接收线程，通过系统框架，将第二音频数据发送至硬件抽象层，包括：通过系统框架，将第二音频数据发送至重采样程序的接收线程。

可选地，系统框架是通过处理线程对第一音频数据进行处理，得到第二音频数据的，因此，在一种可能实现方式中，通过系统框架，将第二音频数据发送至重采样程序的接收线程，包括：通过处理线程，将第二音频数据发送至重采样程序的接收线程。

806、通过重采样程序，根据重采样程序与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序，音频采集程序用于将第二音频数据发送至终端本地的应用程序。

其中，重采样程序与音频采集程序之间建立有通信连接，该通信连接是任一种形式的通信连接。

可选地，重采样程序与音频采集程序之间的通信连接为socket连接，其中，重采样程序作为socket的客户端，音频采集程序作为socket的服务端。其中，通过重采样程序，根据重采样程序与音频采集程序之间的socket连接，将第二音频数据发送至音频采集程序的方式，与步骤506中，通过硬件抽象层，根据硬件抽象层与音频采集程序之间的socket连接，将第二音频数据发送至音频采集程序的方式类似，在此不再一一赘述。

可选地，重采样程序与音频采集程序之间的通信连接为共享内存连接。其中，通过重采样程序，根据重采样程序与音频采集程序之间的共享内存连接，将第二音频数据发送至音频采集程序的方式，与步骤506中，通过硬件抽象层，根据硬件抽象层与音频采集程序之间的共享内存连接，将第二音频数据发送至音频采集程序的方式类似，在此不再一一赘述。

可选地，重采样程序中包括接收线程，重采样程序与音频采集程序之间的通信连接为：接收线程与音频采集程序之间的通信连接；或者，重采样程序包括接收线程和第一发送线程，其中，接收线程用于接收系统框架发送的第二音频数据，第一发送线程为用于将接收线程接收的第二音频数据发送至音频采集程序。重采样程序与音频采集程序之间的通信连接为：第一发送线程与音频采集程序之间的通信连接。

另外，根据上述步骤803可知，第二音频数据的音频参数符合重采样程序的需求，若该第二音频数据的音频参数也符合音频采集程序的需求，则重采样程序能够直接将第二音频数据发送给音频采集程序，若第二音频数据的音频参数不符合音频采集程序的需求，则重采样程序需要对该第二音频数据进行重采样处理，以使处理后的第二音频数据符合音频采集程序的需求，再将处理后的第二音频数据发送至音频采集程序。

例如，重采样程序配置的音频参数为48KHz双通道，若音频采集程序的音频参数为48KHz双通道，则重采样程序无需对第二音频数据进行重采样处理，直接将第二音频数据发送至音频采集程序；若音频采集程序的音频参数为16KHz双通道，则重采样程序需要对第二音频数据进行重采样处理，以使处理后的第二音频数据的采样率为16KHz。

由于重采样程序配置的音频参数与音频采集程序配置的音频参数相同的情况下，重采样程序无需进行重采样处理，因此，可以根据音频采集程序配置的音频参数配置重采样程序，以使重采样程序配置的音频参数与音频采集程序配置的音频参数相同。

需要说明的是，在一种可能实现方式中，系统框架还包括录制线程和检测线程，系统框架中的检测线程会检测当前是否存在其他程序读取录制线程中的数据，如果没有其他程序读取录制线程中的数据，系统框架将不再向重采样程序发送数据。该检测线程的设计初衷在于节省不必要的运算，降低功耗。

另外，如果系统框架还包括录制线程，服务器还需要执行以下步骤807至步骤810。如果系统框架不包括录制线程，则音频采集程序在获取到第二音频数据后，将该第二音频数据发送至终端的本地应用程序。

807、通过重采样程序，将第二音频数据发送至录制线程。

其中，通过重采样程序，将第二音频数据发送至录制线程，录制线程会对接收到的第二音频数据进行录制，由于录制线程边接收第二音频数据边录制第二音频数据，且该录制过程会耗费一定的时间，导致重采样程序将第二音频数据发送至录制线程也耗费一定的时间。可选地，重采样程序包括接收线程和第二发送线程，其中，接收线程用于从系统框架中接收第二音频数据，在第二发送线程存在可用的缓存时，将第二音频数据发送至第二发送线程中。第二发送线程在接收到第二音频数据之后，根据录制线程中配置的音频参数确定是否对该第二音频数据进行重采样处理，若需要对该第二音频数据进行重采样处理，则按照录制线程配置的音频参数，对第二音频数据进行重采样处理，得到处理后的第二音频数据，将处理后的第二音频数据发送至录制线程中；若无需对第二音频数据进行重采样处理，则直接将第二音频数据发送至录制线程中。

其中，第二发送线程存在可用的缓存是指：第二发送线程将重采样程序上一次接收的音频数据全部发送至录制线程中。

另外，如果第二音频数据的音频参数与录制线程配置的音频参数相同，则重采样程序直接将第二音频数据发送至录制线程，该录制线程能够对该第二音频数据进行录制，如果第二音频数据的音频参数与录制线程配置的音频参数不同，则重采样程序直接将第二音频数据发送给录制线程，该录制线程可能无法顺序接收该第二音频数据。其中，第二发送线程根据录制线程中配置的音频参数确定是否对该第二音频数据进行重采样处理，包括：第二发送线程确定第二音频数据的音频参数与录制线程配置的音频参数是否相同，如果第二音频数据的音频参数与录制线程配置的音频参数相同，则确定无需对第二音频数据进行重采样处理；如果第二音频数据的音频参数与录制线程配置的音频参数不同，则确定需要对第二音频数据进行重采样处理。

808、通过录制线程对第二音频数据进行录制，得到第三音频数据。

系统框架还包括录制线程对应的缓存，通过录制线程对第二音频数据进行录制，得到第三音频数据，包括：通过录制线程将第二音频数据拷贝到对应的缓存中，得到第三音频数据，其中，第三音频数据的数据内容与第二音频数据的数据内容相同。

809、通过音频采集程序，调用音频录制接口从录制线程中读取第三音频数据。

其中，录制线程将第三音频数据复制到对应的缓存中，通过音频采集程序，调用音频录制接口从录制线程中读取第三音频数据，包括：通过音频采集程序，调用音频录制接口从录制线程对应的缓存中读取第三音频数据。

可选地，音频录制接口包括read（读取）函数，通过音频采集程序，调用音频录制接口从录制线程中读取第三音频数据，包括：音频采集程序调用音频录制接口的read函数，从录制线程对应的缓存中读取第三音频数据，如果录制线程对应的缓存中不存在第三音频数据，该音频采集程序就会等待，直至录制线程将第三音频数据拷贝到缓存中，再进行读取。

810、通过音频采集程序，丢弃第三音频数据，将第二音频数据发送至终端本地的应用程序。

其中，第二音频数据的数据内容与第三音频数据的数据内容相同，但是第二音频数据是重采样程序直接发送至音频采集程序的，而第三音频数据是重采样程序发送给录制线程，再由音频采集程序从录制线程中读取的，因此，第二音频数据相比第三音频数据能够更快到达音频采集程序，为了减小服务器下发音频数据的延时，音频采集程序会将第二音频数据发送至终端本地的应用程序，而将第三音频数据丢弃。

另外，音频采集程序与重采样程序之间建立有通信连接，第二音频数据是根据通信连接获取的音频数据，而第三音频数据是通过音频采集程序调用音频录制接口的获取的音频数据，因此，第二音频数据和第三音频数据的获取方式不同，可选地，根据获取方式来区分第二音频数据和第三音频数据，将第二音频数据发送至终端本地的应用程序。

例如，音频采集程序包括第一采集线程和第二采集线程，第一采集线程用于采集第二音频数据，该第一采集线程与重采样程序之间建立有通信连接，重采样程序根据重采样程序与该第一采集程序之间的通信连接，将第二音频数据发送至第一采集线程；第二采集线程用于采集第三音频数据，该第二采集线程调用音频录制接口从录制线程中读取第三音频数据。其中服务器将第一采集线程采集的音频数据发送至终端的本地应用程序，将第二采集线程采集的音频数据丢弃。

需要说明的是，本申请实施例中的重采样程序是操作系统中的程序，也就是说，该重采样程序是操作系统自带的程序，本申请通过对操作系统中原有的程序进行改进来实现上述音频数据处理方法。

需要说明的是，本申请实施例仅是以云应用程序输出第一音频数据，音频采集程序获取到第二音频数据为例，对音频数据在服务器中的多个程序之间的处理过程和传输过程进行示例性说明，在一种可能实现方式中，在云应用程序的运行过程，云应用程序能够一直生成音频数据，或者多次生成音频数据，每次音频数据从云应用程序传输至音频采集程序的过程与上述步骤801至步骤810的过程类似，本申请实施例在此不再一一赘述。

需要说明的是，如果云应用程序持续输出音频数据，该云应用程序会周期性输出目标大小的音频数据。可选地，该音频数据的目标大小取决于终端音频数据缓存的大小，可选地，该音频数据的目标大小取决于系统框架、重采样程序、或者音频采集程序中缓存的大小。例如，该音频数据为播放时长为10ms的音频数据。

本申请实施例提供的音频数据处理方法，对操作系统中的重采样程序进行了改进，在重采样程序与音频采集程序之间建立了通信连接，使得该重采样程序能够根据该通信连接，直接将第二音频数据发送至音频采集程序中。与音频采集程序通过调用音频录制接口从录制线程中读取音频数据相比，上述通过通信连接直接发送音频数据的方式，减少了音频数据的传输链路，缩短了音频采集程序获取到音频数据的时长，减小了服务器下发音频数据的延时。

另外，重采样程序还会将音频数据发送至录制线程中，音频采集程序从录制线程中读取音频数据，以保证系统框架持续向重采样程序发送音频数据，保证了音频数据的持续处理和发送，并且，音频采集程序会发送重采样程序发送过来的音频数据，而丢弃从录制线程中读取的音频数据，保证了下发音频数据的延时较小。

另外，本申请实施例还提供了一种延时获取方法，该延时获取方法用于获取上述音频数据处理方法中服务器获取音频数据的延时。图9是本申请实施例提供的一种延时获取方法的流程图，本申请实施例的执行主体为服务器，参见图9，该方法包括以下步骤。

901、将检测应用程序的第一检测音频数据输入至系统框架，记录第一检测音频数据的发送时间。

其中，该检测应用程序是在服务器中运行的，且用于检测服务器下发音频数据延时的应用程序。该检测应用程序能够输出检测音频数据，后续通过获取服务器中其他程序接收该检测音频数据的时间，来获取检测音频数据在其他程序中传输所消耗的时长，其中，服务器中的其他程序为检测应用程序之外的程序。

其中，第一检测音频数据为检测应用程序输出的任一检测音频数据，可选地，检测应用程序能够持续输出音频数据，且除了输出检测音频数据之外，还会输出其他音频数据，其中，检测音频数据与其他音频数据不同，以便对检测音频数据和其他音频数据进行区分，从而得到程序接收检测音频数据的时间。

902、通过系统框架对第一检测音频数据进行处理，得到第二检测音频数据，将第二检测音频数据发送至中转程序。

其中，系统框架为操作系统中的框架，用于对音频数据进行处理。中转程序为系统框架与音频采集程序之间的程序，用于将系统框架处理的音频数据传输至音频采集程序，该中转程序具有转发音频数据的功能，可选地，中转程序还具有其他功能，本申请实施例对此不做限定。

第二检测音频数据为通过系统框架对第一检测音频数据进行处理后的音频数据，但是该第二检测音频数据与第一检测音频数据均为能够与其他音频数据进行区分的音频数据，因此，即便对第一检测音频数据进行处理，得到第二检测音频数据，也能够区分第二检测音频数据以及其他音频数据，从而得到程序接收第二检测音频数据的时间。

903、通过中转程序，根据中转程序与音频采集程序之间的通信连接，将第二检测音频数据发送至音频采集程序，记录音频采集程序接收第二检测音频数据的第一接收时间，音频采集程序用于将第二检测音频数据发送至终端本地的应用程序。

其中，音频采集程序为服务器中用于采集音频数据，并将音频数据发送至终端的程序，中转程序与音频采集程序之间建立有通信连接，中转程序通过该通信连接，直接将第二音频数据发送至音频采集程序。

904、获取发送时间和第一接收时间之间的第一时间差，第一时间差表示检测音频数据从检测应用程序传输至音频采集程序的延时。

由于发送时间为检测应用程序输出检测音频数据的时间，而第一接收时间为音频采集程序接收到该检测音频数据的时间，且由于音频采集程序为服务器中用于采集音频数据，并将音频数据发送至终端的程序，因此，音频采集程序接收到该检测音频数据的时间，能够认为是服务器获取到音频数据的时间，因此，发送时间和第一接收时间之间的第一时间差还表示服务器获取到音频数据所消耗的时长，也即是服务器下发音频数据的延时。

本申请实施例提供的延时获取方法，通过检测应用程序发出检测音频数据，获取音频采集程序接收检测音频数据的接收时间，根据发送时间与接收时间之间的时间差，能够准确得到音频数据从检测应用程序传输至音频采集程序所消耗的时长，也即是得到服务器获取音频数据的时长，该时长能够代表服务器下发音频数据的延时，后续根据该时长能够确定服务器获取音频数据的延时是否会影响音频数据的播放效果，是否会影响终端用户的听觉效果，进而确定是否继续对服务器进行改进，为开发人员提供了较好的改进依据。

需要说明的是，上述步骤902和步骤903中的中转程序为硬件抽象层；或者为操作系统中原有的重采样程序；或者，为其他程序，本申请实施例对此不做限定。

可选地，该中转程序为硬件抽象层，如图4所示，该服务器400包括云应用程序401、系统框架402、硬件抽象层403和音频采集程序404。在上述图4所示的服务器的基础上，本申请实施例还提供了一种延时获取方法，能够用于检测图4所示的服务器下发音频数据的延时。图10是本申请实施例提供的一种延时获取方法的流程图，本申请实施例的执行主体为图4所示的服务器，参见图10，该方法包括以下步骤。

1001、将检测应用程序的第一检测音频数据输入至系统框架，记录第一检测音频数据的发送时间。

其中，该检测应用程序是在服务器中运行的，且用于检测服务器下发音频数据延时的应用程序。该检测应用程序能够输出检测数据，后续通过获取服务器中其他程序接收该检测数据的时间，来获取检测数据在其他程序中传输所消耗的时长，其中，服务器中的其他程序为检测应用程序之外的程序。

为了更加准确地获取到音频数据在服务器中多个程序之间传输所消耗的时长，检测应用程序输出的检测数据为检测音频数据，由于检测音频数据为音频数据，因此，将检测音频数据输出至系统框架等其他程序后，该其他程序能够模拟真实的音频数据处理过程，这样，后续通过获取其他程序接收检测音频数据的时间来确定延时会更加准确。

可选地，检测应用程序与上述步骤501中的云应用程序不同，云应用程序按照接收到的操作指令输出音频数据，而检测应用程序按照配置的检测逻辑来输出音频数据的。可选地，配置的检测逻辑为每隔第一时长发送一次检测音频数据。其中，第一时长可以是4秒、5秒等任一时长。

其中，第一检测音频数据为检测应用程序输出的任一检测音频数据，可选地，检测应用程序能够持续输出音频数据，且除了输出检测音频数据之外，还会输出其他音频数据，其中，检测音频数据与其他音频数据不同，以便区分检测音频数据与其他音频数据，从而得到程序接收检测音频数据的时间。

可选地，第一检测音频数据为携带有标签的音频数据，后续根据第一检测音频数据携带的标签能够确定是否接收到第一检测音频数据。

可选地，第一检测音频数据为一固定数值的音频数据，且该第一检测音频数据与检测应用程序输出的其他音频数据不同。例如，第一检测音频数据的数值为0xffff（0x表示十六进制，ffff表示十六进制的数值），而检测应用程序输出的其他音频数据的数值为0，如图11所示，该检测应用程序输出数值为0的音频数据，并周期性输出数值为0xffff的检测音频数据1101。

可选地，服务器还包括记录程序，该记录程序在检测应用程序将第一检测音频数据输入至系统框架时，记录下当前时间，该当前时间为第一检测音频数据的发送时间。可选地，检测应用程序在将第一检测音频数据输入至系统框架时，会向记录程序发送消息，该消息指示检测应用程序将第一检测音频数据输入至系统框架中，该记录程序记录接收该消息的时间，作为第一检测音频数据的发送时间。

需要说明的是，该记录程序为检测应用程序之外的程序，或者为检测应用程序中的拥有记录功能的程序。

可选地，该记录程序还具有检测其他程序的功能，该记录程序能够检测系统框架中的数据，在检测到系统框架中包含检测音频数据时，记录当前时间，该当前时间为第一检测音频数据的发送时间。

1002、通过系统框架对第一检测音频数据进行处理，得到第二检测音频数据，将第二检测音频数据发送至硬件抽象层。

需要说明的是，通过系统框架对第一检测音频数据进行处理的方式，与上述步骤502中通过系统框架对第一音频数据进行处理的方式类似，通过系统框架将第二检测音频数据发送至硬件抽象层的方式，与上述步骤505中通过系统框架将第二音频数据发送至硬件抽象层的方式类似，在此不再一一赘述。

需要说明的是，通过系统框架对第一检测音频数据进行处理后，得到的第二检测音频数据与第一检测音频数据类似，均为能够与其他音频数据进行区分的音频数据。

例如，如果第一检测音频数据为携带标签的音频数据，那么第二检测音频数据也携带该标签。如果第一检测音频数据的数值为0xffff，其他音频数据的数值为0，那么第二检测音频数据的数值为非0数值，而其他音频数据在处理后，数值依然为0，也即是不会因为对检测音频数据进行处理，而使得检测音频数据的检测功能失效。

1003、记录硬件抽象层接收第二检测音频数据的第二接收时间，获取发送时间与第二接收时间之间的第二时间差，第二时间差表示检测音频数据从检测应用程序传输至硬件抽象层的延时。

其中，记录程序还用于记录硬件抽象层接收第二检测音频数据的第二接收时间，在记录第二接收时间之前，先确定硬件抽象层接收到第二检测音频数据。可选地，硬件抽象层在接收到第二检测音频数据之后，向记录程序上报消息，告知记录程序已接收到第二检测音频数据，记录程序接收到上报的消息时，记录当前时间，该当前时间为硬件抽象层接收第二检测音频数据的第二接收时间。

可选地，该记录程序还具有检测其他程序的功能，例如，该记录程序检测硬件抽象层的代码中是否包括第二检测音频数据，在检测到第二检测音频数据时，记录当前时间，该当前时间为硬件抽象层接收第二检测音频数据的第二接收时间。

1004、通过硬件抽象层，根据硬件抽象层与音频采集程序之间的通信连接，将第二检测音频数据发送至音频采集程序，记录音频采集程序接收第二检测音频数据的第一接收时间，音频采集程序用于将第二检测音频数据发送至终端本地的应用程序。

其中，通过硬件抽象层，根据硬件抽象层与音频采集程序之间的通信连接，将第二检测音频数据发送至音频采集程序，与上述步骤506中通过硬件抽象层，根据硬件抽象层与音频采集程序之间的通信连接，将第二音频数据发送至音频采集程序类似，在此不再一一赘述。

其中，记录程序还用于记录音频采集程序接收第二检测音频数据的第一接收时间，在记录第一接收时间之前，要先确定音频采集程序接收到第二检测音频数据。可选地，音频采集程序在接收到第二检测音频数据之后，向记录程序上报消息，告知记录程序已接收到第二检测音频数据，记录程序接收到上报的消息时，记录当前时间，该当前时间为音频采集程序接收第二检测音频数据的第一接收时间。

可选地，所述记录程序还具有检测其他程序的功能，例如，该记录程序检测音频采集程序的代码中是否包括第二检测音频数据，在检测到第二检测音频数据时，记录当前时间，该当前时间为音频采集程序接收第二检测音频数据的第一接收时间。

1005、获取发送时间和第一接收时间之间的第一时间差，第一时间差表示检测音频数据从检测应用程序传输至音频采集程序的延时。

需要说明的是，本申请实施例仅是以检测应用程序输出第一检测音频数据，获取第一检测音频数据在服务器中的多个程序之间传输所消耗的时长为例，对获取服务器下发音频数据的延时进行示例性说明，在一种可能实现方式中，在检测应用程序的运行过程中，该检测应用程序能够一直输出音频数据，且每隔一定时长输出一次检测音频数据，根据每个检测音频数据，均能获取一个服务器下发音频数据的延时，可选地，对多个延时进行统计处理，得到服务器下发音频数据的目标延时，由于该目标延时考虑了多个检测音频数据的传输过程，因此，该目标延时更加准确。可选地，统计处理为平均处理。

例如，检测应用程序每隔一定时长发送一次检测音频数据，后续能够获取多个第一时间差和第二时间差，通过将多个第一时间差进行统计处理，得到的时间差能够更加准确地表示检测音频数据从检测应用程序传输至音频采集程序的延时；通过将多个第二时间差进行统计处理，得到的时间差能够更加准确地表示检测音频数据从检测应用程序传输至硬件抽象层的延时。

需要说明的是，为了确保相邻的两个检测音频数据能够明显区分开，可以设置较大的时长间隔，例如4秒、5秒等。

如图12所示，在实际获取延时的过程中，检测应用程序1201发送第一检测音频数据的发送时间为t0，硬件抽象层1202接收第二检测音频数据的第二接收时间为t1，根据t0和t1可知，检测音频数据从检测应用程序1201到硬件抽象层1202的延时大约为40ms（毫秒），音频采集程序1203接收第二检测音频数据的时间为t2，根据t1和t2可知，第二检测音频数据从硬件抽象层1202到音频采集程序1203接收到第二检测音频数据的延时大约在0ms。因此，将服务器从操作系统中获取音频数据的耗时控制在40ms左右，极大地缩短了服务器获取音频数据的耗时。

需要说明的是，在一种可能实现方式中，服务器不仅将云应用程序生成的音频数据发送至终端，还会将云应用程序生成的视频数据发送至终端，通过对终端播放的音频和视频进行延时检测，发现音频与视频并不同步，从播放视频到播放该视频对应的音频，延时大约在0.37秒左右。当视频与音频的延时高于0.3秒时，人耳能够感觉到比较明显的延时，从而影响用户的体验。如果采样本申请实施例提供的音频数据处理方法，能够减小服务器下发音频数据的延时，将视频到音频的延时降低至0.242秒左右，从而人耳感觉不到明显的延时，提高用户的体验。

本申请实施例提供的延时获取方法，通过检测应用程序发出检测音频数据，获取音频采集程序接收检测音频数据的接收时间，根据发送时间与接收时间的时间差，能够准确得到音频数据从检测应用程序传输至音频采集程序所消耗的时长，也即是得到服务器获取音频数据的时长，该时长能够代表服务器下发音频数据的延时，后续根据该时长能够确定服务器获取音频数据的延时是否会影响音频数据的播放效果，是否会影响终端用户的听觉效果，进而确定是否继续对服务器进行改进，为开发人员提供了较好的改进依据。

另外，还能够获取硬件抽象层接收到检测音频数据的接收时间，进一步得到检测音频数据从检测应用程序传输至硬件抽象层所消耗的时长，以及检测音频数据从硬件抽象层传输至音频采集程序所消耗的时长，从而准确得到音频数据在每个传输阶段所消耗的时长，以便后续开发人员有针对性对服务器进行改进。

可选地，服务器中的中转程序为重采样程序，如图7所示，该服务器700包括云应用程序701、系统框架702、重采样程序703和音频采集程序704。在上述图7的基础上，本申请实施例还提供了一种延时获取方法，能够用于检测图7所示的服务器下发音频数据的延时。图13是本申请实施例提供的一种延时获取方法的流程图，本申请实施例的执行主体为图7所示的服务器，参见图13，该方法包括以下步骤。

1301、将检测应用程序的第一检测音频数据输入至系统框架，记录第一检测音频数据的发送时间。

1302、通过系统框架对第一检测音频数据进行处理，得到第二检测音频数据，将第二检测音频数据发送至重采样程序。

1303、记录重采样程序接收第二检测音频数据的第二接收时间，获取发送时间与第二接收时间之间的第二时间差，第二时间差表示检测音频数据从检测应用程序传输至硬件抽象层的延时。

1304、通过重采样程序，根据重采样程序与音频采集程序之间的通信连接，将第二检测音频数据发送至音频采集程序，记录音频采集程序接收第二检测音频数据的第一接收时间，音频采集程序用于将第二检测音频数据发送至终端本地的应用程序。

1305、获取发送时间和第一接收时间之间的第一时间差，第一时间差表示检测音频数据从检测应用程序传输至音频采集程序的延时。

需要说明的是，上述步骤1301至步骤1305与上述步骤1101至步骤1105类似，区别仅在于将上述步骤1101至步骤1105中是将第二检测音频数据发送至硬件抽象层，而上述步骤1301至步骤1305是将第二检测音频数据发送至重采样程序。

如图14所示，在实际获取延时的过程中，检测应用程序1401发送第一检测音频数据的发送时间为t0，重采样程序1402接收第二检测音频数据的第二接收时间为t1，音频数据从检测应用程序1401到重采样程序1402的延时大约为40ms（毫秒），音频采集程序1403接收到第二检测音频数据的第一接收时间为t2，音频数据从重采样程序1402到音频采集程序1403的延时大约在0ms。因此，将服务器从操作系统中获取音频数据的耗时控制在40ms左右，极大地缩短了服务器获取音频数据的耗时。

需要说明的是，在一种可能实现方式中，重采样程序还用于将第二检测音频数据发送至录制线程。录制线程对第二检测音频数据进行录制，得到第三检测音频数据，音频采集程序从录制线程中读取第三检测音频数据。

在一种可能实现方式中，记录程序还用于记录音频采集程序接收第三音频数据的第三接收时间，服务器获取发送时间和第三接收时间之间的第三时间差，第三时间差表示检测音频数据从检测应用程序、重采样程序和录制线程传输至音频采集程序的延时。

为了使记录的第三接收时间更加准确，可选地，在重采样程序与音频采集程序未建立通信连接的情况下，来获取音频数据从检测应用程序输出、经过重采样程序和录制线程到达音频采集程序的延时。这样，音频采集程序仅接收到第三检测音频数据，而接收不到第二检测音频数据，因此，得到的第三接收时间更加准确。

如图15所示，在实际获取延时的过程中，检测应用程序1501发送第一检测音频数据的发送时间为t0，重采样程序1502接收第二检测音频数据的第二接收时间为t1，音频数据从检测应用程序1501到重采样程序1502的延时大约为40ms（毫秒），音频采集程序1503接收到第二检测音频数据的第三接收时间为t2，音频数据从重采样程序1502到音频采集程序1503的延时大约在90ms。

需要说明的是，在一种可能实现方式中，服务器不仅将云应用程序生成的音频数据发送至终端，还会将云应用程序生成的视频数据发送至终端，通过对终端播放的音频和视频进行延时检测，发现音频与视频并不同步，从播放视频到播放该视频对应的音频，延时大约在0.37秒左右。当视频与音频的延时高于0.3秒时，人耳能够感觉到比较明显的延时，从而影响用户的体验。如果采样本申请实施例提供的音频数据处理方法，能够减小服务器下发音频数据的延时，将视频到音频的延时降低至0.242秒左右，从而人耳感觉不到明显的延时，提高用户的体验。

本申请实施例提供的延时获取方法，通过检测应用程序发出检测音频数据，获取音频采集程序接收检测音频数据的接收时间，根据发送时间与接收时间的时间差，能够准确得到音频数据从检测应用程序传输至音频采集程序所消耗的时长，也即是得到服务器获取音频数据的时长，该时长能够代表服务器下发音频数据的延时，后续根据该时长能够确定服务器获取音频数据的延时是否会影响音频数据的播放效果，是否会影响终端用户的听觉效果，进而确定是否继续对服务器进行改进，为开发人员提供了较好的改进依据。

另外，还能够获取重采样程序接收到检测音频数据的接收时间，进一步得到检测音频数据从检测应用程序传输至重采样程序所消耗的时长，以及检测音频数据从重采样程序传输至音频采集程序所消耗的时长，从而准确得到音频数据在每个传输阶段所消耗的时长，以便后续开发人员有针对性对服务器进行改进。

需要说明的是，本申请实施例提供的两种音频数据处理方法，对于减小服务器下发音频数据的延时的效果几乎相同，表1是采用本申请实施例提供的任一种音频数据处理方法，得到的视频到音频的延时，以及采用相关技术中其他音频数据处理方法，得到的视频到音频的延时，如表1所示：

表1

其中，产品A采用本申请实施例提供的音频数据处理方法，而产品B和产品C采用其他音频数据处理方法。其中，产品A、产品B和产品C提供有至少一种类型的游戏，该至少一种类型的游戏的应用程序在服务器中运行，也即是，服务器中运行有至少一种类型的云应用程序。

图16是本申请实施例提供的一种服务器的结构示意图，参见图16，该服务器包括：应用运行模块1601、框架运行模块1602、中转模块1603和采集模块1604；

该应用运行模块1601，用于将云应用程序的第一音频数据输入至该框架运行模块1602；

该框架运行模块1602，用于对该第一音频数据进行处理，得到第二音频数据，将该第二音频数据发送至该中转模块1603；

该中转模块1603，用于根据该中转模块1603与该采集模块1604之间的通信连接，将该第二音频数据发送至该采集模块1604，该采集模块1604用于将该第二音频数据发送至终端本地的应用程序。

可选地，该框架运行模块1602，用于若该中转模块1603与该采集模块1604已建立通信连接，则将该第二音频数据发送至该中转模块1603；

该框架运行模块1602，用于若该中转模块1603还未与该采集模块1604建立通信连接，则控制该中转模块1603与该采集模块1604建立通信连接，在该中转模块1603与该采集模块1604成功建立通信连接的情况下，将该第二音频数据发送至该中转模块1603。

可选地，该框架运行模块1602，用于对该第一音频数据进行混音处理，得到第三音频数据，按照音频参数对该第三音频数据进行处理，得到该第二音频数据。

可选地，该框架运行模块1602用于执行以下至少一项：

该音频参数包括目标采样率，按照该目标采样率对该第三音频数据进行重采样处理，得到该第二音频数据；

该音频参数包括目标通道数，按照该目标通道数对该第三音频数据进行通道数转换处理，得到该第二的音频数据；

该音频参数包括目标采样深度，按照该目标采样深度对该第三音频数据进行重采样处理，得到该第二音频数据。

如图17所示，可选地，该框架运行模块1602包括处理单元1612，该处理单元1612用于对该第一音频数据进行混音处理，得到该第三音频数据；

该处理单元1612，用于按照音频参数，对该第三音频数据进行处理，得到该第二音频数据。

可选地，该中转模块1603为硬件抽象层运行模块1613，该框架运行模块1602，用于从该硬件抽象层运行模块1613获取该音频参数，该硬件抽象层运行模块行模块1613存储有音频参数。

可选地，该中转模块1603为硬件抽象层运行模块1613，该框架运行模块1602，用于调用该硬件抽象层运行模块1613的写入接口，将该第二音频数据写入该硬件抽象层运行模块1613。

如图18所示，可选地，该中转模块1603为重采样模块1623，该框架运行模块1602，还用于从该重采样模块1623获取该音频参数，该重采样模块1623配置有音频参数。

可选地，该中转模块1603为重采样模块1623；

该重采样模块1623，还用于对该第二音频数据进行重采样处理，得到处理后的第二音频数据；

该重采样模块1623，用于根据该重采样模块1623与该采集模块1604之间的通信连接，将该处理后的第二音频数据发送至该采集模块1604。

可选地，该框架运行模块1602包括录制单元1622；

该重采样模块1623，用于将该第二音频数据发送至该录制单元1622；

该录制单元1622，用于对该第二音频数据进行录制，得到第三音频数据；

该采集模块1604，用于调用音频录制接口，从该录制单元1622中读取该第三音频数据。

可选地，该采集模块1604，用于丢弃该第三音频数据，将该第二音频数据发送至终端本地的应用程序。

图19是本申请实施例提供的一种服务器的结构示意图，参见图19，该服务器包括：应用运行模块1901、框架运行模块1902、中转模块1903、采集模块1904、记录模块1905和获取模块1906；

该应用运行模块1901，用于将检测应用程序的第一检测音频数据输入至该框架运行模块1902；

该记录模块1905，用于记录该第一检测音频数据的发送时间；

该框架运行模块1902，用于对该第一检测音频数据进行处理，得到第二检测音频数据，将该第二检测音频数据发送至该中转模块1903；

该中转模块1903，用于根据该中转模块1903与该采集模块1904之间的通信连接，将该第二检测音频数据发送至该采集模块1904，该采集模块1904用于将该第二检测音频数据发送至终端本地的应用程序；

该记录模块1905，还用于记录该采集模块1904接收该第二检测音频数据的第一接收时间；

该获取模块1906，用于获取该发送时间和该第一接收时间的第一时间差，该第一时间差表示该检测音频数据从该应用运行模块1901传输至该采集模块1904的延时。

可选地，该记录模块1905，还用于记录该中转模块接收该第二检测音频数据的第二接收时间；

该获取模块1906，用于获取该发送时间与该第二接收时间之间的第二时间差，该第二时间差表示该检测音频数据从该应用运行模块1901传输至该中转模块1903的延时。

可选地，该中转模块1903为硬件抽象层运行模块；或者，该中转模块903为重采样模块。

图20是本申请实施例提供的一种终端的结构框图。该终端2000用于执行上述实施例中终端执行的步骤，可选地，该终端2000是便携式移动终端，比如：智能手机、平板电脑、MP3播放器（Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3）、MP4（Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面4）播放器、笔记本电脑或台式电脑。终端2000还可能被称为用户设备、便携式终端、膝上型终端、台式终端等其他名称。

通常，终端2000包括有：处理器2001和存储器2002。

处理器2001可以包括一个或多个处理核心，比如4核心处理器、8核心处理器等。处理器2001可以采用DSP（Digital Signal Processing，数字信号处理）、FPGA（Field－Programmable Gate Array，现场可编程门阵列）、PLA（Programmable Logic Array，可编程逻辑阵列）中的至少一种硬件形式来实现。处理器2001也可以包括主处理器和协处理器，主处理器是用于对在唤醒状态下的数据进行处理的处理器，也称CPU（Central ProcessingUnit，中央处理器）；协处理器是用于对在待机状态下的数据进行处理的低功耗处理器。在一些实施例中，处理器2001可以集成有GPU（Graphics Processing Unit，图像处理器），GPU用于负责显示屏所需要显示的内容的渲染和绘制。一些实施例中，处理器2001还可以包括AI（Artificial Intelligence，人工智能）处理器，该AI处理器用于处理有关机器学习的计算操作。

存储器2002可以包括一个或多个计算机可读存储介质，该计算机可读存储介质可以是非暂态的。存储器2002还可包括高速随机存取存储器，以及非易失性存储器，比如一个或多个磁盘存储设备、闪存存储设备。在一些实施例中，存储器2002中的非暂态的计算机可读存储介质用于存储至少一个程序代码，该至少一个程序代码用于被处理器2001所执行以实现本申请中方法实施例提供的音频数据处理方法，或者延时获取方法。

在一些实施例中，终端2000还可选包括有：外围设备接口2003和至少一个外围设备。处理器2001、存储器2002和外围设备接口2003之间可以通过总线或信号线相连。各个外围设备可以通过总线、信号线或电路板与外围设备接口2003相连。具体地，外围设备包括：射频电路2004、显示屏2005、摄像头组件2006、音频电路2007、定位组件2008和电源2009中的至少一种。

外围设备接口2003可被用于将I/O（Input /Output，输入/输出）相关的至少一个外围设备连接到处理器2001和存储器2002。在一些实施例中，处理器2001、存储器2002和外围设备接口2003被集成在同一芯片或电路板上；在一些其他实施例中，处理器2001、存储器2002和外围设备接口2003中的任意一个或两个可以在单独的芯片或电路板上实现，本申请实施例对此不加以限定。

射频电路2004用于接收和发射RF（Radio Frequency，射频）信号，也称电磁信号。射频电路2004通过电磁信号与通信网络以及其他通信设备进行通信。射频电路2004将电信号转换为电磁信号进行发送，或者，将接收到的电磁信号转换为电信号。可选地，射频电路2004包括：天线系统、RF收发器、一个或多个放大器、调谐器、振荡器、数字信号处理器、编解码芯片组、用户身份模块卡等等。射频电路2004可以通过至少一种无线通信协议来与其它终端进行通信。该无线通信协议包括但不限于：万维网、城域网、内联网、各代移动通信网络（2G、3G、4G及5G）、无线局域网和/或WiFi(Wireless Fidelity，无线保真）网络。在一些实施例中，射频电路2004还可以包括NFC（Near Field Communication，近距离无线通信）有关的电路，本申请对此不加以限定。

显示屏2005用于显示UI（User Interface，用户界面）。该UI可以包括图形、文本、图标、视频及其它们的任意组合。当显示屏2005是触摸显示屏时，显示屏2005还具有采集在显示屏2005的表面或表面上方的触摸信号的能力。该触摸信号可以作为控制信号输入至处理器2001进行处理。此时，显示屏2005还可以用于提供虚拟按钮和/或虚拟键盘，也称软按钮和/或软键盘。在一些实施例中，显示屏2005可以为一个，设置终端2000的前面板；在另一些实施例中，显示屏2005可以为至少两个，分别设置在终端2000的不同表面或呈折叠设计；在另一些实施例中，显示屏2005可以是柔性显示屏，设置在终端2000的弯曲表面上或折叠面上。甚至，显示屏2005还可以设置成非矩形的不规则图形，也即异形屏。显示屏2005可以采用LCD(Liquid Crystal Display，液晶显示屏)、OLED(Organic Light-Emitting Diode,有机发光二极管)等材质制备。

摄像头组件2006用于采集图像或视频。可选地，摄像头组件2006包括前置摄像头和后置摄像头。通常，前置摄像头设置在终端的前面板，后置摄像头设置在终端的背面。在一些实施例中，后置摄像头为至少两个，分别为主摄像头、景深摄像头、广角摄像头、长焦摄像头中的任意一种，以实现主摄像头和景深摄像头融合实现背景虚化功能、主摄像头和广角摄像头融合实现全景拍摄以及VR（Virtual Reality，虚拟现实）拍摄功能或者其它融合拍摄功能。在一些实施例中，摄像头组件2006还可以包括闪光灯。闪光灯可以是单色温闪光灯，也可以是双色温闪光灯。双色温闪光灯是指暖光闪光灯和冷光闪光灯的组合，可以用于不同色温下的光线补偿。

音频电路2007可以包括麦克风和扬声器。麦克风用于采集用户及环境的声波，并将声波转换为电信号输入至处理器2001进行处理，或者输入至射频电路2004以实现语音通信。出于立体声采集或降噪的目的，麦克风可以为多个，分别设置在终端2000的不同部位。麦克风还可以是阵列麦克风或全向采集型麦克风。扬声器则用于将来自处理器2001或射频电路2004的电信号转换为声波。扬声器可以是传统的薄膜扬声器，也可以是压电陶瓷扬声器。当扬声器是压电陶瓷扬声器时，不仅可以将电信号转换为人类可听见的声波，也可以将电信号转换为人类听不见的声波以进行测距等用途。在一些实施例中，音频电路2007还可以包括耳机插孔。

定位组件2008用于定位终端2000的当前地理位置，以实现导航或LBS（LocationBased Service，基于位置的服务）。定位组件2008可以是基于美国的GPS（GlobalPositioning System，全球定位系统）、中国的北斗系统或俄罗斯的格雷纳斯系统或欧盟的伽利略系统的定位组件。

电源2009用于为终端2000中的各个组件进行供电。电源2009可以是交流电、直流电、一次性电池或可充电电池。当电源2009包括可充电电池时，该可充电电池可以支持有线充电或无线充电。该可充电电池还可以用于支持快充技术。

在一些实施例中，终端2000还包括有一个或多个传感器2010。该一个或多个传感器2010包括但不限于：加速度传感器2011、陀螺仪传感器2012、压力传感器2013、指纹传感器2014、光学传感器2015以及接近传感器2016。

加速度传感器2011可以检测以终端2000建立的坐标系的三个坐标轴上的加速度大小。比如，加速度传感器2011可以用于检测重力加速度在三个坐标轴上的分量。处理器2001可以根据加速度传感器2011采集的重力加速度信号，控制显示屏2005以横向视图或纵向视图进行用户界面的显示。加速度传感器2011还可以用于游戏或者用户的运动数据的采集。

陀螺仪传感器2012可以检测终端2000的机体方向及转动角度，陀螺仪传感器2012可以与加速度传感器2011协同采集用户对终端2000的3D动作。处理器2001根据陀螺仪传感器2012采集的数据，可以实现如下功能：动作感应（比如根据用户的倾斜操作来改变UI）、拍摄时的图像稳定、游戏控制以及惯性导航。

压力传感器2013可以设置在终端2000的侧边框和/或显示屏2005的下层。当压力传感器2013设置在终端2000的侧边框时，可以检测用户对终端2000的握持信号，由处理器2001根据压力传感器2013采集的握持信号进行左右手识别或快捷操作。当压力传感器2013设置在显示屏2005的下层时，由处理器2001根据用户对显示屏2005的压力操作，实现对UI界面上的可操作性控件进行控制。可操作性控件包括按钮控件、滚动条控件、图标控件、菜单控件中的至少一种。

指纹传感器2014用于采集用户的指纹，由处理器2001根据指纹传感器2014采集到的指纹识别用户的身份，或者，由指纹传感器2014根据采集到的指纹识别用户的身份。在识别出用户的身份为可信身份时，由处理器2001授权该用户执行相关的敏感操作，该敏感操作包括解锁屏幕、查看加密信息、下载软件、支付及更改设置等。指纹传感器2014可以被设置终端2000的正面、背面或侧面。当终端2000上设置有物理按键或厂商Logo时，指纹传感器2014可以与物理按键或厂商标志集成在一起。

光学传感器2015用于采集环境光强度。在一个实施例中，处理器2001可以根据光学传感器2015采集的环境光强度，控制显示屏2005的显示亮度。具体地，当环境光强度较高时，调高显示屏2005的显示亮度；当环境光强度较低时，调低显示屏2005的显示亮度。在另一个实施例中，处理器2001还可以根据光学传感器2015采集的环境光强度，动态调整摄像头组件2006的拍摄参数。

接近传感器2016，也称距离传感器，通常设置在终端2000的前面板。接近传感器2016用于采集用户与终端2000的正面之间的距离。在一个实施例中，当接近传感器2016检测到用户与终端2000的正面之间的距离逐渐变小时，由处理器2001控制显示屏2005从亮屏状态切换为息屏状态；当接近传感器2016检测到用户与终端2000的正面之间的距离逐渐变大时，由处理器2001控制显示屏2005从息屏状态切换为亮屏状态。

本领域技术人员可以理解，图20中示出的结构并不构成对终端2000的限定，可以包括比图示更多或更少的组件，或者组合某些组件，或者采用不同的组件布置。

图21是本申请实施例提供的一种服务器的结构示意图，该服务器2100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器（Central ProcessingUnits，CPU）2101和一个或一个以上的存储器2102，其中，存储器2102中存储有至少一条程序代码，至少一条程序代码由处理器2101加载并执行以实现上述各个方法实施例提供的方法。当然，该服务器还可以具有有线或无线网络接口、键盘以及输入输出接口等部件，以便进行输入输出，该服务器还可以包括其他用于实现设备功能的部件，在此不做赘述。

服务器2100可以用于执行上述音频数据处理方法中服务器所执行的步骤；或者，用于执行上述延时获取方法中服务器所执行的步骤。

本申请实施例还提供了一种计算机设备，该计算机设备包括处理器和存储器，该存储器中存储有至少一条程序代码，该至少一条程序代码由该处理器加载并执行以实现上述实施例所述的音频数据处理方法中所执行的操作；或者，以实现上述实施例所述的延时获取方法中所执行的操作。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有至少一条程序代码，该至少一条程序代码由处理器加载并执行以实现上述实施例所述的音频数据处理方法中所执行的操作；或者，以实现上述实施例所述的延时获取方法中所执行的操作。

本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机程序代码，该计算机程序代码存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机程序代码，处理器执行该计算机程序代码，使得该计算机设备实现所述的音频数据处理方法中所执行的操作；或者，实现上述实施例所述的延时获取方法中所执行的操作。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来程序代码相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的可选实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (15)

1.一种音频数据处理方法，其特征在于，所述方法应用于服务器，所述服务器包括云应用程序、系统框架、中转程序和音频采集程序，所述方法包括：

将所述云应用程序的第一音频数据输入至所述系统框架；

通过所述系统框架对所述第一音频数据进行处理，得到第二音频数据，将所述第二音频数据发送至所述中转程序；

通过所述中转程序，根据所述中转程序与所述音频采集程序之间的通信连接，将所述第二音频数据发送至所述音频采集程序，所述音频采集程序用于将所述第二音频数据发送至终端本地的应用程序。

2.根据权利要求1所述的方法，其特征在于，所述将所述第二音频数据发送至所述中转程序，包括：

若所述中转程序与所述音频采集程序已建立通信连接，则将所述第二音频数据发送至所述中转程序；

若所述中转程序还未与所述音频采集程序建立通信连接，则控制所述中转程序与所述音频采集程序建立通信连接，在所述中转程序与所述音频采集程序成功建立通信连接的情况下，将所述第二音频数据发送至所述中转程序。

3.根据权利要求1所述的方法，其特征在于，所述通过所述系统框架对所述第一音频数据进行处理，得到第二音频数据，包括：

通过所述系统框架，对所述第一音频数据进行混音处理，得到第三音频数据；

通过所述系统框架，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据。

4.根据权利要求3所述的方法，其特征在于，所述通过所述系统框架，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据，包括以下至少一项：

所述音频参数包括目标采样率，通过所述系统框架，按照所述目标采样率对所述第三音频数据进行重采样处理，得到所述第二音频数据；

所述音频参数包括目标通道数，通过所述系统框架，按照所述目标通道数对所述第三音频数据进行通道数转换处理，得到所述第二音频数据；

所述音频参数包括目标采样深度，通过所述系统框架，按照所述目标采样深度对所述第三音频数据进行重采样处理，得到所述第二音频数据。

5.根据权利要求3所述的方法，其特征在于，所述系统框架包括处理线程，所述通过所述系统框架，对所述第一音频数据进行混音处理，得到第三音频数据，包括：

通过所述处理线程对所述第一音频数据进行混音处理，得到所述第三音频数据；

所述通过所述系统框架，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据，包括；

通过所述处理线程，按照所述音频参数对所述第三音频数据进行处理，得到所述第二音频数据。

6.根据权利要求3所述的方法，其特征在于，所述中转程序为硬件抽象层，所述通过所述系统框架，按照音频参数对所述第三音频数据进行处理，得到所述第二音频数据之前，所述方法还包括：

通过所述系统框架从所述硬件抽象层获取所述音频参数，所述硬件抽象层存储有所述音频参数。

7.根据权利要求1所述的方法，其特征在于，所述中转程序为硬件抽象层，所述将所述第二音频数据发送至所述中转程序，包括：

通过所述系统框架调用所述硬件抽象层的写入接口，将所述第二音频数据写入所述硬件抽象层。

8.根据权利要求1所述的方法，其特征在于，所述中转程序为重采样程序，所述通过所述中转程序，根据所述中转程序与所述音频采集程序之间的通信连接，将所述第二音频数据发送至所述音频采集程序，包括：

通过所述重采样程序，对所述第二音频数据进行重采样处理，得到处理后的第二音频数据；

通过所述重采样程序，根据所述重采样程序与所述音频采集程序之间的通信连接，将所述处理后的第二音频数据发送至所述音频采集程序。

9.根据权利要求1所述的方法，其特征在于，所述中转程序为重采样程序，所述系统框架包括录制线程，所述将所述第二音频数据发送至所述中转程序之后，所述方法还包括：

通过所述重采样程序，将所述第二音频数据发送至所述录制线程；

通过所述录制线程对所述第二音频数据进行录制，得到第三音频数据；

通过所述音频采集程序，调用音频录制接口从所述录制线程中读取所述第三音频数据。

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

通过所述音频采集程序，丢弃所述第三音频数据，将所述第二音频数据发送至所述终端本地的应用程序。

11.一种延时获取方法，其特征在于，所述方法应用于服务器，所述服务器包括检测应用程序、系统框架、中转程序和音频采集程序，所述方法包括：

将所述检测应用程序的第一检测音频数据输入至所述系统框架，记录所述第一检测音频数据的发送时间；

通过所述系统框架对所述第一检测音频数据进行处理，得到第二检测音频数据，将所述第二检测音频数据发送至所述中转程序；

通过所述中转程序，根据所述中转程序与所述音频采集程序之间的通信连接，将所述第二检测音频数据发送至所述音频采集程序，记录所述音频采集程序接收所述第二检测音频数据的第一接收时间，所述音频采集程序用于将所述第二检测音频数据发送至终端本地的应用程序；

获取所述发送时间和所述第一接收时间之间的第一时间差，所述第一时间差表示检测音频数据从所述检测应用程序传输至所述音频采集程序的延时。

12.根据权利要求11所述的方法，其特征在于，所述将所述第二检测音频数据发送至所述中转程序之后，所述方法还包括：

记录所述中转程序接收所述第二检测音频数据的第二接收时间；

获取所述发送时间与所述第二接收时间之间的第二时间差，所述第二时间差表示检测音频数据从所述检测应用程序传输至所述中转程序的延时。

13.一种服务器，其特征在于，所述服务器包括应用运行模块、框架运行模块、中转模块和采集模块；

所述应用运行模块，用于将云应用程序的第一音频数据输入至所述框架运行模块；

所述框架运行模块，用于对所述第一音频数据进行处理，得到第二音频数据，将所述第二音频数据发送至所述中转模块；

所述中转模块，用于根据所述中转模块与所述采集模块之间的通信连接，将所述第二音频数据发送至所述采集模块，所述采集模块用于将所述第二音频数据发送至终端本地的应用程序。

14.一种服务器，其特征在于，所述服务器包括应用运行模块、框架运行模块、中转模块、采集模块、记录模块和获取模块，

所述应用运行模块，用于将检测应用程序的第一检测音频数据输入至所述框架运行模块；

所述记录模块，用于记录所述第一检测音频数据的发送时间；

所述框架运行模块，用于对所述第一检测音频数据进行处理，得到第二检测音频数据，将所述第二检测音频数据发送至所述中转模块；

所述中转模块，用于根据所述中转模块与所述采集模块之间的通信连接，将所述第二检测音频数据发送至所述采集模块，所述采集模块用于将所述第二检测音频数据发送至终端本地的应用程序；

所述记录模块，还用于记录所述采集模块接收所述第二检测音频数据的第一接收时间；

所述获取模块，用于获取所述发送时间和所述第一接收时间的第一时间差，所述第一时间差表示检测音频数据从所述应用运行模块传输至所述采集模块的延时。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有至少一条程序代码，所述至少一条程序代码由处理器加载并执行以实现如权利要求1至10任一项所述的音频数据处理方法中所执行的操作；或者，以实现如权利要求11至12任一项所述的延时获取方法中所执行的操作。

Images