CN115993948A - 音频处理方法、相关设备及存储介质 - Google Patents

Abstract

本申请公开了一种音频处理方法、相关设备及存储介质，其中，所述方法包括：采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得多核异构系统中的M个应用域的各音频数据；多核异构系统包括多硬件域；多硬件域中的各硬件域由多核异构系统中多个处理器核与各处理核连接的硬件资源构成，各硬件域之间互相隔离；M个应用域和管理域与多硬件域中的至少部分硬件域对应；将各音频数据分配到管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

Description

音频处理方法、相关设备及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种音频处理方法、装置、芯片、电子设备及计算机存储介质。

背景技术

在播放系统存在两个或多个待播放音频和数量有限的播放器如单个扬声器的情况下，为不影响相同时刻对各个待播放音频的正常播放，相关技术中可采用增加硬件开销的方式给予解决。进一步地，在硬件上，采用具有音频处理功能的硬件，如数字信号处理芯片(DSP，Digital Signal Processing)将这些待播放音频进行一定的音频处理(如混音、拼接和/或音效处理)，并通过播放器进行播放。在硬件上，一旦硬件接口之间完成连接，待播放音频之间的音频处理方式不易发生改变，灵活性差。

发明内容

本申请提供了一种音频处理方法、装置、芯片、电子设备及计算机存储介质，以至少解决现有技术中存在的以上技术问题。

根据本申请的第一方面，提供了一种音频处理方法，包括：

采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述管理域与所述多硬件域中的至少部分硬件域对应；

将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；

对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

在一可实施方式中，每个音频数据包括至少一个声道数据流；

所述将各音频数据分配到所述管理域的N个第一音频节点，包括：

将每个音频数据包括的全部声道数据流分配到N个第一音频节点中的至少一个第一音频节点。

在一可实施方式中，所述对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，包括：所述各第一音频节点中的至少一个第一音频节点对应一音频播放器；

对分配到对应于同一音频播放器的第一音频节点的各声道数据流进行音频处理；

基于对各音频播放器对应的各第一音频节点的声道数据流的音频处理结果，得到针对所述各音频数据的目标音频。

在一可实施方式中，所述每个音频数据的各声道数据流由所述M个应用域的各应用域中的各第一虚拟音频驱动单元从各应用域中发送；所述多核异构系统中的管理域包括第二虚拟音频驱动单元；

其中，所述由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据，包括：

所述管理域通过所述第二虚拟音频驱动单元利用与每个音频数据对应的通道进行每个音频数据的全部声道数据流的接收，而获得M个应用域的各音频数据。

在一可实施方式中，所述方法还包括：

基于所述M个应用域中的至少部分应用域的音频录制请求，将录制音频分配至第二音频节点，以将所述录制音频发送至所述至少部分应用域；其中，所述录制音频为音频录制请求所请求录制的音频；

其中，所述音频录制请求基于所述核间通信机制而得到。

在一可实施方式中，所述对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，包括：

对分配到各第一音频节点的声道数据流和第二音频节点的录制音频的录制数据流进行音频处理，得到目标音频。

在一可实施方式中，所述至少部分应用域中的每个域对应有录制音频，所述录制音频包括至少一个录制数据流；

所述将录制音频分配至第二音频节点，包括：

将每个录制音频的全部录制数据流分配至至少一个第二音频节点。

在一可实施方式中，所述每个音频数据对应的通道的数量与所述每个音频数据包括的声道数据流的数量相同或不同。

根据本申请的第二方面，提供了一种音频处理装置，包括：

获得单元，用于采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述管理域与所述多硬件域中的至少部分硬件域对应；

分配单元，用于将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；

处理单元，用于对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

根据本申请的第三方面，提供了一种芯片，所述芯片包括前述的音频处理装置。

根据本申请的第四方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行本申请所述的方法。

根据本申请的第五方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行本申请所述的方法。

本申请的音频处理方法、装置、芯片、电子设备及计算机存储介质，其中所述方法包括：采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

这种管理域的管理方案为一种基于软件实现的管理方案，与相关技术中增加硬件开销的方案相比，具有很强的灵活性。也可避免由于硬件开销的增加而导致的成本增加的问题。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

通过参考附图阅读下文的详细描述，本申请示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本申请的若干实施方式，其中：

在附图中，相同或对应的标号表示相同或对应的部分。

图1示出了本申请实施例中多核异构系统的示意图一；

图2示出了本申请实施例中多核异构系统的示意图二；

图3示出了本申请实施例中音频处理方法的实现流程示意图一；

图4示出了本申请实施例中基于管理域实现音频处理方法的示意图；

图5示出了本申请实施例中音频播放和音频录制的实现示意图；

图6示出了本申请实施例中音频处理方法的实现流程示意图二；

图7示出了本申请实施例中音频处理方法的实现流程示意图三；

图8示出了本申请实施例中基于Android HAL实现音频处理方法的示意图一；

图9示出了本申请实施例中基于Android HAL实现音频处理方法的示意图二；

图10示出了本申请实施例中音频处理装置的组成结构示意图；

图11示出了本申请实施例中电子设备的组成结构示意图。

具体实施方式

为使本申请的目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解,“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

应理解，在本申请的各种实施例中，各实施过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

本申请涉及的音频处理方式包括但不限定于以下几种：

1)混音，是将两种或多种来源的音频，整合至一个立体音轨或单音音轨中。在混音的过程中，将每一个音频信号的频率、动态、音质、定位、残响和声场单独进行调整，让各音轨最佳化，再叠加于最终成品上。这种处理方式，能制作出一般听众在现场录音时不能听到的层次分明的音频输出效果。

2)拼接，指的是音频通道拼接，是将一个或者多个音频的一个或者多个通道按照一定规则重新分配到另外一个音频的通道上去，组合成为一个全新的音频，以满足听众或者音频处理的需求。

3)音效处理，通过改变音量大小、音色、声调等参数、和/或消除人声等达到对音频输出效果进行处理的目的。

本申请中的音频处理方法的处理逻辑部署于多核异构系统中。本申请实施例中，多核异构系统包括多核异构芯片。多核异构芯片，是指在单颗芯片内集成有两个或多个处理器核的芯片。如，集成有两个或多个处理器核的单颗SOC(片上系统)芯片。多核异构芯片中的每个处理器核可作为一个独立处理器，可独立运行每个处理器核需要运行的指令，实现每个处理器核需要实现的任务。可以理解，多核异构芯片作为一种具有多核处理器的芯片。与单核处理器芯片相比，各核任务的独立运行，可加快运行速度，提高多任务执行能力，从而带来性能高的优势。且多核处理器被设置在同一芯片上，具有成本低的优势。

如图1所示，所述多核异构芯片包括多个处理器核，所述多个处理器核包括第一处理器核、第二处理器核…第L处理器核。L为大于等于2的正整数，根据实际情况而灵活设定。在多个处理器核中，每个处理器核相当于是一个计算引擎，其类型和/或数量可不同。其中，处理器核的类型包括计算能力强的核和实时性强(计算快)的核。在实际应用中，多个处理器核可以是不同类型的处理器核，由此，多核异构芯片是由多个架构不同的处理器核构成的。处理器核的类型和/或数量的不同，可在一定程度上实现处理器核之间的架构不同。

示例性地，由于嵌入式处理器(ARM)具有成本低和低功耗的优势，数字信号处理器(DSP)具有数字专用处理的优势，可编程逻辑阵列(FPGA)具有高速处理的优势，每种类型的处理器作为一种处理器核使用，被设计在同一SOC芯片上，即可得到一种多核异构的SOC芯片。

每个处理器核与各处理器核连接的硬件资源，如时钟控制器、中断控制器、内存空间等构成每个硬件域。即，多核异构芯片包括多个硬件域。在多核异构芯片中，每个硬件域是一组硬件资源的集合。不同硬件域之间是互相隔离的，这种隔离可视为一种物理上的隔离，如同一硬件域内的硬件设计在多核异构芯片的相近位置，不同硬件域内的硬件设计在多核异构芯片的不同位置，以物理位置上实现隔离。当然，本申请实施例中的不同硬件域之间的互相隔离可以不是物理上的隔离，而是逻辑上的隔离。这种逻辑上的隔离可体现在：同一硬件域内的硬件资源需要使用同一通信标识进行本硬件域内的访问，即，同一硬件域内的硬件资源之间可基于本硬件域内的通信标识进行互相访问。不同硬件域内的硬件资源使用不同的通信标识进行访问。

在实际应用中，优选不同硬件域之间的互相隔离为一种逻辑隔离，如此至少可节省芯片空间。

在多核异构芯片中，为每个硬件域配置一操作系统。如，为第一硬件域配置第一操作系统，为第二硬件域配置第二操作系等。为不同硬件域配置的操作系统的可以为相同系统，可以为不同，优选为不同系统。如，为第一硬件域配置的第一操作系统为Linux系统，为第二硬件域配置的第二操作系统为安卓系统。其中，由于Linux系统具有安全性高的特点、安卓系统具有轻快性的特点，可将多核异构系统中对安全性要求高的任务交由Linux去执行，将多核异构系统中对需要轻快运行的任务交由安卓系统去执行，因此，多核异构系统中可以采用不同硬件域上的不同操作系统实现各任务的高效执行。

为实现对多核异构系统的应用，本申请实施例中，将各硬件域对应的操作系统视为各应用域的操作系统。通过各应用域，实现对多核异构系统的应用，如在音频、视频输出等方面的应用。

在一些实施例中，为实现更好地应用，可从各应用域中选择出一个或多个应用域作为管理域使用。如图2所示，从各应用域中选择出一个应用域作为管理域来使用。如果将管理域和应用域作为一种域来使用，那么本申请中的应用域是用于应用的域，管理域是用于管理应用域的域。与相关技术中采用增加硬件开销方式，实现相同时刻对各个待播放音频的正常播放(硬件层面的播放方案)不同，本申请中，基于管理域的管理，实现相同时刻对各个待播放音频的正常播放不同。这种管理可视为是一种通过软件层面上的管理，实现的相同时刻对各个待播放音频的正常播放的方案。基于软件层面实现的播放，灵活性佳，可大大避免硬件层面的播放的不灵活性。

本申请实施例中，硬件域之间也存在有通信需求，在不同硬件域之间存在通信需求时，可采用核间通信机制实现硬件域之间的通信。其中，多核异构系统中的核间通信机制包括适于指令传输的mailbox机制、适于数据共享的内存共享机制。单颗SOC芯片内的核间通信，可保证数据在同一芯片内传输，保证了数据安全性和传输快速性。

通常情况下，不同硬件域内的硬件资源是存在差异的，这种差异可能体现在硬件类型、硬件型号、硬件数量等方面的差异。这种差异性，在一定程度上可体现多核异构系统的异构性。从前面的介绍可知，本申请中的多核异构是硬件层面上的概念，与软件层面无关。

如图1所示，本申请实施例中的多核异构芯片还包括各类型控制单元。各类型控制单元包括但不限定于：电源控制单元、非易失性存储控制单元、易失性存储控制单元等。其中，电源控制单元，用于控制电源单元，以实现对多核异构芯片的电源的供给。非易失性存储控制单元，用于控制多核异构芯片中的至少一处理器核对非易失性存储单元的访问。易失性存储控制单元，用于控制多核异构芯片中的至少一处理器核对易失性存储单元的访问。

其中，电源单元、非易失性存储单元、易失性存储单元作为多核异构芯片之外的硬件资源，可在多核异构芯片有需要的情况下被调用。除此之外，音频输出单元(如喇叭或扬声器)、音频采集单元(如麦克风)、视频输出单元(如显示屏)等硬件作为多核异构芯片之外的硬件资源，也可在多核异构芯片有需要的情况下被调用，以实现音频、视频的正常输出。

本申请实施例中的多核异构系统包括多核异构芯片和为不同硬件域配置的操作系统。本申请实施例的音频处理方法是在多核异构系统上实现的，进一步的，是在多核异构系统中的管理域上实现的。

本申请实施例中，可将多核异构系统应用到驾驶设备中。驾驶设备包括私家出行工具和公共出行工具中的至少之一。其中，私家出行工具包括但不限定于平衡车、电动摩托车、私家汽车、私家飞机等。公共出行工具包括但不限定于公交车、火车、地铁、高铁、飞机等。

下面基于本申请的多核异构系统对本申请的音频处理方法、音频处理装置等技术方案进行详细说明。

本申请中音频处理方法的一实施例，应用于多核异构系统，进一步地，应用于多核异构系统的管理域。如图3所示，所述方法包括：

S301：采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述管理域与所述多硬件域中的至少部分硬件域对应。

本申请中，每个应用域存在一个或者多个待播放的音频(音频数据)。管理域通过读取或接收每个应用域的待播放音频而获得每个应用域的待播放音频。每个应用域也可能存在需要录音的音频，管理域可以将录音音频发送至应用域。且，管理域采用多核异构系统中的核间通信机制实现对各个应用域的待播放音频的读取或接收，和/或将各个应用域需要的录音音频分发到应用域。在实际应用中，核间通信机制可以是适于指令传输的mailbox机制。不同域(管理域和各应用域)之间基于mailbox机制实现域之间的通信，由于各域处于同一芯片内，单颗SOC芯片内的核间通信，可保证数据在同一芯片内传输的安全性和快速性。

本申请中，应用域的处理器核和管理域的处理器核的架构可以相同，还可以不同。不同域之间的处理器核的架构可以相同，也可以不同。视具体情况而定。

S302：将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分数据流；M和N均为大于或等于1的正整数。

本申请中，管理域包括两个或多个音频节点(Endpoint)。在某些极端情况下，管理域也可包括一个音频节点。考虑到本申请中包括对应用域的音频进行播放和对音频进行录制两种情形，优选管理域包括多个音频节点。针对管理域中的多个音频节点，挑选部分节点作为在应用域的音频播放情形下使用的节点(第一音频节点)。挑选部分节点作为在音频录制情形下使用的节点(第二音频节点)。当然，同一音频节点，既可作为第一音频节点，也可作为第二音频节点来使用，视具体情况而定。

可以理解，本申请实施例中，应用域的音频数据可以是单声道数据，则音频数据包括单声道数据流。应用域的音频数据可以是双声道数据，则音频数据包括两个声道数据流。应用域的音频数据可以是三声道、四声道或更多声道数据，则音频数据包括三个声道数据流、四个声道数据流或更多声道数据流。如此，本申请中的各音频数据包括一个、两个或多个声道数据流。

针对来自M个应用域的各音频数据，在其包括至少一个声道数据流的情况下，前述的将各音频数据分配到管理域的N个第一音频节点的方案，可通过如下方案来实现：将每个音频数据包括的全部声道数据流分配到N个第一音频节点中的至少一个第一音频节点。

针对每个音频数据的全部数据流，可将该全部数据流分配到不同的音频节点。还可以，将该全部数据流中的部分数据流分配到相同的音频节点，另一部分数据流分配到不同的音频节点。还可以将全部数据流分配到同一音频节点。具有分配灵活性。这种分配灵活性，可在一定程度上体现基于软件实现的各音频数据的播放的灵活性。

从单个音频节点的角度来看，其存储的可能是同一音频数据的一个、两个或多个数据流，还可能是不同音频数据的一个、两个或多个数据流。也就是说，在音频节点中，存储的是音频数据的数据流。分配到同一音频节点的数据流可能是同一音频数据的数据流、或不同音频数据的数据流。在这种情况下，每个音频节点可作为存储单元来使用，用于存储一个或多个音频数据的1个或至少两个声道数据流。

S303：对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

本步骤中，音频处理包括但不限定于前述的混音、拼接和音效处理中的至少其中之一，具有音频处理的灵活性。这种音频处理的灵活性，可体现基于软件实现的各音频数据的播放的灵活性。

如果音频处理为混音，则目标音频是对M个应用域的各音频数据经过混音处理而得到的音频。如果音频处理为拼接，则目标音频是对M个应用域的各音频数据经过拼接处理而得到的音频。如果音频处理为音效处理，则目标音频是对M个应用域的各音频数据经过音效处理而得到的音频。

S301～S303的执行主体为多核异构系统中的管理域。基于核间通信机制，管理域从各应用域获得的音频数据分配到各音频节点，并对分配到各第一音频节点的声道数据流进行音频处理，以得到针对各音频数据的目标音频。基于管理域对各应用域的音频数据的管理，实现对相同时刻各个待播放音频的正常播放。这种管理域的管理方案为一种基于软件实现的管理方案，具有分配灵活性和音频处理的灵活性。与相关技术中增加硬件开销的方案相比，具有很强的灵活性。也可避免由于硬件开销的增加而导致的成本增加的问题。

在一些实施例中，所述每个音频数据的各声道数据流由M个应用域的各应用域中的各第一虚拟音频驱动单元从各应用域中发送；所述多核异构系统中的管理域包括第二虚拟音频驱动单元；其中，所述由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据，包括：所述管理域通过所述第二虚拟音频驱动单元利用与每个音频数据对应的通道进行每个音频数据的全部声道数据流的接收，而获得M个应用域的各音频数据。

结合图4所示，以多核异构芯片为SOC(片上系统)芯片为例，包括3个应用域和1个管理域(虚拟设备管理域)。3个应用域和1个虚拟设备管理域对应不同的处理器核。如，应用域1对应处理器核CPU(中央处理器)-1，应用域2对应处理器核CPU-2，应用域3对应处理器核CPU-3，管理域对应处理器核CPU-4。

在本申请中，在应用域和管理域中安装虚拟音频驱动单元，虚拟驱动单元的安装是为了方便采用核间通信机制实现不同域之间的通信。为区分，将安装在应用域中的虚拟音频驱动单元作为第一虚拟音频驱动单元或虚拟音频驱动(单元)前端使用。将安装在管理域的虚拟音频驱动单元作为第二虚拟音频驱动单元或虚拟音频驱动(单元)后端使用。

可以理解，应用域中的音频数据包括一个单声道，双声道或者多声道的数据流。以应用域1的双声道数据流为例，应用域1的双声道数据流通过应用域的第一虚拟音频驱动单元发送至管理域。管理域通过虚拟音频驱动单元后端，采用两通道进行双声道数据流的接收。如，双声道数据流中的声道数据流1通过虚拟音频驱动单元后端、采用通道1接收，双声道数据流中的声道数据流2通过虚拟音频驱动单元后端、采用通道2接收。以应用域2的三声道数据流为例，应用域2的三声道数据流通过应用域的第一虚拟音频驱动单元发送至管理域。管理域通过虚拟音频驱动后端，采用三通道进行三声道数据流的接收。如，三声道数据流中的声道数据流1通过虚拟音频驱动后端、采用通道1接收。三声道数据流中的声道数据流2通过虚拟音频驱动后端、采用通道2接收。三声道数据流中的声道数据流3通过虚拟音频驱动单元后端、采用通道3接收。

在实际应用中，虚拟音频驱动后端可通过各应用域的标识来区分哪个音频数据是来自于哪个应用域的。针对来自同一应用域的两个或多个音频数据，可通过音频流标识确认每个音频流是同一个应用域的第几个音频流。每个音频数据对应的通道的数量与每个音频数据包括的声道数据流的数量相同或不同。如，针对应用域1的双声道数据流，虚拟音频驱动单元后端采用通道1接收。其中，通道1为双声道数据格式。针对应用域2的三声道数据流，虚拟音频驱动单元后端采用通道2接收。其中，通道2为3声道数据格式。针对应用域3的单声道数据流，虚拟音频驱动单元后端采用通道3接收。其中，通道3为单声道数据格式。

结合图4所示，管理域包括软件音频集线器，至少用于将各音频数据的声道数据流分配至N个第一音频节点，并对分配到各第一音频节点的声道数据流进行音频处理。示例性地，将来自应用域1的双声道数据流中的数据流1分配至音频节点1，将来自应用域1的双声道数据流中的数据流2分配至音频节点2。将来自应用域2的三声道数据流中的数据流1分配至音频节点1，将三声道数据流中的数据流2和数据流3分配至音频节点2(第一种方案)。或者，将三声道数据流中的数据流2分配至音频节点2，将三声道数据流中的数据流3分配至音频节点3(第二种方案)。声道数据流的分配方式可根据预先设置的配置信息而实现。其中，配置信息至少包括每个应用域的各声道数据流可被分配至哪个音频节点。在实施时，可根据对音频数据的输出效果的需求，灵活对配置信息进行配置。配置的方式可以是预先分配的静态配置方式，也可以是根据应用要求动态配置。由此，可实现分配的灵活性，进而实现从软件上实现对各音频播放的灵活性。

其中，静态配置方式是预先配置好的。例如，预先配置音频节点1的数据流经由音频输出设备1输出，音频节点2的数据流经由音频输出设备2输出。如此，在实施时，被配置至音频节点1的数据流需通过音频输出设备1播放，被配置至音频节点2的数据流需通过音频输出设备2播放。

动态配置方式是可根据实际应用情形或情况进行灵活配置的配置方式。如，原本需分配至音频节点1的数据流，被分配至了音频节点2，以使原本由音频节点1对应的音频输出设备1进行输出，切换为由音频节点2对应的音频输出设备2进行输出。或者，将原本需分配至音频节点1的数据流，既分配至了音频节点1，又分配至了音频节点2，使得音频节点1对应的音频输出设备1和音频节点2对应的音频输出设备2均进行了输出。

示例性地，如将来自应用域1的双声道音频数据和来自应用域2的三声道音频数据实现混音输出，则按照前述的第一种方案进行声道数据流到音频节点的分配。如将来自应用域1的双声道音频数据和来自应用域2的三声道音频数据实现混音以及音效处理后输出，则按照前述的第二种方案进行声道数据流到音频节点的分配。

在图4中，在多核异构系统中，还包括DMA(直接存储接口，Direct Memory Access)控制器、I2S(音频总线，InterIC Sound)设备、转换器(Codec)和音频输出单元如扬声器、SPDIF数字接口(Sony/Philips Digital Interface)和SPDIF设备。

对音频节点如音频节点1和音频节点2的声道数据流进行音频处理后的数据通过DMA或者CPU数据拷贝方式以比特形式进行传输、并经由I2S设备传输至Codec，通过Codec进行数字信号到模拟信号的转换，经转换而得来的模拟信号经由扬声器播放。对音频节点如音频节点3的声道数据流进行音频处理后的数据通过DMA以比特形式进行传输、并经由SPDIF总线接口传输至SPDIF设备，以进行播放。

前述方案中，通过管理域中的虚拟音频驱动单元和软件音频集线器，实现软件层面上的各音频播放方案。在软件层面上，可根据预先设置的配置信息，实现各声道数据流到音频节点的灵活分配，与相关技术相比，具有很强的灵活性。

在一些实施例中，所述对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频的方案包括：所述各第一音频节点中的至少一个第一音频节点对应一音频播放器；对分配到对应于同一音频播放器的第一音频节点的各声道数据流进行音频处理；基于对各音频播放器对应的各第一音频节点的声道数据流的音频处理结果，得到针对所述各音频数据的目标音频。

前述方案中，音频播放器为多核异构系统可调用的音频输出单元如扬声器，扬声器的数量为一个或至少两个。每个音频节点中的数据经音频处理后由哪个或哪些扬声器输出可预先进行配置(静态配置方式)或者在音频系统运行中动态配置(动态配置方式)。可根据实际情况进行配置，具有配置灵活性。其中，静态配置方式和动态配置方式参见前述相关说明，不赘述。

示例性地，配置音频节点1对应的扬声器为扬声器1，来自应用域1的双声道数据流中的数据流1分配至音频节点1，来自应用域2的双声道数据流中的数据流1分配至音频节点1，对音频节点1中的两数据流进行音频处理，并将经音频处理后的声音通过扬声器1输出。

配置音频节点2对应的扬声器为扬声器2，来自应用域1的双声道数据流中的数据流2分配至音频节点2，来自应用域2的双声道数据流中的数据流2分配至音频节点2，对音频节点2中的两数据流进行音频处理，并将经音频处理后的声音通过扬声器2输出。来自应用域1的音频数据和来自应用域2的音频数据经软件层面的音频处理后，经由扬声器1和扬声器2一同输出，经由扬声器1和扬声器2一同输出的音频即可视为目标音频。由此，实现了相同时刻对各音频数据的正常播放。

结合图5所示，软件音频集线器包括多个音频节点。其中，音频节点用于存储分配至自身的音频数据的声道数据流。因为软件音频集线器位于管理域，相对于管理域来说，来自应用域的音频数据的声道数据流可作为管理域的远端数据流使用，管理域自身需要播放的音频数据的声道数据流可作为管理域的本地数据流使用。从图5来看，音频节点1和2用于存储远端数据流，音频节点3用于存储本地数据流。图5所示的音频节点是用于存储远端数据流，还是用于存储本地数据流，仅是一种实现方式，其他任何合理的方案均覆盖在本申请范围内。将分配到对应于同一音频播放器的音频节点的各数据流进行音频处理，得到针对该同一音频播放器的待播放数据。全部音频播放器的待播放数据的集合即可视为目标音频。其中，在对应于同一音频播放器的音频节点的各数据流经音频处理后可通过该同一音频播放器输出时，对应于其他音频播放器的音频节点的各数据流经音频处理后可通过该其他音频播放器输出。如此，会令听众收听到各音频数据经混音、拼接或音量变大或变小等音效的音频输出效果。实现了对各应用域的音频数据的正常输出。

可以理解，本申请中的应用域的音频进行播放的处理流程主要在管理域侧实现，为此，管理域设置有虚拟音频驱动单元后端和软件音频集线器。虚拟音频驱动单元后端和软件音频集线器都是软件模块。利用软件模块执行音频播放的流程如图6所示。初始化软件音频集线器和虚拟音频驱动单元后端。针对虚拟音频驱动单元后端，创建音频驱动后端服务，通过该服务来判断是否接收有来自应用域的音频数据。如果判断为接收有来自应用域的音频数据，则将音频数据传输至软件音频集线器，软件音频集线器进行音频节点的分配，以实现对音频节点中的声道数据流的音频处理。针对软件音频集线器，为其配置播放参数，并创建播放流。可以理解，播放参数包括但不限于音频播放时的播放格式、音频采样率、和/或音频处理时的音频长度。被创建的播放流在被创建时其中承载的内容为空，需要在对各音频播放器对应的各第一音频节点的声道数据流进行音频处理后，将各音频处理结果承载在其上，从而得到目标音频。软件音频集线器判断是否有音频需要播放，或是否接收到音频数据。如果判断为是，则按照前述方案，得到目标音频，以供音频播放器进行播放。

在一些实施例中，所述音频处理方法还包括：

基于所述M个应用域中的至少部分应用域的音频录制请求，将录制音频分配至第二音频节点，以将所述录制音频发送至所述至少部分应用域；其中，所述录制音频为音频录制请求所请求录制的音频。

应用域在存在播放音频的需求之外，还存在有录制音频的需求。存在有录制需求的应用域通过核间通信机制如mailbox机制将该音频录制请求传输至管理域。进一步的，通过应用域的虚拟音频驱动单元，将音频录制请求传输至管理域的虚拟音频驱动单元后端，进而实现音频录制请求从应用域到管理域的传输。响应于音频录制请求，触发音频采集单元如麦克风进行需要录制的音频的录制。管理域读取麦克风录制的音频，将获取到的录制音频分配至一个或多个第二音频节点，第二音频节点用于保存录制音频。在有需要的情况下，可将第二音频节点保存的录制音频经由虚拟音频驱动单元后端发送至应用域的虚拟音频驱动单元，以实现录制音频从管理域到应用域的传输，以方便应用域对其需要的录制音频的使用。

结合图4所示，在实施时，由麦克风采集要录制的音频，采集到的音频经Codec进行模拟信号到数字信号的转换，转换后的数字信号经由I2S设备，通过比特形式传输至DMA，DMA将数字信号传输至要分配到的第二音频节点。

从前面方案来看，本申请的音频处理方法包括音频播放情形，还包括音频录制情形，适于实用，实用性强。在音频录制方案中，基于管理域的管理方案实现对音频的录制，简单易行。

在实际应用中，所述至少部分应用域中的每个域对应有录制音频，所述录制音频包括至少一个录制数据流。通俗来讲，对于具有录制需求的应用域，其需要录制的音频可采用单声道、双声道、三声道或更多声道进行录制，每个被录制的声道数据可视为一个录制数据流。如此，对于具有录制需求的某个应用域，其需要录制的一个音频可包括一个录制数据流，两个录制数据流，三个录制数据流或更多录制数据流。如此，前述的将录制音频分配至第二音频节点的方案可以是：将每个录制音频的全部录制数据流分配至至少一个第二音频节点。

即，针对同一录制音频的全部录制数据流，可将全部录制数据流分配至同一第二音频节点。也可以，将部分录制数据流分配至同一第二音频节点，其余录制数据流分配至另一个第二音频节点。还可以，将不同的录制数据流分配至不同的第二音频节点，视实际应用情况而定。

在实施时，可预先设置一配置信息，根据配置信息进行录制数据流到第二音频节点的分配。该配置信息用于指示哪个录制数据流分配到哪个第二音频节点，以实现录制数据流的期望分配。由此可见，本申请技术方案，通过管理域的音频录制管理方案，可实现分配灵活性，为录制音频的灵活输出提供了保障。

在将录制音频的录制数据流分配至一个或多个第二音频节点的情形下，前述的对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频的方案可以通过如下方式来实现：对分配到各第一音频节点的声道数据流和第二音频节点的录制音频的录制数据流进行音频处理，得到目标音频。

本申请技术方案中，录制音频的用途主要包括三种，其中第一种是用于测试，第二种是用于和第一音频节点的声道数据流一起进行音频处理以得到目标音频，第三种是用于存储，待到有需要时使用。

结合图5所示，以应用域1请求录制音频1为例，音频1需要采用双声道进行录制，得到录制数据流1和录制数据流2。将录制数据流1和录制数据流2分配至第二音频节点。如，将录制数据流1和录制数据流2分配至作为第二音频节点使用的音频节点5。如果此时应用域未存在需要播放的音频数据，分配至第二音频节点的录制数据流1和录制数据流2可经音效处理后，经过音频输出单元输出。这种方案，相当于采集到录制音频后，将音频输出的方案，该方案用于测试。如，用于测试音频输出单元和音频采集单元是否处于正常状态。如果音频输出单元输出的内容和音频采集单元采集到的内容相同，则说明音频输出单元和音频采集单元均处于正常状态。

如果此时应用域存在需要播放的音频数据，音频数据的声道数据流1被分配至作为第一音频节点使用的音频节点1，音频数据的声道数据流2被分配至作为第一音频节点使用的音频节点2。如果音频节点1和音频节点5对应同一音频播放器1，则将分配至音频节点5的录制数据流1和录制数据流2、以及分配至音频节点1的声道数据流1进行音频处理，以供音频播放器1输出。如果音频节点2对应音频播放器2，则分配至音频节点2的声道数据流2进行音频处理，以供音频播放器2输出。在实施时，音频播放器1和音频播放器2进行共同输出，共同输出的音频可作为目标音频。由此，可达到录制音频和应用域要播放的音频等不同音频的均正常输出。

在将录制数据流1和录制数据流2分配至音频节点5的情况下，还可将录制数据流1和录制数据流2分配至其他音频节点如音频节点4，以供存储，待到有需要时使用。例如，将录制数据流1和录制数据流2通过虚拟音频驱动单元后端发送至应用域1。如此，实现了对录制音频在不同用途方面的使用。

如图7所示，利用软件音频集线器和虚拟音频驱动单元后端等软件模块实现音频录制的流程是：初始化软件音频集线器和虚拟音频驱动单元后端。针对虚拟音频驱动单元后端，创建音频驱动后端服务，通过该服务来判断是否存在应用域的录音请求。如果存在应用域的录音请求，则请求软件音频集线器进行录音。针对软件音频集线器，为其配置录音参数，并创建录音流。可以理解，录音参数包括但不限于录音时的录音格式、录音采样率、和/或录音长度。在需要录音时，采用麦克风对需要录制的音频进行录音，得到录音流，以实现对录音流的创建。将录音流分配至一个或多个第二音频节点，并将第二音频节点中的录音流经由虚拟音频驱动单元后端发送至应用域的虚拟音频驱动单元，以实现录制音频从管理域到应用域的传输，方便应用域对录制音频的使用。

本申请技术方案中，管理域可采用Android(安卓)HAL(硬件抽象层)架构来实现音频处理方法中的音频播放方案。如图8所示，在Android HAL使用一个或者多个单声道、双声道或者TDM(采用时分复用技术的多声道)传送音频数据。每个单声道，双声道或者TDM通道有多个slot，图8是以TDM 8slot为例。在实际应用中，在汽车中出现的音频，即应用域请求播放的音频包括media(诸如音乐、视频等多媒体音频)、系统响声(system sound)、电话铃声(Ring Tone)、通话音(Phone)、导航音(Nav)等类型。

参见图8中的Android Playback slot(安卓播放时隙)以多媒体音频如音乐为四声道音频为例，四声道音频需映射到四个slot上。示例性地，声道数据流1映射到slot 1，声道数据流2映射到slot 2，声道数据流3映射到slot 3，声道数据流4映射到声道slot 4。可按照采用静态配置方式预先配置的用于指示哪个slot中的数据分配到哪个音频节点的配置信息，将映射到各slot的声道数据流分配到对应的音频节点(Endpoint)中。如，将slot 1和slot 2分配到Endpoint 2；将slot 3和slot 4分配到Endpoint 3。将分配到Endpoint 2的声道数据流进行音频处理，并通过与Endpoint 2对应的扬声器输出。以及，将分配到Endpoint 3的声道数据流进行音频处理，并通过与Endpoint 3对应的扬声器与Endpoint 2对应的扬声器一起同时输出。采用多个扬声器实现了多媒体音的正常输出，多个扬声器对同一音频进行输出，势必会为用户带来良好的收听效果。

以电话铃声为双声道为例，双声道音频需映射到二个slot上。示例性地，声道数据流1映射到slot 1，声道数据流2映射到slot 2。将slot 1和slot 2分配到Endpoint 4中。Endpoint 4和Endpoint 2对应相同的扬声器，将Endpoint 2和Endpoint 4的声道数据流进行音频处理，以供此相同扬声器进行输出。实现了电话铃声和音乐音的同时输出。

以通话音为单声道为例，单声道音频需映射到1个slot上。示例性地，声道数据流1映射到slot 1。将slot 1分配到Endpoint 5中。Endpoint 5和Endpoint2对应相同的扬声器，将Endpoint 5和Endpoint 2的声道数据流进行音频处理，以供此相同扬声器进行输出。采用同一扬声器实现了通话音和音乐音的同时输出。

以导航音为双声道音频为例，双声道音频需映射到两个slot上。示例性地，声道数据流1映射到slot 1，声道数据流2映射到slot 2。将slot 1和slot 2分配到Endpoint 6中。Endpoint 6和Endpoint 2对应相同的扬声器，将Endpoint 6和Endpoint 2的声道数据流进行音频处理，以供此相同扬声器进行输出。实现了汽车导航音和音乐音的同时输出。

如果应用域的音频数据是来自其他操作系统如Linux系统的音频数据，参见图8中的cluster Playback slot(仪表声音播放时隙)，管理域也可将该音频数据从声道数据流映射到slot上，如将双声道的音频数据中的声道数据流1映射到slot 1上，双声道的音频数据中的声道数据流2映射到slot 2上。将slot 1和slot 2分配到Endpoint 1中。Endpoint 1和Endpoint 2对应相同的扬声器，将Endpoint 1和Endpoint 2的声道数据流进行音频处理，以供此相同扬声器进行输出。

参见图8中的Local Playback(本地播放)，如果管理域本地存在待播放的音频，为节约资源，无需进行将音频数据从本地到虚拟音频后端的映射，将待播放音频分配至预先约定的音频节点如Endpoint 7即可。Endpoint 7和Endpoint2对应相同的扬声器，将Endpoint 7和Endpoint 2的声道数据流进行音频处理，以供此相同扬声器进行输出。

如此，基于Android音频架构和Linux音频构架实现了本申请的音频处理方法。可以理解，在实际应用中，应用域可安装Android操作系统或者其他操作系统比如Linux，以通过对Android应用或者Linux应用程序实现本申请的音频处理方法。

其中，在图8中，虚拟I2S流(Virtual I2S Stream)可视为从声道到slot的映射。Audio Hub为软件音频集线器。

本申请技术方案中，管理域可采用Android HAL架构来实现音频处理方法中的音频录制方案。如图9所示，以TDM 4slot为例，在麦克风录制应用域1请求录制的四声道音频时，将录制的录音数据流1映射到slot 1，录音数据流2映射到slot 2，录音数据流3映射到slot 3，录音数据流4映射到slot 4。将录音数据流1和录制数据流2分配至Endpoint 8，录音数据流3和录制数据流4分配至Endpoint 9，以供保存，以完成前述三种用途中的至少之一。待到有需要时，分配至Endpoint 8和Endpoint 9的录制音频流进行各自的音频处理后，通过各自对应的扬声器输出。

还以TDM 4slot为例，在麦克风录制应用域2请求录制的二声道音频时，将录制的录音数据流1映射到slot 1，录音数据流2映射到slot 2，录音数据流3映射到slot 3，录音数据流4映射到slot 4。将录音数据流1和录制数据流2分配至Endpoint 10，以供保存，以完成前述三种用途中的至少之一。待到有需要时，分配至Endpoint 10的录制音频流进行音频处理后，通过对应的扬声器输出。

基于Android(安卓)HAL架构，采用诸如Audio Hub等软件模块实现的方案为一种基于软件的管理实现的音频处理方法。这种软件实现方式，可实现音频数据和录音数据到音频节点的分配灵活性，还可实现音频节点中的数据流通过不同音频输出单元进行播放的播放灵活性。与相关技术中的硬件方式相比，实现了音频处理和音频播放的灵活性。

在实际应用中，如果汽车只有一个扬声器，那么利用本申请技术方案，可将不同应用域的音频数据通过同一扬声器进行输出，实现了各音频数据的正常输出，提升了用户的收听体验。

本申请技术方案中，由管理域的软件音频集线器来管理相关音频硬件设备如Codec(数字信号到模拟信号的转换或模拟信号到数字信号的转换)、音频输出单元和音频采集单元。与由硬件进行管理相比，由软件进行管理，可大大简化对每个应用域的音频播放流程，实现音频的高效播放。

由管理域进行软件上的音频处理，可减少对硬件开销的耗费，避免相关技术中增加硬件开销如增加硬件以及硬件之间的连接接口而导致的资源耗费问题，可大大节约成本。此外，相关技术方案，音频数据在被某个硬件设备处理后可能还被送回至该硬件进行其他处理，以实现对音频的更好播放，如此，便增加了时延。本申请技术方案中，由管理域进行软件上的音频处理，可大大缩短时延，实现音频数据的及时播放。

本申请还提供一种音频处理装置，如图10所示，所述装置包括：

获得单元1001，用于采用多核异构系统的核间通信机制，获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述多核异构系统中的管理域与所述多硬件域中的至少部分硬件域对应；

分配单元1002，用于将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；

处理单元1003，用于对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

在一些实施例中，每个音频数据包括至少一个声道数据流；所述分配单元1002，用于将每个音频数据包括的全部声道数据流分配到N个第一音频节点中的至少一个第一音频节点。

在一些实施例中，所述各第一音频节点中的至少一个第一音频节点对应一音频播放器；所述处理单元1003，用于：

对分配到对应于同一音频播放器的第一音频节点的各声道数据流进行音频处理；

基于对各音频播放器对应的各第一音频节点的声道数据流的音频处理结果，得到针对所述各音频数据的目标音频。

在一些实施例中，所述每个音频数据的各声道数据流由所述M个应用域的各应用域中的各第一虚拟音频驱动单元从各应用域中发送；所述多核异构系统中的管理域包括第二虚拟音频驱动单元；获得单元1001，用于通过所述第二虚拟音频驱动单元利用与每个音频数据对应的通道进行每个音频数据的全部声道数据流的接收，而获得M个应用域的各音频数据。

在一些实施例中，所述分配单元1002，用于基于所述M个应用域中的至少部分应用域的音频录制请求，将录制音频分配至第二音频节点，以将所述录制音频发送至所述至少部分应用域；其中，所述录制音频为音频录制请求所请求录制的音频；其中，所述音频录制请求基于所述核间通信机制而得到。

在一些实施例中，所述处理单元1003，用于：

对分配到各第一音频节点的声道数据流和第二音频节点的录制音频的录制数据流进行音频处理，得到目标音频。

在一些实施例中，所述至少部分应用域中的每个域对应有录制音频，所述录制音频包括至少一个录制数据流；所述分配单元1002，用于将每个录制音频的全部录制数据流分配至至少一个第二音频节点。

在一些实施例中，所述每个音频数据对应的通道的数量与所述每个音频数据包括的声道数据流的数量相同或不同。

需要说明的是，本申请实施例的音频处理装置，由于该音频处理装置解决问题的原理与前述的音频处理方法相似，因此，音频处理装置的实施过程及实施原理均可以参见前述方法的实施过程及实施原理描述，重复之处不再赘述。

本申请提供了一种芯片，包括如图10所示的音频处理装置。

本申请还提供了一种电子设备和一种可读存储介质。

图11示出了可以用来实施本申请的实施例的示例电子设备800的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图11所示，设备800包括计算单元801，其可以根据存储在只读存储器(ROM)802中的计算机程序或者从存储单元808加载到随机访问存储器(RAM)803中的计算机程序，来执行各种适当的动作和处理。在RAM 803中，还可存储设备800操作所需的各种程序和数据。计算单元801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(I/O)接口805也连接至总线804。

设备800中的多个部件连接至I/O接口805，包括：输入单元806，例如键盘、鼠标等；输出单元807，例如各种类型的显示器、扬声器等；存储单元808，例如磁盘、光盘等；以及通信单元809，例如网卡、调制解调器、无线通信收发机等。通信单元809允许设备800通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元801可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元801的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元801执行上文所描述的各个方法和处理，例如音频处理方法。例如，在一些实施例中，音频处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元808。在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元809而被载入和/或安装到设备800上。当计算机程序加载到RAM 803并由计算单元801执行时，可以执行上文描述的音频处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元801可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行音频处理方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本申请的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本申请的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (12)

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

采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述管理域与所述多硬件域中的至少部分硬件域对应；

将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；

对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

2.根据权利要求1所述的方法，其特征在于，每个音频数据包括至少一个声道数据流；

所述将各音频数据分配到所述管理域的N个第一音频节点，包括：

将每个音频数据包括的全部声道数据流分配到N个第一音频节点中的至少一个第一音频节点。

3.根据权利要求2所述的方法，其特征在于，所述对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，包括：

所述各第一音频节点中的至少一个第一音频节点对应一音频播放器；

对分配到对应于同一音频播放器的第一音频节点的各声道数据流进行音频处理；

基于对各音频播放器对应的各第一音频节点的声道数据流的音频处理结果，得到针对所述各音频数据的目标音频。

4.根据权利要求2或3所述的方法，其特征在于，所述每个音频数据的各声道数据流由所述M个应用域的各应用域中的各第一虚拟音频驱动单元从各应用域中发送；所述多核异构系统中的管理域包括第二虚拟音频驱动单元；

其中，所述由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据，包括：

所述管理域通过所述第二虚拟音频驱动单元利用与每个音频数据对应的通道进行每个音频数据的全部声道数据流的接收，而获得M个应用域的各音频数据。

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

基于所述M个应用域中的至少部分应用域的音频录制请求，将录制音频分配至第二音频节点，以将所述录制音频发送至所述至少部分应用域；其中，所述录制音频为音频录制请求所请求录制的音频；

其中，所述音频录制请求基于所述核间通信机制而得到。

6.根据权利要求5所述的方法，其特征在于，所述对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，包括：

对分配到各第一音频节点的声道数据流和第二音频节点的录制音频的录制数据流进行音频处理，得到目标音频。

7.根据权利要求5所述的方法，其特征在于，所述至少部分应用域中的每个域对应有录制音频，所述录制音频包括至少一个录制数据流；

所述将录制音频分配至第二音频节点，包括：

将每个录制音频的全部录制数据流分配至至少一个第二音频节点。

8.根据权利要求4所述的方法，其特征在于，所述每个音频数据对应的通道的数量与所述每个音频数据包括的声道数据流的数量相同或不同。

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

获得单元，用于采用多核异构系统的核间通信机制，由多核异构系统中的管理域获得所述多核异构系统中的M个应用域的各音频数据；其中，所述多核异构系统包括多硬件域；所述多硬件域中的各硬件域由所述多核异构系统中多个处理器核与各处理核连接的硬件资源构成，所述各硬件域之间互相隔离；所述M个应用域和所述管理域与所述多硬件域中的至少部分硬件域对应；

分配单元，用于将各音频数据分配到所述管理域的N个第一音频节点；其中，各第一音频节点包括至少一个音频数据的至少部分声道数据流；M和N均为大于或等于1的正整数；

处理单元，用于对分配到各第一音频节点的声道数据流进行音频处理，得到目标音频，所述目标音频用于供播放。

10.一种芯片，其特征在于，所述芯片包括权利要求9所示的音频处理装置。

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

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-8中任一项所述的方法。

12.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行根据权利要求1-8中任一项所述的方法。

Images