CN107992282B - 音频数据处理方法及装置、计算机装置及可读存储装置 - Google Patents

Abstract

本发明实施例公开了一种音频数据处理方法及装置、计算机装置及可读存储装置，用于解决现有技术耳返的延时较长的问题。本发明实施例方法包括：终端的框架层从音频内核层获取录音数据；框架层将录音数据存储在缓存区；框架层对缓存区内的录音数据进行音效处理，得到处理后数据；框架层将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放。

Description

音频数据处理方法及装置、计算机装置及可读存储装置

技术领域

本发明涉及移动终端的数据处理领域，具体涉及一种音频数据处理方法及装置、计算机装置及可读存储装置。

背景技术

对于在较大的场地或在佩戴耳机的情况下讲话或唱歌的情形，为了方便用户监听自己的声音，终端一般会设置耳返功能。比如用户在使用K歌应用进行K歌时，用户除了可以听到K歌应用中的背景音乐，还可以听到自己通过麦克录入的声音。

目前市面上的K歌应用一般都是在应用层实现的软件耳返，安卓系统上的音频框架通常包括用户层(User)和音频内核层，音频内核层包括音频内核驱动和音频硬件设备，用户层一般包括几个层次结构，包括应用层(APP)、框架层(Framework)以及硬件抽象层(HAL层)，音频内核层获取到录音数据之后，录音数据依次经过硬件抽象层以及框架层进入到应用层，应用层再执行耳返功能，将获取到的录音数据依次通过框架层、硬件抽象层发送到音频内核层进行播放。

由于在应用层实现耳返的过程中声音的输入-输出回路过长，导致耳返的延时较长，耳返的延时是指声音从麦克风输入的时刻到从扬声器或耳机里输出的时刻之间的时长，同步效果差，影响用户体验。

发明内容

本发明实施例提供了一种音频数据处理方法及装置、计算机装置及可读存储装置，用于解决现有技术耳返的延时较长的问题。

本发明实施例一方面提供一种音频数据处理方法，包括：

终端的框架层从音频内核层获取录音数据；

所述框架层将所述录音数据存储在缓存区；

所述框架层对所述缓存区内的所述录音数据进行音效处理，得到处理后数据；

所述框架层将所述处理后数据混到播放数据中，以使得播放组件对所述播放数据进行播放。

结合第一方面，在第一方面的第一种可能的实现方式中，所述框架层将所述录音数据存储在缓存区之后，在所述框架层对所述缓存区内的所述录音数据进行音效处理之前，所述方法还包括：

判断所述缓存区内的所述录音数据的帧数是否超过阈值；

若超过，则触发对所述缓存区内的所述录音数据进行音效处理的操作。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，在终端的框架层从音频内核层获取录音数据之前，所述方法还包括：

所述框架层接收应用发送的录音获取请求；

所述框架层判断所述录音获取请求是否为耳返数据的获取请求；

若是，在终端的框架层从音频内核层获取录音数据之后，所述框架层触发将所述录音数据存储在缓存区的操作。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述框架层判断所述录音获取请求是否为耳返数据的获取请求包括：

所述框架层判断所述应用是否为目标应用，所述目标应用为预先记录的将录音数据作为耳返数据的应用；

若是，所述框架层判定所述录音获取请求为耳返数据的获取请求。

结合第一方面的第二种可能的实现方式，在第一方面的第四种可能的实现方式中，所述框架层判断所述录音获取请求是否为耳返数据的获取请求包括：

所述框架层判断当前是否获取到所述应用发送的媒体流；

若是，则所述框架层判定所述录音获取请求为耳返数据的获取请求。

结合第一方面的第一种可能的实现发送、第一方面的第二种可能的实现方式、第一方面的第三种可能的实现方式和第一方面的第四种可能的实现方式中任意一种可能的实现方式，在第一方面的第五种可能的实现方式中，所述方法还包括：

当所述框架层判定当前获取到所述应用发送的媒体流时，减小所述阈值。

本发明实施例第二方面提供一种音频数据处理装置，部署于终端音频系统的架构层，包括：

获取模块，用于从音频内核层获取录音数据；

存储模块，用于将所述录音数据存储在缓存区；

音效处理模块，用于对所述缓存区内的所述录音数据进行音效处理，得到处理后数据；

混音模块，用于将所述处理后数据混到播放数据中，以使得播放组件对所述播放数据进行播放。

结合第一方面，在第一方面的第一种可能的实现方式中，所述音频数据处理装置还包括：

第一判断模块，用于在所述存储模块将所述录音数据存储在缓存区之后，在所述音效处理模块对所述缓存区内的所述录音数据进行音效处理之前，判断所述缓存区内的所述录音数据的帧数是否超过阈值；

第一触发模块，用于当所述第一判断模块判定所述录音数据的帧数超过阈值时，触发对所述缓存区内的所述录音数据进行音效处理的操作。

结合第一方面或第一方面的第一种可能的实现方式，在第一方面的第二种可能的实现方式中，所述音频数据处理装置还包括：

接收模块，用于在所述获取模块从音频内核层获取录音数据之前，接收应用发送的录音获取请求；

第二判断模块，用于判断所述录音获取请求是否为耳返数据的获取请求；

第二触发模块，用于当所述第二判断模块判定所述录音获取请求是耳返数据的获取请求时，在所述获取模块从音频内核层获取录音数据之后，触发将所述录音数据存储在缓存区的操作。

结合第一方面的第二种可能的实现方式，在第一方面的第三种可能的实现方式中，所述第二判断模块包括：

第一判断单元，用于判断所述应用是否为目标应用，所述目标应用为预先记录的将录音数据作为耳返数据的应用；

第一判定单元，用于当所述第一判断单元判定所述应用是目标应用时，判定所述录音获取请求为耳返数据的获取请求。

结合第一方面的第二种可能的实现方式，在第一方面的第四种可能的实现方式中，所述第二判断模块包括：

第二判断单元，用于判断当前是否获取到所述应用发送的媒体流；

第二判定单元，用于当所述第二判断单元判定当前获取到所述应用发送的媒体流时，判定所述录音获取请求为耳返数据的获取请求。

结合第一方面的第一种可能的实现发送、第一方面的第二种可能的实现方式、第一方面的第三种可能的实现方式和第一方面的第四种可能的实现方式中任意一种可能的实现方式，在第一方面的第五种可能的实现方式中，所述音频数据处理装置还包括：

减小模块，用于若获取到所述应用发送的媒体流，则减小所述阈值。

本发明实施例的第三方面提供了一种计算机装置，所述计算机装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如第一方面或第一方面的任意一种可能的实现方式所述方法的步骤。

本发明实施例的第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面或第一方面的任意一种可能的实现方式所述方法的步骤。

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

本发明实施例中终端的框架层可以从音频内核层获取录音数据，并将录音数据存储在缓存区，对缓存区内的录音数据进行音效处理，得到处理后数据，之后可以将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放，由于在框架层实现耳返的过程中声音的输入-输出回路较短，导致耳返的延时较短，同步效果好，提高用户体验。

附图说明

图1是本发明音频数据处理方法一个实施例示意图；

图2是本发明音频数据处理方法另一个实施例示意图；

图3是本发明音频数据处理装置一个实施例示意图；

图4是本发明音频数据处理装置另一个实施例示意图；

图5是本发明计算机装置一个实施例示意图。

具体实施方式

本发明实施例提供了一种音频数据处理方法及装置、计算机装置及可读存储装置，用于在框架层实现耳返，缩短耳返的延时，优化同步效果。

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

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

安卓系统上的音频框架通常包括用户层和音频内核层，音频内核层包括音频内核驱动和音频硬件设备，用户层一般包括几个层次结构，包括应用层(APP)、框架层(Framework)以及硬件抽象层(HAL层)。

应用层为客户端，可例如Audio APP(应用程序)等，具体可以为安卓系统中的JAVA应用单元。框架层一般包括应用服务单元、音频录播单元和本地服务单元；音频录播单元包括音频录音单元和音频播放单元，二者属于音频系统对外提供的API(应用程序变成接口)类，应用层通过调用这两个API接口可以完成音频系统中音频数据的录制和播放任务；本地服务单元包括音频系统单元(AudioSystem)、本地音频服务单元(AudioFlinger)、音频策略服务器(AudioService)和音频策略管理器(AudioPolicyManager)，其中，本地音频服务单元为本地服务的音频中枢，起到承上启下的作用，具体的，用于为上层提供访问接口，通过下层的硬件抽象层来管理音频设备。硬件抽象层主要包括Audio HAL，Audio HAL是本地音频服务单元的直接访问对象，用来连接本地服务单元与音频内核层。音频硬件设备一般包括麦克风、喇叭、听筒等音频设备，音频内核驱动用于控制上述音频硬件设备实现打开和关闭等功能。

请参阅图1，本发明实施例中音频数据处理方法一个实施例包括：

101、终端的框架层从音频内核层获取录音数据；

音频内核层获取到录音数据之后，比如通过麦克风获取到录音数据之后，终端的框架层可以从音频内核层获取该录音数据。

102、框架层将录音数据存储在缓存区；

框架层获取到录音数据之后，可以将录音数据存储在缓存区。

103、框架层对缓存区内的录音数据进行音效处理，得到处理后数据；

框架层可以对缓存区内存储的录音数据进行音效处理，得到处理后数据。对录音数据进行音效处理可以包括：对录音数据进行消噪、动态压缩、均衡和混响处理等操作。

104、框架层将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放。

框架层得到处理后数据之后，可以将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放，具体的，框架层将播放数据通过硬件抽象层发送到音频内核层进行播放。

下面提供一种利用本地音频服务单元AudioFlinger实现耳返功能的具体方法：

实现一个包含OutputTrack对象的回环LoopbackThread播放线程，该线程作为上行录音线程RecordThread的内部成员，维护一个缓冲区Ringbuffer，对输入、输出进行同步以实现上行数据转为下行的功能。在上行录音线程RecordThread取数据时，将取得的录音数据写入LoopbackThread的Ringbuffer,LoopbackThread的ThreadLoop将Ringbuffer中的录音数据通过OutputTrack直接写入PlaybackThread播放线程，以实现将上行转下行并直接输出的功能。

本发明实施例中终端的框架层可以从音频内核层获取录音数据，并将录音数据存储在缓存区，对缓存区内的录音数据进行音效处理，得到处理后数据，之后可以将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放，和现有技术的应用层耳返相比，由于录入数据进入到框架层之后，便直接下行到音频硬件设备输出，减少了录音数据上行到应用层以及从应用层下行到框架层的时间，在框架层实现耳返的过程中声音的输入-输出回路较短，从而较大的减小了耳返延迟，同步效果好，提高用户体验。

作为系统平台级软件耳返，可以在安卓平台上通用，并可供所有需要具备耳返功能的应用使用。而且由于框架层在音频框架中处于应用层和音频内核层之间，处于承上启下的位置，能够更高效的处理应用层与音频内核层的数据与指令。

终端可以设置耳返选项，当用户选择开启耳返功能时(比如佩戴降噪耳机时，难以听清自己的声音)，框架层可以按照图1对应的实施例对获取到的所有录音数据进行耳返。但是，耳返功能需要用户手动开启，用户使用不便，因此需要自动判断需要开启耳返功能的场景，自动开启耳返功能。为了解决上述问题，请参阅图2，本发明实施例中音频数据处理方法另一个实施例包括：

201、框架层接收应用发送的录音获取请求；

应用层的应用需要获取录音数据时，可以向框架层发送录音获取请求。

202、框架层从音频内核层获取录音数据；

音频内核层获取到录音数据之后，比如通过麦克风获取到录音数据之后，终端的框架层可以从音频内核层获取该录音数据。

203、框架层判断录音获取请求是否为耳返数据的获取请求，若是，则执行步骤204，若否，则执行步骤209；

在框架层接收到应用发送的录音获取请求时，可以判断该录音获取请求是否为耳返数据的获取请求，若是，则执行步骤204，若否，则执行步骤209。耳返数据是指用于实现耳返功能的录音数据。

下面提供两种判断录音获取请求是否为耳返数据的获取请求的方法：

第一种方法包括：

A1、框架层判断应用是否为目标应用，若是，则执行步骤A2，若否，则执行步骤A3；

框架层可以预存将录音数据作为耳返数据的应用，比如唱吧APP，在本发明实施例中，将预存的这类应用称作目标应用。框架层可以判断录音获取请求的发送方是否为目标应用，若是，则执行步骤A2，若否，则执行步骤A3。

A2、框架层判定录音获取请求为耳返数据的获取请求；

若判定应用为目标应用，则框架层判定录音获取请求为耳返数据的获取请求。

A3、框架层判定录音获取请求不是耳返数据的获取请求。

若判定应用不是目标应用，则框架层判定录音获取请求不是耳返数据的获取请求。

第二种方法包括：

B1、框架层判断当前是否获取到应用发送的媒体流，若是，则执行步骤B2，若否，则执行步骤B3；

在框架层接收到应用发送的录音获取请求之后，可以判断当前是否获取到该应用发送的媒体流数据，若获取到该应用发送的媒体流数据，则执行步骤B2，若未获取到该应用发送的媒体流数据，则执行步骤B3。

B2、框架层判定录音获取请求为耳返数据的获取请求；

若框架层获取到该应用发送的媒体流数据，则可以判定录音获取请求为耳返数据的获取请求，因为当应用播放媒体流数据时，若同时获取录音数据，通常希望将录音数据与媒体流数据进行混音播放。

B3、框架层判定录音获取请求不是耳返数据的获取请求。

若框架层未获取到该应用发送的媒体流数据，则可以判定录音获取请求不是耳返数据的获取请求。

204、框架层将录音数据存储在缓存区；

若框架层判定该录音获取请求是耳返数据的获取请求，框架层可以将获取到的录音数据存储在缓存区。

205、当前获取到应用发送的媒体流时，框架层减小阈值；

框架层预设有缓存区内存储的录音数据的帧数的阈值，在一般情况下，该阈值取标准值，当框架层判定当前获取到应用发送的媒体流时，可以减小阈值，使得阈值的取值低于该标准值。

对于确定的采样率(即一秒内音频采帧数)，比如48KHz，若缓存区内存储的录音数据的帧数的阈值的标准值为960帧时，表示框架层在一个处理周期处理的音频数据的帧数为960帧，那么框架层一个处理周期所需的时间为960/48000＝0.02s，若减小阈值的取值，则框架层一个处理周期所需的时间会减小，有利于提高耳返的实时性。但是，如果阈值一直设为较小的值，框架层在单位时间内会经历更多的处理周期，处理频率高，增加系统负担。由于应用发送媒体流时若需要获取录音数据，通常该应用通常处于KTV模式，对耳返的实时性要求更高，因此优选的，可以在这种情况下减小阈值。在实际使用中，也可以不执行步骤205，而直接执行步骤206。

206、框架层判断缓存区内的录音数据的帧数是否超过阈值，若是，则执行步骤207，若否，则执行步骤209；

框架层将获取到的录音数据存储在缓存区之后，可以判断缓存区内的录音数据的帧数是否超过阈值，若超过，则执行步骤207，若未超过，则执行步骤209。

207、框架层对缓存区内的录音数据进行音效处理，得到处理后数据；

当缓存区内的录音数据的帧数超过阈值时，框架层可以对缓存区内存储的录音数据进行音效处理，得到处理后数据。对录音数据进行音效处理可以包括：对录音数据进行消噪、动态压缩、均衡和混响处理等操作。

208、框架层将处理后数据混到播放数据中；

对缓存区内的录音数据进行音效处理得到处理后数据之后，框架层可以将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放，具体的，框架层将播放数据通过硬件抽象层发送到音频内核层进行播放。

209、执行其他操作。

由于框架层在音频框架中处于应用层和音频内核层之间，处于承上启下的位置，因此方便获取应用层的数据与指令。

上面对本发明实施例中的音频数据处理方法进行了描述，下面对本发明实施例中的音频数据处理装置进行描述。

请参阅图3，本发明实施例中音频数据处理装置3的一个实施例包括：

音频数据处理装置，部署于终端音频系统的架构层，包括：

获取模块301，用于从音频内核层获取录音数据；

存储模块302，用于将录音数据存储在缓存区；

音效处理模块303，用于对缓存区内的录音数据进行音效处理，得到处理后数据；

混音模块304，用于将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放。

优选的，请参阅图4，本发明实施例中音频数据处理装置4的另一个实施例包括：

音频数据处理装置，部署于终端音频系统的架构层，包括：

获取模块401，用于从音频内核层获取录音数据；

存储模块402，用于将录音数据存储在缓存区；

第一判断模块403，用于在存储模块将录音数据存储在缓存区之后，在音效处理模块对缓存区内的录音数据进行音效处理之前，判断缓存区内的录音数据的帧数是否超过阈值；

音效处理模块404，用于当第一判断模块判定录音数据的帧数超过阈值时，对缓存区内的录音数据进行音效处理，得到处理后数据；

混音模块405，用于将处理后数据混到播放数据中，以使得播放组件对播放数据进行播放。

可选的，音频数据处理装置4还包括：

接收模块406，用于在获取模块从音频内核层获取录音数据之前，接收应用发送的录音获取请求；

第二判断模块407，用于判断录音获取请求是否为耳返数据的获取请求，当第二判断模块判定录音获取请求是耳返数据的获取请求时，在获取模块从音频内核层获取录音数据之后，触发将录音数据存储在缓存区的操作。

可选的，第二判断模块407包括：

第一判断单元(图中未示出)，用于判断应用是否为目标应用，目标应用为预先记录的将录音数据作为耳返数据的应用；

第一判定单元(图中未示出)，用于当第一判断单元判定应用是目标应用时，判定录音获取请求为耳返数据的获取请求。

可选的，第二判断模块407包括：

第二判断单元(图中未示出)，用于判断当前是否获取到应用发送的媒体流；

第二判定单元(图中未示出)，用于当第二判断单元判定当前获取到应用发送的媒体流时，判定录音获取请求为耳返数据的获取请求。

可选的，音频数据处理装置4还包括：

减小模块408，用于若获取到应用发送的媒体流，则减小阈值。

上面从模块化功能实体的角度对本发明实施例中的音频数据处理装置进行了描述，下面从硬件处理的角度对本发明实施例中的计算机装置进行描述：

本发明实施例还提供了一种计算机装置5，如图5所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该计算机装置5一般指服务器等处理能力较强的计算机设备。

参考图5，计算机装置5包括：电源510、存储器520、处理器530、有线或无线网络接口540以及存储在存储器中并可在处理器上运行的计算机程序。处理器执行计算机程序时实现上述各个音频数据处理方法实施例中的步骤，例如图1所示的步骤101至104。或者，处理器执行计算机程序时实现上述各装置实施例中各模块或单元的功能。

示例性的，计算机程序可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器中，并由所述处理器执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序在所述计算机装置中的执行过程。

本领域技术人员可以理解，图5中示出的结构并不构成对计算机装置5的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，例如所述计算机装置还可以包括输入输出设备、总线等。

所称处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等，所述处理器是所述计算机装置的控制中心，利用各种接口和线路连接整个计算机装置的各个部分。

所述存储器可用于存储所述计算机程序和/或模块，所述处理器通过运行或执行存储在所述存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现所述计算机装置的各种功能。所述存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述计算机装置集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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

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

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

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

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

Claims (5)

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

终端的框架层从音频内核层获取录音数据；

所述框架层将所述录音数据存储在缓存区；

判断所述缓存区内的所述录音数据的帧数是否超过阈值；

若超过，则所述框架层对所述缓存区内的所述录音数据进行音效处理，得到处理后数据；

所述框架层将所述处理后数据混到播放数据中，以使得播放组件对所述播放数据进行播放；

在终端的框架层从音频内核层获取录音数据之前，所述方法还包括：

所述框架层接收应用发送的录音获取请求；

所述框架层判断所述录音获取请求是否为耳返数据的获取请求；

若是，在终端的框架层从音频内核层获取录音数据之后，所述框架层触发将所述录音数据存储在缓存区的操作；

所述框架层判断所述录音获取请求是否为耳返数据的获取请求包括：

所述框架层判断当前是否获取到所述应用发送的媒体流；

若是，则所述框架层判定所述录音获取请求为耳返数据的获取请求；

若所述框架层获取到所述应用发送的媒体流，则减小所述阈值。

2.根据权利要求1所述的音频数据处理方法，其特征在于，所述框架层判断所述录音获取请求是否为耳返数据的获取请求包括：

所述框架层判断所述应用是否为目标应用，所述目标应用为预先记录的将录音数据作为耳返数据的应用；

若是，所述框架层判定所述录音获取请求为耳返数据的获取请求。

3.一种音频数据处理装置，部署于终端音频系统的架构层，其特征在于，包括：

获取模块，用于从音频内核层获取录音数据；

存储模块，用于将所述录音数据存储在缓存区；

第一判断模块，用于在所述存储模块将所述录音数据存储在缓存区之后，在音效处理模块对所述缓存区内的所述录音数据进行音效处理之前，判断所述缓存区内的所述录音数据的帧数是否超过阈值；

第一触发模块，用于当所述第一判断模块判定所述录音数据的帧数超过阈值时，触发对所述缓存区内的所述录音数据进行音效处理的操作；

音效处理模块，用于对所述缓存区内的所述录音数据进行音效处理，得到处理后数据；

混音模块，用于将所述处理后数据混到播放数据中，以使得播放组件对所述播放数据进行播放；

接收模块，用于在所述获取模块从音频内核层获取录音数据之前，接收应用发送的录音获取请求；

第二判断模块，用于判断所述录音获取请求是否为耳返数据的获取请求；

第二触发模块，用于当所述第二判断模块判定所述录音获取请求是耳返数据的获取请求时，在所述获取模块从音频内核层获取录音数据之后，触发将所述录音数据存储在缓存区的操作；

所述第二判断模块包括：

第二判断单元，用于判断当前是否获取到所述应用发送的媒体流；

第二判定单元，用于当所述第二判断单元判定当前获取到所述应用发送的媒体流时，判定所述录音获取请求为耳返数据的获取请求；

减小模块，用于若获取到所述应用发送的媒体流，则减小所述阈值。

4.一种计算机装置，其特征在于，所述计算机装置包括处理器，所述处理器用于执行存储器中存储的计算机程序时实现如权利要求1-2中任意一项所述方法的步骤。

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

Images