CN107329726A - Android系统中对输入的音频数据的处理方法和装置 - Google Patents

Abstract

本申请提供一种Android系统中对输入的音频数据的处理方法和装置。该处理方法包括：在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；对写入所述缓存buffer的音频数据进行左右声道的混音操作；读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。本申请实施例仅考虑预设类型的音频数据，从而避免Android系统兼容所有类型的音频数据而造成延迟，满足低延迟场景的需求，提升用户体验。本申请实施例还可以减少Android系统的进程间通信开销，提高Android系统的处理效率。

Description

Android系统中对输入的音频数据的处理方法和装置

技术领域

本申请涉及数据处理技术领域，尤其涉及一种Android系统中对输入的音频数据的处理方法和装置。

背景技术

在一些互动场景下，通常配置多个有Android系统的移动设备进行无线互联。例如，唱歌场景，配置麦克和音箱采用蓝牙进行互联。

在Android系统接收到一个移动设备的蓝牙音频数据后，经过“蓝牙协议栈”进行协议解析，然后再将上述音频数据包写入到驱动层的虚拟设备节点UHID。Android系统的核心服务即音频数据实体AuduiFlinger对上述音频数据进行处理，将每次采样的音频包送到不同的线程进行混音，然后再送往处理该音频数据的进程进行处理以及输出。

但是，为兼容不同设备的音频格式，AuduiFlinger采用相同或者相近的流程处理不同格式的音频数据。由于AuduiFlinger需要对音频数据做大量的逻辑运算并多线程处理，导致Android系统冗余，延缓了音频数据的传输。也就是说，android原生平台所有类型的音频数据，例如蓝牙音频数据，按键音音频数据，系统声音音频数据等等都需要从Audioflinger中进行音效处理，而Audiofliger需要兼容所有的设备节点上传的音频数据进行分割和混音处理，造成用户常用的外接音频设备例如蓝牙外设输入的蓝牙音频数据流程处理比较慢，延迟比较明显；以蓝牙音频数据为例，由于人耳对音频的延迟感受大约是50ms，特别是在某些场景时对蓝牙音频数据具有低延迟要求。例如在唱歌场景中，利用上述音频处理方法处理蓝牙音频数据时，从用户发声到听到声音之间延时超过110ms，声音延迟过大而影响交互效果。

发明内容

有鉴于此，本申请提供一种Android系统中对输入的音频数据的处理方法和装置，用于缓解现有Android系统处理蓝牙音频数据时延时过长的问题。

具体地，本申请是通过如下技术方案实现的：

一方面，本申请实施例提供了一种Android系统中对输入的音频数据的处理方法，该处理方法包括：

在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；

对写入所述缓存buffer的音频数据进行左右声道的混音操作；

读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。

可选地，在接收到目标设备上报的音频数据之后，且在将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer之前，所述方法进一步包括：

确定音频处理模式；

若确定出的音频处理模式为用于指示写入缓存buffer的模式，则继续执行所述将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

可选地，确定音频处理模式的步骤，包括；

检查Android系统当前是否仅有指定类型的音频数据；所述指定类型为所述目标设备支持的音频数据类型；

若是，则确定所述音频模式为指示写入缓存buffer的模式；

若否，则输出模式切换选择消息以使用户选择音频处理模式；

依据用户的选择确定音频处理模式。

可选地，确定音频处理模式的步骤，包括；

检查已配置的音频处理模式的标记位；

若所述标记位为用于指示将所述音频数据写入缓存buffer的第一预设值，则确定所述音频模式为指示写入缓存buffer的模式；

若所述标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值，则确定所述音频模式为上报至音频数据实体AudioFlinger的模式。

可选地，将所述音频数据写入缓存buffer的步骤，包括：

对所述音频数据进行解析并将解析后的音频数据输出至目标设备驱动节点HIDROW；

所述目标设备驱动节点HIDROW将所述解析后的音频数据输出至音频读取接口VoiceCap；

所述音频读取接口VoiceCap将所述解析后的音频数据输出至所述缓存buffer。

另一方面，本申请实施例提供了一种Android系统中对输入的音频数据的处理装置，所述装置包括：

切换模块，用于在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；

混音模块，用于对写入所述缓存buffer的音频数据进行左右声道的混音操作；

读取模块，用于读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。

可选地，所述装置还包括：

模式确定模块，用于确定音频处理模式；

数据写入模块，用于在确定出的音频处理模式为用于指示写入缓存buffer的模式时，继续执行所述将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

可选地，所述模式确定模块包括：

类型检测单元，用于检查Android系统当前是否仅有指定类型的音频数据；所述指定类型为所述目标设备支持的音频数据类型；

第一音频模式确定单元，用于在所述Android系统当前仅有指定类型的音频数据时，确定所述音频模式为指示写入缓存buffer的模式；

第二音频模式确定单元，用于在所述Android系统当前包括指定类型之外的音频数据时，输出模式切换选择消息以使用户选择音频处理模式；依据用户的选择确定音频处理模式。

可选地，所述模式确定模块包括：

标记位检测单元，用于检测已配置的音频处理模式的标记位；

第三音频模式确定单元，用于在所述标记位为用于指示将所述音频数据写入缓存buffer的第一预设值时，确定所述音频模式为指示写入缓存buffer的模式；

第四音频模式确定单元，用于在所述标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值时，则确定所述音频模式为上报至音频数据实体AudioFlinger的模式。

可选地，所述切换模块包括：

数据解析单元，用于对所述音频数据进行解析并将解析后的音频数据输出至目标设备驱动节点HIDROW；

目标设备驱动节点HIDROW单元，用于将所述解析后的音频数据输出至音频读取接口VoiceCap；

音频读取接口VoiceCap单元，用于将所述解析后的音频数据输出至所述缓存buffer。

由上述技术方案可知，本申请实施例通过在接收到目标设备上报的音频数据后，将音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；然后对写入所述缓存buffer的音频数据进行左右声道的混音操作；最后读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。与相关技术相比较，本申请实施例针对指定类型的音频数据设置单独的进入缓存buffer处理的流程，从而避免现有Android系统为兼容所有类型的音频数据而造成的音频数据输出延迟，可以满足低延迟场景的需求，提升用户体验。并且，本申请中在仅有指定类型的音频数据时，可避免使用AudioFlinger处理预设类型的音频数据，能够减少Android系统的进程间通信开销，提高Android系统的处理效率。

附图说明

图1是本申请一实施例中提供的Android系统中对输入的音频数据的处理方法的流程示意图；

图2是图1所示步骤101中确定音频处理模式的流程示意图；

图3是本申请一实施例中用户切换音频处理模式示意图；

图4是图2所示步骤201中确定音频数据类型的流程示意图；

图5是图2所示步骤201中确定音频数据类型的流程示意图；

图6是本申请另一实施例中用户切换音频处理模式示意图；

图7是Android系统中音频子系统Audio处理音频数据的流程示意图；

图8是本申请一实施例中提供的Android系统中对输入的音频数据的处理方法的流程示意图；

图9是本申请一实施例中提供的Android系统中对输入的音频数据的处理装置的框图；

图10是本申请另一实施例中提供的Android系统中对输入的音频数据的处理装置的框图；

图11是图10所示处理装置中模式确定模块的一种结构示意图；

图12是图10所示处理装置中模式确定模块的另一种结构示意图；

图13是图9所示处理装置中切换模块的结构示意图。

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

本申请实施例提供了一种Android系统中对输入的音频数据的处理方法，如图1所示，该处理方法包括：

步骤101，在接收到目标设备上报的音频数据后，将音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer。

现有Android系统中，所有音频设备上报的音频数据都会上报至音频数据实体AudioFlinger，由AudioFlinger进行处理。在步骤101中，若是目标设备上报的音频数据(可以理解为指定类型，即目标设备支持的音频数据的类型)则由上报至音频数据实体AudioFlinger流程(后续称全通道音频处理方式)切换至写入缓存buffer(后续称指定音频处理方式)，能够避免音频数据实体AudioFlinger处理音频数据时引起的延迟问题，在低延迟的特定场景中可提升用户使用体验。

为实现全通道音频处理方式和指定音频处理方式之间灵活切换，本申请一实施例中，步骤101中的在接收到目标设备上报的音频数据之后，将音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer之前，确定音频处理模式，如图2所示，包括：

步骤201，确定音频处理模式。

实际应用中，音频处理模式配置方式可以包括静态配置和动态配置。

本申请一实施例中，静态配置可由人工设置音频处理模式，此时模式切换选择可以设置在Android系统的操作菜单中。如图3所示，用户可以选择“设置”按钮(如图3(a)所示)，得到如图3(b)所示的“设置”菜单。然后在上述“设置”菜单中选择“音频处理模式”选项，得到如图3(c)所示的“音频处理模式”子菜单，触发“指定音频处理模式”选项或者“全通道音频处理模式”即可。本申请一实施例中，音频处理模式可以由标记位确定，当标记位为第一预设值“1”时，指示将所述音频数据写入缓存buffer，当标记位为第二预设值“0”时，指示上报至音频数据实体AudioFlinger。即在确定音频处理模式的类型时，可以上述标记位的预设值来确定。本申请仅用移动终端进行示例性说明，本领域技术人员可以结合具体使用场景调整设置方式以及触发方式，本申请不作限定。

在静态配置完成之后，本申请一实施例中确定音频处理模式可以采用如图4所示步骤，包括：

步骤401，检查已配置的音频处理模式的标记位。

步骤402，若标记位为用于指示将音频数据写入缓存buffer的第一预设值“1”，则确定音频模式为指示写入缓存buffer的模式即指定音频处理模式。

步骤403，若标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值“0”，则确定音频模式为上报至音频数据实体AudioFlinger的模式即全通道音频处理模式。

本申请一实施例中，动态配置可以由Android系统完成。此时，Android系统轮询所有音频驱动(例如，蓝牙驱动、USB音频驱动或者扬声器音频驱动等)。此时，确定音频处理模式可以采用如图5所示步骤，包括：

步骤501，检查Android系统当前是否仅有指定类型的音频数据；指定类型为目标设备支持的音频数据类型。

步骤502，若仅有指定类型的音频数据，则确定音频模式为指示写入缓存buffer的模式。

步骤503，若除指定类型的音频数据，还包括其他类型的音频时，则输出模式切换选择消息以使用户选择音频处理模式；依据用户的选择确定音频处理模式。

本申请一实施例中，若指定类型的音频数据为一种时，Android系统检测当前音频数据的类型和数量，若检测到仅有目标设备有音频数据输入时，此时Android系统可以将音频处理模式切换到指定音频处理模式；若有多路音频数据输入，可以直接切换到全通道音频处理模式，此切换过程用户无感知。当然，有多路音频数据输入时，如图6(a)所示，也可以由Android系统发出模式切换选择消息，如图6(b)所示，根据用户触发选择切换到确定音频处理模式为全通道音频处理模式或者蓝牙音频处理模式。

步骤202，若确定出的音频处理模式为用于指示上报至音频数据实体AudioFlinger的模式，则将音频数据上报至音频数据实体AudioFlinger。

本申请一实施例中，以蓝牙音频数据为例进行说明，如图7所示，蓝牙音频数据通过蓝牙设备接收后输入到Android系统中，然后经过“蓝牙协议栈”进行音频数据解析得到音频数据包，然后写入到虚拟设备节点UHID中。上述过程为蓝牙音频数据的物理链路传输过程。音频数据进入到Android系统内，经过硬件抽象层(HAL)，送至AudioFlinger进行音频数据的处理。然后AudioFlinger将每次采样的音频包送到不同的线程进行混音，之后通过进程间通信机制IPC送往专门负责处理该音频数据的进程来实现音频的输出。

为兼容不同的音频数据格式，AudioFlinger需要复杂的线程结构进行大量的逻辑运算，并且为每个放音/录音设备创建一个处理线程，以实现音频数据的合成、输入和输出。换言之，AudioFlinger对各种类型的音频数据采用相同的处理方式。

步骤203，若确定出的音频处理模式为用于指示写入缓存buffer的模式，则继续执行将音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

步骤102，对写入缓存buffer的音频数据进行左右声道的混音操作。

在步骤102中，对写入缓存buffer的音频数据进行左右声道的混音操作时，可以采用现有的混音方式实现，在此不再说明。

继续以蓝牙音频数据为例进行说明，本申请一实施例中，如图8所示，蓝牙音频数据通过蓝牙设备接收后上报至Android系统中，经过“蓝牙协议栈”进行音频数据解析得到音频数据包，直接写入到虚拟蓝牙设备节点HIDROW中。当指定类型为其他音频数据类型时，该蓝牙设备节点HIDROW可以由其他目标设备节点替换。蓝牙音频数据包经过音频读取接口VoiceCap被写入第一缓存(即上述缓存buffer)。与全通道音频处理模式相比较，本申请中蓝牙音频处理模式不需要采样处理，可以直接写入HIDROW中，可以减少数据缓存，读取效率更高。

本申请一实施例中，创建处理进程对蓝牙音频数据进行左右声道混音处理。为降低进程间调用的开销，上述处理进程包括两个线程(即第一线程和第二线程)。第一线程从第一缓存中读取蓝牙音频数据，将分割成预设大小的音频数据包，例如，音频数据包的大小为128字节，之后发送给第二线程。第一线程在处理蓝牙音频数据的过程中，将标识嵌入到音频数据包的头数据中，例如，第一缓存中的地址、第二缓存中的地址、音频数据包中音频数据的大小、前后包标记等。第二线程对上述音频数据包进行左右声道混音处理，在混音过程中插入存储地址的标记，并将混音后的音频数据包发送到第二缓存保存。当然，处理进程还可以直接记录混音处理后的音频数据在第二缓存中的存储地址，然后将存储地址和偏移量直接发送给后续的播放进程。

需要说明的是，第一缓存和第二缓存仅用于区别音频数据在处理过程中进行存储的过程，实际应用中，第一缓存和第二缓存可以由同一个物理实体实现。

可理解的是，存储地址是音频数据包在第二缓存中的位置。在蓝牙音频数据传输的大多数场景下，用户基本上不关心其他音频数据，仅将用户关注的蓝牙音频数据进行有效处理，因此以上设置可以提高音频数据的处理效率。

步骤103，读取混音后的音频数据，并将混音后的音频数据写入至Android系统的脉冲编码调制PCM音频驱动。

步骤103中，直接从第二缓存中读取混音后的音频数据包，并将上述音频数据包直接写入Android系统的PCM音频驱动以及喇叭中。

实际应用中，处理音频数据时，本申请实施例提供的处理方法可以实现延时小于100ms，在如唱歌、视频通话等具体交互场景下，可以满足用户的要求，提升交互体验。本申请实施例能够提高蓝牙音频数据输出的效率。

需要说明的是，本申请一实施例中，在蓝牙音频数据模式时可以创建三个线程：读取进程、处理进程和播放进程。其中读取进程完成步骤102中从第一缓存中读取指定类型的音频数据的过程，处理进程完成步骤102中对音频数据的左右声道的混音处理。播放进程完成步骤103中音频数据的读取以及输出至PCM音频驱动的过程。当然，上述读取进程、处理进程和播放进程可以采用Android系统中的相应进程实现，本申请不作限定。

需要说明的是，本申请上述实施例中仅以蓝牙音频数据为例描述了上述处理方法，当然根据特殊场景的需求以及音频数据的特点可以对上述处理方法作适当的调整，实现在指定音频数据模式和全通道音频数据模式之间切换，同样可以达到减少Android系统开销，提高处理效率的效果。

本申请实施例中指定音频处理模式可以独立完成指定音频数据的处理，即不需要通过Android系统的音频子系统Audio处理(无需启动AudioFlinger)，减少进程开销以及指定类型的音频数据在Android系统中的存留时间。

依据上述处理方法，本申请实施例还提供了一种Android系统中对输入的音频数据的处理装置，如图9所示，所述装置包括：

切换模块901，用于在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；

混音模块902，用于对写入所述缓存buffer的音频数据进行左右声道的混音操作；

读取模块903，用于读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。

本申请一实施例中，如图10所示，该处理装置还包括：

模式确定模块1001，用于确定音频处理模式；

数据写入模块1002，用于在确定出的音频处理模式为用于指示写入缓存buffer的模式时，继续执行所述将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

本申请另一实施例中，如图10所示，该处理装置还包括：

数据上报模块1003，用于在确定出的音频处理模式为用于指示上报至音频数据实体AudioFlinger的模式时，将所述音频数据上报至所述音频数据实体AudioFlinger；

本申请一实施例中，如图11所示，上述模式确定模块1001包括：

类型检测单元1101，用于检查Android系统当前是否仅有指定类型的音频数据；所述指定类型为所述目标设备支持的音频数据类型；

第一音频模式确定单元1102，用于在所述Android系统当前仅有指定类型的音频数据时，确定所述音频模式为指示写入缓存buffer的模式；

第二音频模式确定单元1103，用于在所述Android系统当前包括指定类型之外的音频数据时，输出模式切换选择消息以使用户选择音频处理模式；依据用户的选择确定音频处理模式。

本申请一实施例中，如图12所示，上述模式确定模块1001包括：

标记位检测单元1201，用于检测已配置的音频处理模式的标记位；

第三音频模式确定单元1202，用于在所述标记位为用于指示将所述音频数据写入缓存buffer的第一预设值时，确定所述音频模式为指示写入缓存buffer的模式；

第四音频模式确定单元1203，用于在所述标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值时，则确定所述音频模式为上报至音频数据实体AudioFlinger的模式。

本申请一实施例中，如图13所示，上述切换模块901包括：

数据解析单元1301，用于对所述音频数据进行解析并将解析后的音频数据输出至目标设备驱动节点HIDROW；

目标设备驱动节点HIDROW单元1302，用于将所述解析后的音频数据输出至音频读取接口VoiceCap；

音频读取接口VoiceCap单元1303，用于将所述解析后的音频数据输出至所述缓存buffer。

关于上述实施例中的装置，其中各个单元或者模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

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

Claims (10)

1.一种Android系统中对输入的音频数据的处理方法，其特征在于，所述方法包括：

在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；

对写入所述缓存buffer的音频数据进行左右声道的混音操作；

读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。

2.根据权利要求1所述的处理方法，其特征在于，在接收到目标设备上报的音频数据之后，且在将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer之前，所述方法进一步包括：

确定音频处理模式；

若确定出的音频处理模式为用于指示写入缓存buffer的模式，则继续执行所述将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

3.根据权利要求2所述的处理方法，其特征在于，确定音频处理模式的步骤，包括；

检查Android系统当前是否仅有指定类型的音频数据；

若是，则确定所述音频模式为指示写入缓存buffer的模式；

若否，则输出模式切换选择消息以使用户选择音频处理模式；

依据用户的选择确定音频处理模式。

4.根据权利要求2所述的处理方法，其特征在于，确定音频处理模式的步骤，包括；

检查已配置的音频处理模式的标记位；

若所述标记位为用于指示将所述音频数据写入缓存buffer的第一预设值，则确定所述音频模式为指示写入缓存buffer的模式；

若所述标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值，则确定所述音频模式为上报至音频数据实体AudioFlinger的模式。

5.根据权利要求1所述的处理方法，其特征在于，将所述音频数据写入缓存buffer的步骤，包括：

对所述音频数据进行解析并将解析后的音频数据输出至目标设备驱动节点HIDROW；

所述目标设备驱动节点HIDROW将所述解析后的音频数据输出至音频读取接口VoiceCap；

所述音频读取接口VoiceCap将所述解析后的音频数据输出至所述缓存buffer。

6.一种Android系统中对输入的音频数据的处理装置，其特征在于，所述装置包括：

切换模块，用于在接收到目标设备上报的音频数据后，将所述音频数据从上报至音频数据实体AudioFlinger流程切换为写入缓存buffer；

混音模块，用于对写入所述缓存buffer的音频数据进行左右声道的混音操作；

读取模块，用于读取混音后的音频数据，并将所述混音后的音频数据写入至所述Android系统的脉冲编码调制PCM音频驱动。

7.根据权利要求6所述的处理装置，其特征在于，所述装置还包括：

模式确定模块，用于确定音频处理模式；

数据写入模块，用于在确定出的音频处理模式为用于指示写入缓存buffer的模式时，继续执行所述将所述音频数据从上报至音频数据实体AudioFlinger切换为写入缓存buffer的步骤。

8.根据权利要求7所述的处理装置，其特征在于，所述模式确定模块包括：

类型检测单元，用于检查Android系统当前是否仅有指定类型的音频数据；

第一音频模式确定单元，用于在所述Android系统当前仅有指定类型的音频数据时，确定所述音频模式为指示写入缓存buffer的模式；

第二音频模式确定单元，用于在所述Android系统当前包括指定类型之外的音频数据时，输出模式切换选择消息以使用户选择音频处理模式；依据用户的选择确定音频处理模式。

9.根据权利要求7所述的处理装置，其特征在于，所述模式确定模块包括：

标记位检测单元，用于检测已配置的音频处理模式的标记位；

第三音频模式确定单元，用于在所述标记位为用于指示将所述音频数据写入缓存buffer的第一预设值时，确定所述音频模式为指示写入缓存buffer的模式；

第四音频模式确定单元，用于在所述标记位为用于指示上报至音频数据实体AudioFlinger的第二预设值时，则确定所述音频模式为上报至音频数据实体AudioFlinger的模式。

10.根据权利要求6所述的处理装置，其特征在于，所述切换模块包括：

数据解析单元，用于对所述音频数据进行解析并将解析后的音频数据输出至目标设备驱动节点HIDROW；

目标设备驱动节点HIDROW单元，用于将所述解析后的音频数据输出至音频读取接口VoiceCap；

音频读取接口VoiceCap单元，用于将所述解析后的音频数据输出至所述缓存buffer。