CN106911831B

CN106911831B - 一种终端的麦克风的数据处理方法和具有麦克风的终端

Info

Publication number: CN106911831B
Application number: CN201710072226.6A
Authority: CN
Inventors: 耿炳钰; 安亮; 郑伟波
Original assignee: Hisense Mobile Communications Technology Co Ltd
Current assignee: Hisense Mobile Communications Technology Co Ltd
Priority date: 2017-02-09
Filing date: 2017-02-09
Publication date: 2019-09-20
Anticipated expiration: 2037-02-09
Also published as: US20180225080A1; US10387103B2; CN106911831A

Abstract

本发明实施例公开了一种终端的麦克风的数据处理方法和具有麦克风的终端，涉及移动终端技术领域，用以解决现有技术中当有应用正在调用麦克风时，其他应用无法开启录音功能的问题。所述终端包含与麦克风通信的数据发送端口以及与所述数据发送端口具有一对多映射关系的数据接收端口，所述方法包括：在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给第二应用。

Description

一种终端的麦克风的数据处理方法和具有麦克风的终端

技术领域

本发明涉及移动终端技术领域，尤其涉及一种终端的麦克风的数据处理方法和具有麦克风的终端。

背景技术

在移动互联网时代，随着智能终端的推广和普及，终端的录音功能愈来愈智能化。例如在Android系统中，录音机，语音识别，语音搜索，视频通话等应用都会用到麦克风的录音功能。

参考图1所示，现有技术中应用获取录音的过程主要包括以下几个模块：应用(Application)、操作系统的录音模块、硬件抽象层(HAL)、录音硬件部分(Hardware)(包括麦克风和DSP等，为了便于描述以下都用麦克风代替录音硬件部分进行简单说明)。其中，应用包括录音机、语音输入、语音搜索等需要录制声音的应用，应用开启录音功能；操作系统的录音模块属于Android操作系统，包括Framework应用框架，用于传递录音开启命令和录音数据；HAL是位于操作系统内核(Linux内核驱动)与上层录音模块之间的接口层，其目的在于将硬件抽象化；麦克风用于根据录音开启命令采集录音数据。具体的操作系统包括：Java接口、JNI接口(C++与Java之间的接口)、AudioRecord.cpp(Android录音代码)、C++录音框架(AudioRecordThread)等。

现有技术应用获取录音的方式有两种，一种是通过Java接口的MediaRecorder(Android框架中的类)方式获取到编码过的数据(如录音机，录像等应用)，另一种是通过Java接口的AudioRecord(Android框架中的类)获取原始的数据(如语音识别，语音指令，语音搜索，视频通话，语音输入法等应用)。两种方式的差别在上述的录音过程的Java接口->JNI(C++与Java之间的接口)->录音框架部分。

方式一是MediaRecorder方式，具体为：应用->MediaRecorder(java)->MediaRecorder(JNI)->编码部分(StagefrightRecorder)->AudioRecord.cpp->AudioRecordThread->HAL->麦克风。

方式二是AudioRecord方式，具体为：应用->AudioRecord(java)->AudioRecord(JNI)->AudioRecord.cpp->AudioRecordThread->HAL->麦克风。

应用程序各式各样，每个应用可能会有不同的需求，因而会设置不同的录音参数等。相应的录音参数会通过上述过程传递给麦克风，当麦克风收到录音开启指令之后，会按照应用下达的录音参数开启，然后将采集到的录音数据按照与上述顺序相反的顺序从麦克风传输至应用。当麦克风正以一应用设置的固定录音参数运行采集录音数据的过程中，如果有第二个应用要开启录音功能，这时为防止参数冲突，会阻止第二个应用开启录音功能，操作系统将会报错，第二个应用无法开启录音功能，以至于无法获取麦克风的录音数据。

发明内容

本发明的实施例提供一种终端的麦克风的数据处理方法和具有麦克风的终端，用以解决现有技术中当有应用正在调用麦克风时，其他应用无法开启录音功能的问题。

为达到上述目的，本发明的实施例采用如下技术方案：

第一方面、本发明实施例提供了一种终端的麦克风的数据处理方法，所述终端包含与麦克风通信的数据发送端口以及与所述数据发送端口具有一对多映射关系的数据接收端口，所述方法包括：

在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给第二应用。

第二方面、本发明实施例提供了一种具有麦克风的终端，所述终端包括：

录音模块，所述录音模块与麦克风连接，包括与麦克风通信的数据发送端口以及与所述数据发送端口具有一对多映射关系的数据接收端口；

所述录音模块，用于在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给第二应用。

本发明实施例提供了一种终端的麦克风的数据处理方法和具有麦克风的终端，通过在操作系统的录音模块中增加一个数据发送端口和N个数据接收端口，使得当在麦克风被第一应用调用时，终端接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给第二应用。也就是当第一应用正在调用麦克风，使用录音功能获取录音数据时，第二应用开启了录音功能，终端通过为第二应用分配一个数据接收端口，然后通过数据发送端口数据接收端口等获得录音数据发回给第二应用。这样通过类似于网络服务的方式来实现数据重用，从而解决了现有技术中当有应用正在调用麦克风时，其他应用无法开启录音功能的问题。

附图说明

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

图1为现有技术提供的一种应用开启录音功能并获取录音数据的框架图；

图2为本发明实施例提供的一种应用开启录音功能并获取录音数据的框架图；

图3为本发明实施例提供的一种终端的麦克风的数据处理方法的流程图；

图4为本发明实施例提供的一种具有麦克风的终端的框图。

具体实施方式

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

本发明实施例中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本发明实施例中字符“/”，一般表示前后关联对象是一种“或”的关系。

为了便于清楚描述本发明实施例的技术方案，在本发明的实施例中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本发明的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本发明实施例中“多个应用同时开启录音功能”的含义可以是多个应用同一时间开启录音功能，也可以是在至少一个应用开启录音功能且未关闭录音功能之前，又有其他应用开启了录音功能。应用调用麦克风就是指应用开启录音功能。

本发明实施例的工作原理在于修改JNI接口至HAL层之间的代码，即现有技术中录音模块中Android录音代码及C++录音框架这两部分。且在不修改应用软件、Java接口、JNI接口(接口部分为了保证现有以及将来新出现软件的兼容问题，也不做任何修改)、硬件抽象层、录音硬件部分的前提下，仅修改Android录音代码及C++录音框架，将原来的单一线程转换为多个线程，支持多个应用可以同时获取录音数据，从而实现多个应用可以同时开启录音功能。也就是说，本发明实施例在不修改应用软件和硬件部分的前提下，仅通过软件部分的修改，实现终端中的多个应用可以同时开启录音功能。

本发明实施例获取录音数据的过程的主要变化在Android录音代码及C++录音框架这两部分，且对这两部分的修改有两种方案。其中方案一是在保留现有技术中录音开启指令的下发以及录音数据上传过程的基础上，通过增加数据发送端口(protocol port)和N个数据接收端口的方式增加了一种录音数据上传的方法；方案二是保留现有技术中录音开启指令的下发过程，将原有录音数据上传的方法改成通过数据发送端口和数据接收端口的录音数据上传的方法。具体的参考图2所示(需要说明的是：其中实线表示现有技术的录音开启指令的下发以及录音数据上传过程，虚线表示本发明实施例增加的录音数据上传过程。图中以三个应用同时开启录音功能为例。)，通过类似于网络服务的方式来实现数据重用，在Android录音代码及C++录音框架之间增加一个数据发送端口和N个数据接收端口，N大于等于2。

给需要获取录音数据的应用分配一个未被占用的数据接收端口。数据发送端口从C++录音框架获取录音数据，然后通过广播的方式发送至N个数据接收端口。已被应用占用的数据协议端口收到录音数据之后，将数据返回对应的应用。

实施例一

本发明实施例提供了一种终端的麦克风的数据处理方法，该方法的执行主体可以是终端，也可以是终端中的软件或硬件，示例的，可以是终端中的录音模块。终端包含与麦克风通信的数据发送端口以及与所述数据发送端口具有一对多映射关系的数据接收端口。数据发送端口和数据接收端口之间可以是根据某种协议进行通信。优选的，数据发送端口和数据接收端口之间根据用户数据报协议(User Datagram Protocol，简称UDP)，因为UDP协议相对比较简单且满足本发明实施例的需要；可选的，数据发送端口和数据接收端口之间也可以是根据传输控制协议(Transmission Control Protocol，简称TCP)等其他协议进行通信，这里不做限定。参考图3所示，该方法包括以下步骤：

S101、在麦克风被第一应用调用时，接收第二应用发出的录音开启指令。

需要说明的是：本发明实施例中要保护的是在第一应用可以获得录音数据的前提下，第二应用发出录音开启指令，并获得录音数据的情况。第一应用指的是在第二应用发出录音开启指令之前，任意一个正在调用麦克风的应用，也就是任意一个已经开启录音功能并正在使用录音功能的应用。若该第一应用是第一个开启录音功能的应用，则该第一应用可以完全按照现有技术的方法实现录音开启指令的下发以及录音数据的上传；也可以按照现有技术中的方法实现录音开启指令的下发，但实现录音数据的上传按照本发明实施例提供的通过数据发送端口和数据接收端口上传录音数据的方法。

当一应用开启录音功能时，会向终端发出录音开启指令，该录音开启指令包括应用所需的录音参数、开启麦克风指令和返回录音数据。其中，录音参数包括下述的一种或多种：采样率，声道数，和录音格式。优选的，录音参数包括采样率，声道数，和录音格式等其他设定录音效果的参数，这样可以得到应用所需的最优的录音数据。

终端获取该录音开启指令，并将该录音开启指令发送给麦克风。具体的通过依次调用Java接口、JNI接口、Android录音代码、C++录音框架获取应用的录音开启命令，并将该命令传递给硬件抽象层，通过硬件抽象层来开启麦克风。

第一个开启录音功能的应用，终端会根据该应用的录音开启指令中的开启麦克风指令开启麦克风。在开启麦克风时，可以按照录音开启指令中的录音参数为麦克风配置录音参数，也可以是按照预设的录音参数为麦克风配置录音参数。其中预设的录音参数可以是手机设备出厂时设置好的，也可以是某次使用前重新设置的，但在麦克风使用过程通常不修改该录音参数。

需要说明的是，在现有技术中，麦克风是按照其出厂时设置的固定的录音参数采集录音数据的，然后通过DSP等其他硬件部分对采集到的录音数据进行转换处理，以获得应用所需的录音数据，再通过硬件抽象层将应用所需的录音数据返回给C++录音框架，最后在一步步返回给应用。在本发明实施例中的麦克风是代表录音硬件部分(包括DSP、麦克风等)，而不仅仅是指实际上的麦克风，因此麦克风的录音参数是可以设置的。

从第二个开启录音功能的应用开始以后的开启录音功能的应用，也就是说当麦克风正在录音时，开启录音功能的应用，终端在将该应用的录音开启指令下发后，通过C++录音框架及Android录音代码会收到指示录音开启失败的消息，表明已经有其他应用开启了麦克风功能，此时麦克风处于开启状态。执行步骤S102-S104。

示例的，指示录音开启失败消息可以是录音开启指令的返回值，若返回失败，说明麦克风被占用，处于开启状态。当然若录音开启失败，也可以返回其他设定值，例如No、不可以、0等值，指示麦克风被占用，处于开启状态。录音开启指令的返回值为成功、Yes、可以、1等值，这指示麦克风未被占用，处于关闭状态，当然也可以不返回任何值，直接返回录音数据。

S102、从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口。

终端通过AudioRecord.cpp从未被占用的数据接收端口中为第二应用分配一个数据接收端口，分配的时候可以是依次分配的，例如给N个数据接收端口编号，依次分配这N个数据接收端口；也可以是任意分配的，例如为一应用分配了一个端口，但该端口已经被占用，则为该应用分配下一个端口，直到为该应用分配到未被占用的端口为止。

第一应用分配有另外一个对应的数据接收端口。若第一应用为第一个开启录音功能的应用，则第一应用可能分配有另外一个对应的数据接收端口，也可能未分配有另外一个对应的数据接收端口；若第一应用不是第一个开启录音功能的应用，那么第一应用分配有另外一个对应的数据接收端口。

S103、通过数据发送端口获取由麦克风采集到的录音数据，并广播所采集的录音数据。

在本发明实施例中，当麦克风采集完一定量的录音数据后，通过硬件抽象层返回给C++录音框架。若第一个开启录音功能的应用按照现有技术的方法获得录音数据，则C++录音框架将录音数据复制，一份发直接返回给Android录音代码，Android录音代码将录音数据返回给第一个开启录音功能的应用；一份发送给数据发送端口，然后数据发送端口广播该录音数据。若第一个开启录音功能的应用按照本发明的方法获得录音数据，那么C++录音框架直接将录音数据发送给数据发送端口，然后数据发送端口广播该录音数据。

终端通过数据发送端口获取由麦克风采集到的录音数据的过程：可选的，数据发送端口向C++录音框架发出获取录音数据的指令，C++录音框架将录音数据复制发送给数据发送端口。可选的，当C++录音框架获取了麦克风采集到的录音数据后，主动将录音数据发送给数据发送端口。具体的，在终端的C++录音框架中增加将录音数据复制再分别发送的程序代码，或者在终端的C++录音框架中将原有的将录音数据发送给Android录音代码的程序代码改成将录音数据发送给数据发送端口的程序代码。

数据发送端口收到数据之后，通过广播的方式将数据发送给了N个数据接收端口。此时C++录音框架可能同时将数据发送给了Android录音代码，从而返回给第一个开启录音功能的应用，若第一个开启录音功能的应用关闭录音功能，则C++录音框架不需要再将录音数据同时发送给Android录音代码。

S104、通过为第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给第二应用。

终端通过为第二应用分配的数据接收端口接收广播的录音数据，并通过Android录音代码、JNI接口和Java接口等将所接收的录音数据返回给第二应用。需要说明的是：在本发明实施例中，以终端将广播的录音数据返回给第二应用的过程为例来说明通过数据发送端口、数据接收端口、Android录音代码、JNI接口和Java接口等获得录音数据的过程。

在整个录音过程中，麦克风始终以一个固定的录音参数来采集录音数据。这个固定的录音参数可以是第一个开启录音功能的应用所需的录音参数，即其他应用所需的录音参数不会作用到麦克风上；优选的是系统预设的录音参数，即所有应用所需的录音参数都不会作用到麦克风上。并且返回给应用的录音数据的内容一定是应用需要的，但录音效果不一定是应用需要的，即返回给应用的录音数据可能不符合应用所需的录音参数。因此可选的，可以直接将由麦克风集到的录音数据返回给应用，返回的录音数据的效果不一定是应用需要的，优选的可以是将应用所需的录音数据返回给应用。

在将所接收的录音数据返回给第二应用之前，将由所述麦克风采集到的录音数据按照所述第二应用所需的录音参数进行转换处理。这里的转换方法可以使用现有技术中的任一种，只要能将所接收的录音数据转换成第二应用所需的即可，示例的，可以是将所接收的录音数据按照第二应用所需的录音参数进行重采样，以获得第二应用所需的录音数据。

重采样的过程可以是在数据接收端口进行的，则数据接收端口收到录音数据之后，将录音数据重采样；重采样的过程也可以是在Android录音代码中进行的，则数据接收端口收到录音数据之后，将录音数据返回给Android录音代码，Android录音代码将录音数据重采样，或者C++录音框架获取录音数据之后，将录音数据返回给Android录音代码，Android录音代码将录音数据重采样。当然重采样的过程也可以是在JNI接口或Java接口中进行，在此不再赘述。

若由麦克风采集到的录音数据为麦克风按照第一个开启录音功能的应用所需的录音参数采集到的录音数据，则该录音数据即为应用所需的数据，终端可以直接将该数据返回给应用。

当应用关闭录音功能之后，释放终端为应用分配的数据接收端口。

终端为应用分配的数据接收端口，即为应用占用的数据接收端口。

可选的，当占用数据接收端口的应用关闭录音功能时，不释放其占用的数据接收端口。

优选的，当占用数据接收端口的应用关闭录音功能时，释放其占用的数据接收端口，释放的数据接收端口可以供其他应用再次使用。这样可以节约被占用的空间及占用端口数量，可以复用端口，节约整个程序的执行时间，例如当应用关闭了录音功能，但数据接收端口还在给应用返回数据，或在为一个新应用分配数据接收端口时，可能要分配很多次才能为应用分配到未被占用的数据接收端口。

若该应用是第一个开启了录音功能的应用，且该应用根据现有技术的方法获取的录音数据，即该应用未占用数据接收端口，则当该应用关闭录音功能时，优选的C++录音框架不再将录音数据发送给Android录音代码。即关闭该应用获取数据的路径，但不关闭麦克风，且C++录音框架仍可以从麦克风获取录音数据，然后将录音数据发送给数据发送端口。

当所有开启录音功能的应用都关闭录音功能时，关闭麦克风，关闭录音模块。

示例的，只有一个应用开启录音功能，可选的，录音模块采用现有技术的方法下发录音开启指令，采用本发明提供的方法上传录音数据。优选的录音模块采用现有技术的方法下发录音开启指令以及上传录音数据。这样可以减少程序的复杂度。

示例的，有2个应用开启录音功能。第一个开启了录音功能的应用，录音模块可以按照现有技术的方法下发录音开启指令，采用本发明提供的方法上传录音数据；录音模块也可以采用现有技术的方法下发录音开启指令以及上传录音数据。在第一个仍在使用录音功能时，第二个开启了录音功能的应用，录音模块采用本发明提供的方法下发录音开启指令和上传录音数据。

示例的，有3个应用开启了录音功能，第一个开启了录音功能的应用，录音模块可以按照现有技术的方法下发录音开启指令，采用本发明提供的方法上传录音数据；录音模块也可以采用现有技术的方法下发录音开启指令以及上传录音数据。在第一个仍在使用录音功能时，第二个、第三个应用开启了录音功能，录音模块采用本发明提供的方法下发录音开启指令和上传录音数据。

示例的，有3个应用开启了录音功能，第一个开启了录音功能的应用，录音模块可以按照现有技术的方法下发录音开启指令，采用本发明提供的方法上传录音数据；录音模块也可以采用现有技术的方法下发录音开启指令以及上传录音数据。在第一个开启了录音功能的应用仍在使用录音功能时，第二个应用开启了录音功能，录音模块采用本发明提供的方法下发录音开启指令和上传录音数据。在第一个开启了录音功能的应用已关闭录音功能，第二个开启了录音功能的应用仍在使用录音功能时，第三个应用正在开启录音功能，录音模块采用本发明提供的方法下发录音开启指令和上传录音数据。

本发明实施例提供了一种向应用返回录音数据的方法，在麦克风被第一应用调用时，通过数据接收端口和数据发送端口等，将获得的录音数据发回给第二应用。这样通过类似于网络服务的方式来实现数据重用，从而解决了现有技术中当有应用正在调用麦克风时，其他应用无法开启录音功能的问题。

实施例二

本发明实施例提供了一种具有麦克风的终端，其中各个功能模块的实现可以参考上述实施例，在此不再赘述。参考图4所示，所述终端包括：

录音模块11，所述录音模块11与麦克风12连接，包括与麦克风12通信的数据发送端口111以及与所述数据发送端口111具有一对多映射关系的数据接收端口112；

所述录音模块11，用于在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口112，通过所述数据发送端口111获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为第二应用分配的数据接收端口112接收广播的录音数据，并将所接收的录音数据返回给第二应用。

可选的，所述录音开启指令包括所述第二应用所需的录音参数，所述录音参数包括下述的一种或多种：采样率，声道数，和录音格式。

可选的，所述录音模块11：还用于在将所接收的录音数据返回给所述第二应用之前，将由所述麦克风12采集到的录音数据按照所述第二应用所需的录音参数进行转换处理。

可选的，所述第一应用分配有另外一个对应的数据接收端口112。

可选的，所述数据发送端口111和数据接收端口112之间根据用户数据报协议UDP进行通信。

需要说明的是，本实施例中的录音模块可以为单独设立的处理器，也可以集成在终端的某一个处理器中实现，此外，也可以以程序代码的形式存储于终端的存储器中，由终端的某一个处理器调用并执行以上各个单元的功能。这里所述的处理器可以是一个中央处理器(英文全称：Central Processing Unit，英文简称：CPU)，或者是特定集成电路(英文全称：Application Specific Integrated Circuit，英文简称：ASIC)，或者是被配置成实施本发明实施例的一个或多个集成电路。

本发明实施例提供了一种具有麦克风的终端，该终端的录音模块在麦克风被第一应用调用时，通过数据接收端口和数据发送端口等，将获得的录音数据发回给第二应用。这样通过类似于网络服务的方式来实现数据重用，从而解决了现有技术中当有应用正在调用麦克风时，其他应用无法开启录音功能的问题。

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

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

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

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims

1.一种终端的麦克风的数据处理方法，其特征在于，所述终端包含与麦克风通信的数据发送端口以及与所述数据发送端口具有一对多映射关系的数据接收端口，所述方法包括：

在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为所述第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给所述第二应用；

所述第一应用分配有另外一个对应的数据接收端口。

2.根据权利要求1所述的方法，其特征在于，所述录音开启指令包括所述第二应用所需的录音参数，所述录音参数包括下述的一种或多种：采样率，声道数，和录音格式。

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

在将所接收的录音数据返回给所述第二应用之前，将由所述麦克风采集到的录音数据按照所述第二应用所需的录音参数进行转换处理。

4.根据权利要求1所述的方法，其特征在于，所述数据发送端口和数据接收端口之间根据用户数据报协议UDP进行通信。

5.一种具有麦克风的终端，其特征在于，所述终端包括：

所述录音模块，用于在麦克风被第一应用调用时，接收第二应用发出的录音开启指令，从未被占用的数据接收端口中为所述第二应用分配一个数据接收端口，通过所述数据发送端口获取由所述麦克风采集到的录音数据，并广播所采集的录音数据，通过为所述第二应用分配的数据接收端口接收广播的录音数据，并将所接收的录音数据返回给所述第二应用；

所述第一应用分配有另外一个对应的数据接收端口。

6.根据权利要求5所述的终端，其特征在于，所述录音开启指令包括所述第二应用所需的录音参数，所述录音参数包括下述的一种或多种：采样率，声道数，和录音格式。

7.根据权利要求5或6所述的终端，其特征在于，所述录音模块：还用于在将所接收的录音数据返回给所述第二应用之前，将由所述麦克风采集到的录音数据按照所述第二应用所需的录音参数进行转换处理。

8.根据权利要求5所述的终端，其特征在于，所述数据发送端口和数据接收端口之间根据用户数据报协议UDP进行通信。