CN112786070A - 音频数据处理方法、装置、存储介质与电子设备 - Google Patents

Abstract

本公开提供了一种音频数据处理方法、音频数据处理装置、计算机可读存储介质与电子设备，涉及音频处理技术领域。其中，所述音频数据处理方法包括：将待播放的原始音频数据输入框架层，通过所述框架层对所述原始音频数据进行处理，得到目标音频数据；从所述框架层提取所述目标音频数据，并对所提取的目标音频数据进行检测。本公开提高了音频异常情况的检测效率。

Description

音频数据处理方法、装置、存储介质与电子设备

技术领域

本公开涉及音频处理技术领域，尤其涉及一种音频数据处理方法、音频数据处理装置、计算机可读存储介质与电子设备。

背景技术

在听音乐、看视频、语音通话等场景中，终端设备需要接收外部发送的音频并播放，有时会发生音频卡顿等异常情况，影响用户体验。相关技术缺乏对音频异常情况进行高效检测的方案。

发明内容

本公开提供了一种音频数据处理方法、音频数据处理装置、计算机可读存储介质与电子设备，进而至少在一定程度上提高音频异常情况的检测效率。

根据本公开的第一方面，提供一种音频数据处理方法，包括：将待播放的原始音频数据输入框架层，通过所述框架层对所述原始音频数据进行处理，得到目标音频数据；从所述框架层提取所述目标音频数据，并对所提取的目标音频数据进行检测。

根据本公开的第二方面，提供一种音频数据处理装置，包括：框架层数据处理单元，被配置为将待播放的原始音频数据输入框架层，通过所述框架层对所述原始音频数据进行处理，得到目标音频数据；目标音频数据检测单元，被配置为从所述框架层提取所述目标音频数据，并对所提取的目标音频数据进行检测。

根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面的音频数据处理方法及其可能的实现方式。

根据本公开的第四方面，提供一种电子设备，包括：处理器；存储器，用于存储所述处理器的可执行指令。其中，所述处理器配置为经由执行所述可执行指令来执行上述第一方面的音频数据处理方法及其可能的实现方式。

本公开的技术方案具有以下有益效果：

在音频数据处理过程中，从框架层提取处理后的目标音频数据进行检测，相当于在音频数据处理过程的最后一个节点进行检测，能够检测出任何环节所导致的音频异常情况，从而提高了检测效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

图1示出本示例性实施方式中一种电子设备的结构示意图；

图2示出本示例性实施方式中一种音频数据处理方法的流程图；

图3示出本示例性实施方式中一种音频数据传输的示意图；

图4示出本示例性实施方式中一种音频数据处理的示意图；

图5示出本示例性实施方式中一种提取目标音频数据方法的流程图；

图6示出本示例性实施方式中一种检测断音方法的流程图；

图7示出本示例性实施方式中目标音频数据中空白数据段的示意图；

图8示出本示例性实施方式中一种音频异常检测方法的流程图；

图9示出本示例性实施方式中一种音频数据处理装置的结构示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

附图中所示的流程图仅是示例性说明，不是必须包括所有的步骤。例如，有的步骤还可以分解，而有的步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。

在音频的传输与处理过程中，任何一个环节都可能导致音频异常，例如网络连接波动、音频重采样异常等。相关技术的一种方案中，实时抓取网络中传输的音频数据包以进行异常分析，这样仅能检测出网络传输导致的异常情况，而无法检测出接收音频之后的处理过程中产生的异常情况，因此实际检测效果较差。

鉴于上述问题，本公开的示例性实施方式首先提供一种音频数据处理方法，其应用场景包括但不限于：在云游戏场景中，用户A和用户B进行联机游戏并保持语音通话，用户A输入的语音通过云服务器发送至用户B，在用户B的终端(下称终端B)上进行处理并播放，用户B输入的语音通过云服务器发送至用户A，在用户A的终端(下称终端A)上进行处理并播放，同时云服务器还向用户A和用户B发送游戏音频；可以在用户A和用户B的终端上执行本示例性实施方式中的音频数据处理方法，以检测语音或游戏音频是否存在异常，从而在异常时采取相应的措施。

本公开的示例性实施方式还提供一种电子设备，可以是上述终端A或终端B，用于执行本示例性实施方式中的音频数据处理方法。该电子设备包括但不限于智能手机、平板电脑、可穿戴设备(如增强现实眼镜)、个人电脑等。一般的，电子设备包括处理器、存储器和通信模块。存储器用于存储处理器的可执行指令，也可以存储应用数据，如音频数据、视频数据等；处理器配置为经由执行可执行指令来执行本示例性实施方式中的音频数据处理方法。

下面以图1中的移动终端100为例，对上述电子设备的构造进行示例性说明。本领域技术人员应当理解，除了特别用于移动目的的部件之外，图1中的构造也能够应用于固定类型的设备。

如图1所示，移动终端100具体可以包括：处理器110、内部存储器121、外部存储器接口122、USB(Universal Serial Bus，通用串行总线)接口130、充电管理模块140、电源管理模块141、电池142、天线1、天线2、移动通信模块150、无线通信模块160、音频模块170、扬声器171、受话器172、麦克风173、耳机接口174、传感器模块180、显示屏190、摄像模组191、指示器192、马达193、按键194以及SIM(Subscriber Identification Module，用户标识模块)卡接口195等。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括AP(Application Processor，应用处理器)、调制解调处理器、GPU(Graphics ProcessingUnit，图形处理器)、ISP(Image Signal Processor，图像信号处理器)、控制器、编码器、解码器、DSP(Digital Signal Processor，数字信号处理器)、基带处理器和/或NPU(Neural-Network Processing Unit，神经网络处理器)等。

在一种实施方式中，处理器110可以包括一个或多个接口，通过不同的接口和移动终端100的其他部件形成连接。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括易失性存储器与非易失性存储器。处理器110通过运行存储在内部存储器121的指令，执行移动终端100的各种功能应用以及数据处理。

外部存储器接口122可以用于连接外部存储器，例如Micro SD卡，实现扩展移动终端100的存储能力。外部存储器通过外部存储器接口122与处理器110通信，实现数据存储功能，例如存储音频、视频等文件。

USB接口130是符合USB标准规范的接口，可以用于连接充电器为移动终端100充电，也可以连接耳机或其他电子设备。

充电管理模块140用于从充电器接收充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为设备供电；电源管理模块141还可以监测电池的状态。

移动终端100的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等实现。天线1和天线2用于发射和接收电磁波信号。移动通信模块150可以提供应用在移动终端100上的包括2G/3G/4G/5G等无线通信的解决方案。无线通信模块160可以提供应用在移动终端100上的包括WLAN(Wireless LocalArea Networks，无线局域网)(如Wi-Fi(Wireless Fidelity，无线保真)网络)、BT(Bluetooth，蓝牙)、GNSS(Global Navigation Satellite System，全球导航卫星系统)、FM(Frequency Modulation，调频)、NFC(Near Field Communication，近距离无线通信技术)、IR(Infrared，红外技术)等无线通信解决方案。

移动终端100可以通过GPU、显示屏190及AP等实现显示功能，显示用户界面。例如，当用户开启拍摄功能时，移动终端100可以在显示屏190中显示拍摄界面和预览图像等。

移动终端100可以通过ISP、摄像模组191、编码器、解码器、GPU、显示屏190及AP等实现拍摄功能。

移动终端100可以通过音频模块170、扬声器171、受话器172、麦克风173、耳机接口174及AP等实现音频功能。例如音乐播放、录音等。音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。在一些实施方式中，DSP可以设置于音频模块170中，用于进行数字音频信息与模拟音频信号的互相转换，或者对数字音频信息进行可调谐的算法处理等。音频模块170还可以用于对音频信号编码和解码。扬声器171，用于将音频电信号转换为声音信号。受话器172，用于将音频电信号转换成声音信号。麦克风173，用于将声音信号转换为音频电信号。耳机接口174用于连接耳机或外置音箱。

传感器模块180可以包括深度传感器1801、压力传感器1802、陀螺仪传感器1803、气压传感器1804等，以实现相应的感应检测功能。

指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。马达193可以产生振动提示，也可以用于触摸振动反馈等。按键194包括开机键，音量键等。

移动终端100可以支持一个或多个SIM卡接口195，用于连接SIM卡，以实现通话与移动通信等功能。

下面以运行Android系统的电子设备为例，结合图2对本示例性实施方式的音频数据处理方法进行说明，应当理解，该音频数据处理方法同样适用于运行其他系统(如iOS系统)的电子设备。

图2示出了音频数据处理方法的示例性流程，可以包括：

步骤S210，将待播放的原始音频数据输入框架层，通过框架层对原始音频数据进行处理，得到目标音频数据；

步骤S220，从框架层提取目标音频数据，并对所提取的目标音频数据进行检测。

通过上述方法，在音频数据处理过程中，从框架层提取处理后的目标音频数据进行检测，相当于在音频数据处理过程的最后一个节点进行检测，能够检测出任何环节所导致的音频异常情况，从而提高了检测效率。

下面对图2中的每个步骤进行详细说明。

步骤S210中，将待播放的原始音频数据输入框架层，通过框架层对原始音频数据进行处理，得到目标音频数据。

其中，原始音频数据是需要播放的音频数据，可以是本地存储的音频数据，也可以是从外部接收的音频数据。

在一种实施方式中，步骤S210之前，可以执行以下步骤：

通过网络连接接收由外部发送的所述原始音频数据

举例来说，终端A可以通过运营商网络与服务器(如游戏服务器、音乐服务器、视频服务器)建立网络连接，接收服务器发送的原始音频数据。终端A也可以通过WLAN、BT、NFC等与终端B建立网络接接，接收终端B发送的原始音频数据。

在一种实施方式中，终端A可以通过App(Application，应用程序)来获取原始音频数据。以图3为例进行说明，终端A 310和终端B 320运行云游戏App，均与云服务器330建立网络连接；终端A 310和终端B 320联机游戏，例如可以加入云服务器330上建立的同一云游戏房间；终端A 310和终端B 320开启云游戏的语音功能，当用户B输入语音时，语音信息经过终端B 320底层、框架层处理为音频数据，通过云游戏App向云服务器330发送；云服务器330将音频数据发送至终端A 310，终端A 310可以通过云游戏App接收音频数据，得到的即原始音频数据。

原始音频数据通常是数字音频信息，例如用户B输入的语音为模拟音频信号，通过ADC(Analog-to-Digital Converter，模拟-数字转换器)转换为数字音频信息，并经过一定的方式进行音频优化与编码，得到原始音频数据。在一种实施方式中，原始音频数据可以是经过PCM编码(Pulse Code Modulation，脉冲编码调制)的音频数据。

框架层(Framework)可以包括应用程序的各种API(Application ProgrammingInterface，应用程序接口)，用于提供系统级服务，例如音频数据处理的相关服务。本示例性实施方式中，框架层可以包括音频数据处理的系统库，或者调用相关的系统库以执行音频数据处理。

参考上述图3所示，将原始音频数据输入框架层，经过框架的处理得到目标音频数据。目标音频数据可以被继续输入底层，通过DAC(Digital-to-Analog Converter，数字-模拟转换器)转换为模拟音频信号并进行播放。

在一种实施方式中，通过框架层对原始音频数据进行处理，可以包括：

通过框架层中的多个音频数据处理节点依次对原始音频数据进行处理。

其中，音频数据处理节点可以是音频服务的相关进程，每个音频数据处理节点可以对音频数据进行一种处理。参考图4所示，音频数据处理节点可以包括：重采样(resample)节点、混音(audio mix)节点、音效处理(audio effect)节点，其分别用于对音频数据进行重采样处理、混音处理、音效处理。原始音频数据进入框架层后，依次经过重采样节点、混音节点、音效处理节点的处理，得到目标音频数据。

继续参考图2，步骤S220中，从框架层提取目标音频数据，并对所提取的目标音频数据进行检测。

一般的，在音频数据处理过程中，导致音频异常的环节包括但不限于：音频输入处理的环节，例如图3中终端B 320的麦克风异常，导致录制的音频数据异常；通过网络连接接收原始音频数据的环节，例如网络连接波动导致音频数据丢包；框架层对原始音频数据进行处理的环节，例如图3中终端A310运行了过多的程序导致原始音频数据处理时资源不足，导致得到的目标音频数据异常。上述各环节的异常最终都会导致目标音频数据的异常。因此，本示例性实施方式从框架层提取目标音频数据并进行检测，无论上述哪个环节存在异常，都可以检测出目标音频数据的异常，从而提高检测效率。

在一种实施方式中，步骤S210之后，还可以执行以下步骤：

将目标音频数据从框架层输入硬件抽象层。

硬件抽象层(Hardware Abstraction Layer，HAL)是位于操作系统内核与硬件电路之间的接口层，可以通过硬件抽象化组件对目标音频数据处理，执行框架层之后的处理环节。例如，图3与图4中的底层可以包括硬件抽象层，此外还可以包括驱动层等。

为了保证音频的播放，使步骤S220对于目标音频数据的播放处理不产生影响。在提取目标音频数据时，可以从框架层复制目标音频数据，所复制的目标音频数据用于检测，同时将原本的目标音频数据输入硬件抽象层，用于播放处理。由此，音频的检测与播放是并行执行的过程，目标音频数据从框架层传输至硬件抽象层的过程不受步骤S220的影响，减少由于检测目标音频数据所导致的播放延迟。

参考上述图4所示，可以在框架层的各音频数据处理节点之后设置检测节点，该检测节点可以位于音效处理节点(即最后一个音频数据处理节点)之后，可以是检测目标音频数据的专用进程。音效处理节点输出的音频数据即目标音频数据。在一种实施方式中，可以将目标音频数据从音效处理节点直接输入检测节点，由检测节点进行检测后再输入底层，即执行先检测后播放，这样节省了目标音频数据所占的内存资源，同时可以在播放前检测出音频异常情况，有利于在播放中进行相应的调整。在另一种实施方式中，可以将目标音频数据复制为两份，一份输入检测节点，另一份输入底层，即同时执行检测与播放，这样能够减少由于检测目标音频数据所导致的播放延迟。

为了进一步减少音频播放延迟，在一种实施方式中，参考图5所示，上述从框架层复制目标音频数据，可以包括以下步骤S510和S520：

步骤S510，复制目标音频数据，并存储至框架层的缓存数据中；

步骤S520，从框架层的缓存数据中读取目标音频数据。

对于框架层的音频数据处理环节，可以设置缓存的机制：在框架层中最后一个节点(例如图4所示的音效处理节点)处理音频数据时，可以将所得到的目标音频数据复制并存储至框架层的缓存数据中。后续再从缓存数据中读取目标音频数据。由此，在音效处理节点处理音频数据时，可以将处理完成的数据立即复制并写入缓存数据，同时向底层输入目标音频数据。该过程无需等待检测节点，即使检测节点的运行发生卡顿，导致读取目标音频数据延迟，也可以从缓存数据中读取完整的目标音频数据，不影响目标音频数据向底层的传输，从而进一步减少音频播放延迟。

检测目标音频数据的目的是确定目标音频数据是否存在异常，例如断音、杂音等。进而，可以采取相应的措施，例如关闭系统中的无用进程，为音频数据处理留出更多资源，或者对网络连接状况进行检测，发出网络异常的提示信息，或者在音视频同时传输的场景中，降低视频数据的清晰度、帧率等标准，以减少对网络带宽的占用，改善丢包的情况。

在一种实施方式中，参考图6所示，上述对提取的目标音频数据进行检测，可以包括以下步骤S610和S620：

步骤S610，检测目标音频数据中的数据是否为0，以确定目标音频数据中的空白数据段。

在音频数据的传输中，如果丢失了部分数据，通常填充0。空白数据段是指目标音频数据中数据均为0的数据段。

在一种实施方式中，可以按照目标音频数据中的时间戳，依次检测目标音频数据中的数据是否为0；当检测连续为0的数据且该连续为0的数据达到预设时长时，确定该连续为0的数据为空白数据段。其中，目标音频数据中的数据具有时间戳，可以是生成时间、接收时间或者在整个目标音频数据中的时间偏移值等。一般的，目标音频数据中的数据按照时间戳的顺序排列，可以以数据流的形式输入框架层与各个节点。由此，可以依此检测所读取的每个数据是否为0。预设时长是空白数据段的时长标准，可以根据经验与实际需求确定，例如人耳可识别5ms的断音数据，因此可以将5ms作为预设时长，当检测到一段连续为0的数据，且时间戳的跨度达到5ms时，确定出现空白数据段。图7示出了目标音频数据中的空白数据段，被框出的部分，数据连续为0且超过5ms，因此为空白数据段。

步骤S620，当检测到目标音频数据中存在预设数量的空白数据段时，确定目标音频数据中存在断音。

出现一个空白数据段，可以认为发生一次理论上的断音，但是这样的断音可能是一些系统误差引起的。为了确保存在实际断音情况，设置预设数量的标准，当检测到目标音频数据中存在预设数量的空白数据段，确定存在断音。预设数量是实际断音的衡量标准，可以根据经验或实际需求设定。需要说明的是，在执行步骤S620时，通常在一定的时长范围内判断，例如可以对目标音频数据进行周期性检测，如以每2秒为一个周期，在2秒结束时检测这2秒时间段以内的目标音频数据，如果这一段目标音频数据中空白数据段的数量达到预设数量(例如为10)，则可以认为这2秒内存在断音。

在一种实施方式中，可以根据原始音频数据的声源类型，确定上述预设数量，也可以确定上述预设时长。其中，声源类型包括但不限于：语音，音乐，短视频，影视剧等。不同声源类型的音频中断音的情况一般也不同，例如正常情况下，语音存在断音的情况(如说话人的说话间隔)，音乐不存在断音的情况，等等。示例性的，可以由服务器选取正常的音频数据，检测并统计其中发生正常断音的数量或时长，在此基础上确定用于异常检测的上述预设数量或预设时长。

目标音频数据中的异常反映了在整个音频处理流程中存在一个或多个环节的异常。为了对异常环节进行定位，在一种实施方式中，参考图8所示，音频数据处理方法还可以包括：

步骤S810，当检测到目标音频数据存在异常时，从各音频数据处理节点处提取对原始音频数据处理所得到的中间音频数据；

步骤S820，对中间音频数据进行检测，以确定导致目标音频数据异常的音频数据处理节点。

需要说明的是，中间音频数据是指从原始音频数据到目标音频数据的处理过程中，所得到的一个或多个中间版本的音频数据。参考上述图4所示，通过云游戏App接收原始音频数据后，所经历的每个节点都可能对数据进行一定的处理与修改，导致数据产生变化，得到中间音频数据。例如重采样节点处理前的中间音频数据、重采样节点处理后的中间音频数据、混音节点处理后的中间音频数据，这三个节点的中间音频数据存在差异。由此，对不同节点的中间音频数据进行提取并检测，可以确定哪个节点导致异常。

在一种实施方式中，可以将框架层中每个节点的音频数据均复制到框架层的缓存数据中，例如可以包括图4中上述三个节点的中间音频数据。检测节点首先从框架层的缓存数据中读取目标音频数据，当检测到目标音频数据存在异常时，可以继续从框架层的缓存数据中读取中间音频数据并检测。例如，在图4中，可以按照音频数据处理的倒序，首先读取混音节点处理后的中间音频数据，如果存在与目标音频数据相同的异常，则排除音效处理节点的异常；继续读取重采样节点处理后的中间音频数据，如果存在与目标音频数据相同的异常，则排除混音节点的异常；继续读取重采样节点处理前的中间音频数据，如果存在与目标音频数据相同的异常，则排除重采样节点的异常……最终可以排查出导致目标音频数据异常的音频数据处理节点，有利于找到异常原因并解决。需要说明的是，如果排除了框架层中所有的音频数据处理节点，则通常可以确定网络连接异常导致音频异常。应当理解，实际应用中，读取并检测中间音频数据的顺序不限于上述倒序的方式，本公开对此不做限定。

本公开的示例性实施方式还提供一种音频数据处理装置。参考图9所示，该音频数据处理装置900可以包括：

框架层数据处理单元910，被配置为将待播放的原始音频数据输入框架层，通过框架层对原始音频数据进行处理，得到目标音频数据；

音频数据检测单元920，被配置为从框架层提取目标音频数据，并对所提取的目标音频数据进行检测。

在一种实施方式中，框架层数据处理单元910，被配置为：

通过框架层中的多个音频数据处理节点依次对原始音频数据进行处理。

在一种实施方式中，音频数据检测单元920，被配置为：

当检测到目标音频数据存在异常时，从各音频数据处理节点处提取对原始音频数据处理所得到的中间音频数据；

对中间音频数据进行检测，以确定导致目标音频数据异常的音频数据处理节点。

在一种实施方式中，框架层数据处理单元910，被配置为：

在得到目标音频数据后，将目标音频数据从框架层输入硬件抽象层。

音频数据检测单元920，被配置为：

从框架层复制目标音频数据。

在一种实施方式中，音频数据检测单元920，被配置为：

复制目标音频数据，并存储至框架层的缓存数据中；

从框架层的缓存数据中读取目标音频数据。

在一种实施方式中，音频数据检测单元920，被配置为：

检测目标音频数据中的数据是否为0，以确定目标音频数据中的空白数据段，空白数据段中的数据均为0；

当检测到目标音频数据中存在预设数量的空白数据段时，确定目标音频数据中存在断音。

在一种实施方式中，音频数据检测单元920，被配置为：

按照目标音频数据中的时间戳，依次检测目标音频数据中的数据是否为0；

当检测连续为0的数据且连续为0的数据达到预设时长时，确定连续为0的数据为空白数据段。

在一种实施方式中，音频数据检测单元920，被配置为：

根据原始音频数据的声源类型，确定上述预设数量，也可以确定上述预设时长。

在一种实施方式中，音频数据处理装置900还可以包括音频数据接收单元，被配置为：

通过网络连接接收由外部发送的原始音频数据。

上述装置中各部分的细节在方法部分实施方式中已经详细说明，因而不再赘述。

本公开的示例性实施方式还提供了一种计算机可读存储介质，可以实现为一种程序产品的形式，其包括程序代码，当程序产品在电子设备上运行时，程序代码用于使电子设备执行本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施方式的步骤。在一种实施方式中，该程序产品可以实现为便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在电子设备，例如个人电脑上运行。然而，本公开的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的示例性实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施方式。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施方式仅被视为示例性的，本公开的真正范围和精神由权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限定。

Claims (12)

1.一种音频数据处理方法，其特征在于，包括：

将待播放的原始音频数据输入框架层，通过所述框架层对所述原始音频数据进行处理，得到目标音频数据；

从所述框架层提取所述目标音频数据，并对所提取的目标音频数据进行检测。

2.根据权利要求1所述的方法，其特征在于，所述通过所述框架层对所述原始音频数据进行处理，包括：

通过所述框架层中的多个音频数据处理节点依次对所述原始音频数据进行处理。

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

当检测到所述目标音频数据存在异常时，从各所述音频数据处理节点处提取对所述原始音频数据处理所得到的中间音频数据；

对所述中间音频数据进行检测，以确定导致所述目标音频数据异常的音频数据处理节点。

4.根据权利要求1所述的方法，其特征在于，在通过所述框架层对所述原始音频数据进行处理，得到目标音频数据后，所述方法还包括：

将所述目标音频数据从所述框架层输入硬件抽象层；

所述从所述框架层提取所述目标音频数据，包括：

从所述框架层复制所述目标音频数据。

5.根据权利要求4所述的方法，其特征在于，所述从所述框架层复制所述目标音频数据，包括：

复制所述目标音频数据，并存储至所述框架层的缓存数据中；

从所述框架层的缓存数据中读取所述目标音频数据。

6.根据权利要求1所述的方法，其特征在于，所述对所提取的目标音频数据进行检测，包括：

检测所述目标音频数据中的数据是否为0，以确定所述目标音频数据中的空白数据段，所述空白数据段中的数据均为0；

当检测到所述目标音频数据中存在预设数量的空白数据段时，确定所述目标音频数据中存在断音。

7.根据权利要求6所述的方法，其特征在于，所述检测所述目标音频数据中的数据是否为0，以确定所述目标音频数据中的空白数据段，包括：

按照所述目标音频数据中的时间戳，依次检测所述目标音频数据中的数据是否为0；

当检测连续为0的数据且所述连续为0的数据达到预设时长时，确定所述连续为0的数据为空白数据段。

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

根据所述原始音频数据的声源类型，确定所述预设数量。

9.根据权利要求1至8任一项所述的方法，其特征在于，所述方法还包括：

通过网络连接接收由外部发送的所述原始音频数据。

10.一种音频数据处理装置，其特征在于，包括：

框架层数据处理单元，被配置为将待播放的原始音频数据输入框架层，通过所述框架层对所述原始音频数据进行处理，得到目标音频数据；

目标音频数据检测单元，被配置为从所述框架层提取所述目标音频数据，并对所提取的目标音频数据进行检测。

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

12.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1至9任一项所述的方法。

Images