CN120108406A

CN120108406A - 音频处理方法、车载音频设备、电子设备及车辆

Info

Publication number: CN120108406A
Application number: CN202311645806.1A
Authority: CN
Inventors: 白帆; 白金印; 马翔宇; 陈宇飞
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-11-30
Filing date: 2023-11-30
Publication date: 2025-06-06
Anticipated expiration: 2043-11-30
Also published as: CN120108406B

Abstract

本申请提供了一种音频处理方法、车载音频设备、电子设备及车辆，涉及音频处理技术领域。该方法包括：接收多个应用程序生成的音频数据；将音频数据处理为子音频数据；通过为子音频数据创建的对应数量的编码器，对子音频数据进行编码处理，得到编码音频；通过预设的传输通道，将编码音频发送至车载音频设备；编码音频用于触发车载音频设备通过为编码音频创建的解码器，对编码音频进行解码处理，得到解码音频；解码音频用于车载音频设备根据播放策略播放解码音频。该音频处理方法能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了用户的驾乘体验。

Description

音频处理方法、车载音频设备、电子设备及车辆

技术领域

本申请涉及音频处理技术领域，尤其涉及一种音频处理方法、车载音频设备、电子设备及车辆。

背景技术

随着电子科技的快速发展，电子设备(如手机)与车载信息系统(简称车机)之间的交互场景越来越丰富。目前，已经有多种应用程序支持手机与车机之间的服务访问、音视频传输及播放等操作。

通常情况下，在音频传输及播放的场景中，手机和车机处于连接状态，手机对不同类型的音频进行混音处理后发送给车机。车机针对经过混音处理后的音频，只能进行统一播放、调整等操作，导致手机与车机之间很多用于提升用户体验的优化场景无法实现，降低了用户的驾乘体验。

发明内容

本申请提供了一种音频处理方法、车载音频设备、电子设备及车辆，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了用户的驾乘体验。

第一方面，本申请提供了一种音频处理方法，应用于电子设备的应用程序框架层，该电子设备与车载音频设备连接，该方法包括：接收多个应用程序生成的音频数据；将音频数据处理为子音频数据；通过为子音频数据创建的对应数量的编码器，对子音频数据进行编码处理，得到编码音频；通过预设的传输通道，将编码音频发送至车载音频设备；编码音频用于触发车载音频设备通过为编码音频创建的解码器，对编码音频进行解码处理，得到解码音频；解码音频用于车载音频设备根据播放策略播放解码音频。

可选地，音频数据可以包括媒体音频数据、导航音频数据、通话音频数据、通知音频数据、警示音频数据、提示音频数据以及铃声音频数据中的至少一个。

可选地，子音频数据可以包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个。

其中，混音子音频数据是对除媒体子音频数据、导航子音频数据以及通话子音频数据外的其他子音频数据进行混音处理得到的。

可选地，其他子音频数据可以包括通知子音频数据、警示子音频数据、提示子音频数据以及铃声子音频数据中的至少一个。

可选地，播放策略可以包括独立调整解码音频对应的播放音量，和/或通过指定扬声器播放与指定扬声器对应的解码音频。

可选地，指定扬声器可以包括驾驶座扬声器，与指定扬声器对应的解码音频的音频类型为导航音频类型。

本申请实施例提供的音频处理方法，由于子音频数据所包含的数据是一个个单独的音轨数据(或者说子音频数据包含的每个数据都是不同类型的音频数据)，对这些单独的音轨数据分别编码后发送给车载音频设备，车载音频设备通过为编码音频创建的解码器，对编码音频进行解码处理后，得到解码音频也是一个个单独的音频(或者说得到的每个解码音频都是不同类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此，本申请提供的音频处理方法，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

结合第一方面，在第一方面的某些实现方式中，本申请实施例提供的音频处理方法还包括：获取子音频数据的音频类型；创建与子音频数据的音频类型相匹配的编码器。

其中，媒体子音频数据的音频类型为媒体音频类型，导航子音频数据的音频类型为导航音频类型，通话子音频数据的音频类型为通话音频类型，混音子音频数据的音频类型为混音音频类型。

在该实现方式中，为不同音频类型的子音频数据创建各自对应的编码器，使一个类型的编码器只需对一种音频类型的子音频数据进行编码处理，能够提升编码效率，有效避免发生编码卡顿现象，从而使最终在车载音频设备播放的音频更流畅。

结合第一方面，在第一方面的某些实现方式中，电子设备还包括虚拟硬件抽象层，本申请实施例提供的音频处理方法还包括：通过虚拟硬件抽象层创建的音频路由，将子音频数据转发至与子音频数据相匹配的编码器中。

可选地，创建的音频路由与该子音频数据的音频类型相匹配。

在该实现方式中，为不同音频类型的子音频数据创建各自对应的音频路由，使一个类型的音频路由只需对一种音频类型的子音频数据进行转发处理，不仅有利于后续设备虚拟化服务快速区分其接收到的子音频数据的音频类型，还能够提升转发效率。

结合第一方面，在第一方面的某些实现方式中，子音频数据为通话子音频数据时，本申请实施例提供的音频处理方法还包括：通过虚拟硬件抽象层中的通话通道，将通话子音频数据传输至与通话子音频数据相匹配的编码器中。

在该实现方式中，为通话音频数据建立单独的通话通道以及通话编码器，可以保证通话音频数据的传输过程和编码过程不受干扰，有效提高了通话质量。

结合第一方面，在第一方面的某些实现方式中，传输通道可以包括第一传输通道和第二传输通道，第一传输通道用于传输非通话音频子数据对应的编码音频，第二传输通道用于传输通话子音频数据对应的编码音频。

其中，非通话子音频数据可以包括媒体子音频数据、导航子音频数据以及混音子音频数据。

在该实现方式中，为通话子音频数据建立单独的传输通道，可以保证通话子音频数据对应的编码音频在传输过程中不受干扰，有效提高了通话质量。

结合第一方面，在第一方面的某些实现方式中，将音频数据处理为子音频数据，包括：根据音频数据携带的不同的音频类型标识，从音频数据中识别出媒体子音频数据、导航子音频数据、通话子音频数据以及其他子音频数据中的至少两种；若识别出其他子音频数据，对其他子音频数据进行混音处理，得到混音子音频数据。

在该实现方式中，通过音频类型标识识别出不同音频类型的子音频数据，从而对不同音频类型的子音频数据做出不同的处理，以便于得到一个个单独的音轨数据，从而有利于后续车载音频设备对不同音频类型的子音频数据对应的音频进行独立调整、播放。

结合第一方面，在第一方面的某些实现方式中，本申请实施例提供的音频处理方法，在接收多个应用程序生成的音频数据之前，还包括：接收音频分流指令。

其中，音频分流指令用于指示将音频数据处理为子音频数据。

可以理解为，音频分流指令用于指示音频框架对媒体音频数据、导航音频数据以及通话音频数据不进行混音处理，对其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)进行混音处理。

在该实现方式中，音频分流指令用于指示音频框架对不同音频类型的音频数据做出不同的处理，以便于得到一个个单独的音轨数据，从而有利于后续车载音频设备对不同音频类型的子音频数据对应的音频进行独立调整、播放。

结合第一方面，在第一方面的某些实现方式中，本申请实施例提供的音频处理方法，在接收多个应用程序生成的音频数据之前，还包括：接收跨设备音频流转能力启动指令。

其中，跨设备音频流转能力启动指令用于，指示设备虚拟化服务为不同类型的子音频数据创建对应的编码器，以及对子音频数据进行编码处理，得到编码音频。

在该实现方式中，通过跨设备音频流转能力启动指令指示设备虚拟化服务为不同音频类型的子音频数据创建各自对应的编码器，使一个类型的编码器只需对一种音频类型的子音频数据进行编码处理，能够提升编码效率，有效避免发生编码卡顿现象，从而使最终在车载音频设备播放的音频更流畅。

结合第一方面，在第一方面的某些实现方式中，本申请实施例提供的音频处理方法，在接收多个应用程序生成的音频数据之前，还包括：响应于针对多个应用程序的输入操作，生成音频数据。

其中，应用程序可以包括媒体类应用程序、导航类应用程序、通话类应用程序购物类应用程序、工具类应用程序、其他应用程序等。

可选地，媒体类应用程序可以包括但不限于，各种音乐应用、各种视频应用、各种短视频应用、各种社交应用、各种游戏应用、各种资讯应用。

导航类应用程序可以包括但不限于，各种地图应用、各种出行应用、各种打车应用、各种定位应用。

通话类应用程序可以包括但不限于，电话应用、各种网络电话应用。

购物类应用程序可以包括各种购物应用。

工具类应用程序可以包括但不限于，各种浏览器应用、各种学习应用、各种天气应用、各种办公应用、各种咨询应用。

其他应用程序是指除媒体类应用程序、导航类应用程序、通话类应用程序、购物类应用程序以及工具类应用程序外的应用程序。例如，其他应用程序可以包括通知应用、短信息应用、能够在驾驶过程中进行安全提示的应用等。

在该实现方式中，不同应用可以生成不同类型的音频数据，为后续将音频数据处理为一个个单独的音轨数据提供了基础。

结合第一方面，在第一方面的某些实现方式中，本申请实施例提供的音频处理方法还包括：接收电子设备与车载音频设备断开连接的指令，销毁编码器，并指示虚拟硬件抽象层销毁音频路由。

在该实现方式中，及时销毁创建的编码器和音频路由，有效避免编码器和音频路由长期占用系统资源，提高了资源利用率，提升了电子设备的性能。

第二方面，本申请提供了一种音频处理方法，应用于车载音频设备的应用程序框架层，车载音频设备与电子设备连接，该方法包括：接收通过预设的传输通道发送的编码音频；通过为编码音频创建的解码器，对编码音频进行解码处理，得到解码音频；根据播放策略播放解码音频；播放策略包括独立调整解码音频对应的播放音量，和/或通过指定扬声器播放与指定扬声器对应的解码音频。

其中，编码音频是电子设备的应用程序框架层通过为子音频数据创建的编码器，对子音频数据进行编码处理得到的；子音频数据是电子设备的应用程序框架层对音频数据进行处理得到的；音频数据是电子设备中的多个应用程序生成的。

子音频数据可以包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个；混音子音频数据是电子设备的应用程序框架层对除媒体子音频数据、导航子音频数据以及通话子音频数据外的其他子音频数据进行混音处理得到的。

本申请实施例提供的音频处理方法中，由于车载音频设备接收到的不是混音数据，而是一个个单独的编码音频，对编码音频进行解码处理后，得到的解码音频也是一个个单独的音频(或者说，解码得到的每个解码音频都是不同音频类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此，本申请提供的音频处理方法，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

结合第二方面，在第二方面的某些实现方式中，本申请实施例提供的音频处理方法还包括：获取编码音频对应的音频类型；创建与编码音频对应的音频类型相匹配的解码器。

可选地，媒体子音频数据的编码音频对应的音频类型为媒体音频类型，导航子音频数据的编码音频对应的音频类型为导航音频类型，通话子音频数据的编码音频对应的音频类型为通话音频类型，混音子音频数据的编码音频对应的音频类型为混音音频类型。

在该实现方式中，为不同音频类型的编码音频创建各自对应的解码器，使一个类型的解码器只需对一种音频类型的编码音频进行解码处理，有效避免了音频卡顿现象的发生，从而提升了最终播放的音频的流畅性，进而提升了用户体验。

第三方面，本申请提供一种电子设备，该电子设备包括：一个或多个处理器；一个或多个存储器；安装有多个应用程序的模块；存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得电子设备执行上述第一方面及其任意可能的实现方式中的方法。

第四方面，本申请提供一种车载音频设备，该车载音频设备包括：一个或多个处理器；一个或多个存储器；安装有多个应用程序的模块；存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得车载音频设备执行上述第二方面及其任意可能的实现方式中的方法。

第五方面，本申请提供一种车辆，该车辆包括：一个或多个处理器；一个或多个存储器；存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得该车辆执行上述第二方面及其任意可能的实现方式中的方法。

第六方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法，或执行第二方面及其任意可能的实现方式中的方法。

可选的，芯片还包括存储器，存储器与处理器通过电路或电线连接。

可选的，芯片还包括通信接口。

第七方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得该处理器执行第一方面及其任意可能的实现方式中的方法，或使得该处理器执行第二方面及其任意可能的实现方式中的方法。

第八方面，本申请提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得该电子设备执行第一方面及其任意可能的实现方式中的方法。或，当计算机程序代码在车载音频设备上运行时，使得该车载音频设备执行第二方面及其任意可能的实现方式中的方法。

上述第二方面、第三方面、第四方面、第五方面、第六方面、第七方面以及第八方面所获得的技术效果可参考上述第一方面和第二方面中对应的技术手段获得的技术效果，在这里不再赘述。

附图说明

图1为本申请实施例示出的音频处理方法的一种应用场景示意图；

图2为本申请实施例示出的音频处理方法的另一种应用场景示意图；

图3为本申请实施例示出的一种显示界面示意图；

图4为本申请一示例性实施例示出的电子设备的软件结构框图；

图5为本申请一示例性实施例示出的系统架构框图；

图6为本申请实施例示出的一种音频处理方法的流程示意图；

图7为本申请实施例示出的另一种音频处理方法的流程示意图；

图8为本申请实施例示出的另一种系统结构框图；

图9为本申请实施例示出的又一种音频处理方法的流程示意图；

图10为本申请实施例示出的再一种音频处理方法的流程示意图；

图11为本申请一示例性实施例示出的又一种电子设备的软件结构框图；

图12为本申请一示例性实施例示出的合包处理示意图；

图13为本申请一示例性实施例示出的发送周期示意图；

图14为本申请一示例性实施例示出的合包数据示意图；

图15为本申请一示例性实施例示出的另一种系统架构框图；

图16为本申请一示例性实施例示出的分包处理示意图；

图17为本申请实施例示出的一种音频传输方法的流程示意图；

图18为本申请实施例示出的另一种音频传输方法的流程示意图；

图19为本申请实施例示出的又一种音频传输方法的流程示意图；

图20为本申请实施例示出的又一种音频传输方法的流程示意图；

图21为本申请一示例性实施例示出的电子设备的硬件结构示意图；

图22为本申请实施例提供的一种芯片的结构示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

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

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

为了更好地理解本申请实施例提供的音频处理方法以及音频传输方法，下文首先对本申请实施例中涉及的部分术语进行解释说明，以便于本领域技术人员理解。

1.车载信息系统

车载信息系统也称为汽车信息系统，本申请实施例中简称为车机。

车载信息系统是一种能使驾驶员在驾驶过程中，及时了解车辆运行信息和外界信息的装置。

2.输入缓冲区

本申请实施例中也称为inBuffer，其可以看作是一块临时存储数据的内存区域。

在本申请实施例中，一个编码器对应一个inBuffer，每个inBuffer用于接收并存储其对应的编码器发送的编码音频。

以上是对本申请实施例所涉及的名词的简单介绍，以下不再赘述。

在电子设备(如手机)与车机之间的交互场景中，譬如在音频传输及播放的场景中，手机和车机处于连接状态(或称互联状态)。不同类型的音频数据(如媒体音频数据、导航音频数据、通话音频数据、通知音频数据等)将要从手机发送至车机时，手机会对这些不同类型的音频数据进行混音处理，得到混音数据，再将该混音数据发送给车机。

由于混音处理是个不可逆的过程，车机接收到混音数据后，无法对混音数据进行拆分，即无法从混音数据中拆分出各个类型的音频数据。例如，车机无法从混音数据中拆分出单独的媒体音频数据、导航音频数据、通话音频数据、通知音频数据等。

基于上述原因，车机只能对混音数据进行统一播放、调整等操作，无法对各个类型的音频数据进行单独播放、调整等操作，导致手机与车机之间很多用于提升用户体验的优化场景无法实现，降低了用户的驾乘体验。其中，用于提升用户体验的优化场景包括但不限于，车机分别控制不同类型的音频数据对应的播放音量大小，车机控制导航音频数据在驾驶座扬声器单独播放、车机控制导航音频数据在驾驶座扬声器和副驾驶座扬声器播放等。

有鉴于此，本申请实施例提供了一种音频处理方法，应用于电子设备的应用程序框架层，该电子设备与车载音频设备连接，电子设备的应用程序框架层接收多个应用程序生成的音频数据，将音频数据处理为子音频数据，子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个，通过为子音频数据创建的对应数量的编码器，对各个子音频数据进行编码处理，得到编码音频，通过预设的传输通道，将编码音频发送至车载音频设备。

由于子音频数据所包含的数据是一个个单独的音轨数据(或者说子音频数据包含的每个数据都是不同类型的音频数据)，对这些单独的音轨数据分别编码后发送给车载音频设备，车载音频设备通过为编码音频创建的解码器，对编码音频进行解码处理后，得到解码音频也是一个个单独的音频(或者说得到的每个解码音频都是不同类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此，本申请提供的音频处理方法，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

下面结合附图，对本申请实施例提供的音频处理方法的应用场景进行描述。

值得说明的是，在本申请的一些实施例中，电子设备可以为手机、智慧屏、平板电脑、可穿戴设备(如智能手表、智能眼镜、智能手环、智能项圈等)、电视、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personaldigital assistant，PDA)、投影仪等等，或者可以为其他能够进行音频处理的设备或装置，对于电子设备的具体类型，本申请实施例不作任何限制。

请参阅图1，图1为本申请实施例示出的音频处理方法的一种应用场景示意图。如图1所示，该应用场景中包括电子设备100和车辆200，应理解，本申请实施例中以电子设备100为手机为例进行说明。

车辆200可以是承载人和/或物，且通过发送机、电池等动力系统移动的任何类型的车辆，包括但不限于汽车、轿车、卡车、巴士、电动车、摩托车、房车、火车、动车组列车、高速动车组旅客列车等等。

在一种可能地实现方式中，车辆200可以是通过驾驶员驾驶的车辆。可选地，在另一种可能地实现方式中，车辆200也可以是具有一定自动驾驶能力的车辆。

车辆200可以包括车载音频设备210。该车载音频设备210和电子设备100之间可以通过通信连接，以实现车载音频设备210和电子设备100之间的信息交互。

其中，通信连接可以包括有线通信连接和短距离无线通信连接。有线通信连接可以包括通用串行总线(Universal Serial Bus，USB)连接，短距离无线通信连接可以包括但不限于：蓝牙连接、无线保真(WIreless Fidelity，Wi-Fi)连接、Wi-Fi点对点(Peer-to-Peer，P2P)连接、紫蜂网络(Zigbee)连接，以及近距离无线通信技术(Near FieldCommunication，NFC)连接等。

在一种可能地实现方式中，该车载音频设备210可以通过软件形式被承载在车辆200的硬件设备中，该硬件设备可用于访问、存取、播放电子设备100的应用程序中的内容。在另一种可能地实现方式中，该车载音频设备210也可以被实现为能够与车辆200连接的其他独立的硬件设备。

上面图1所对应的实施例，主要以车辆200外部的角度对音频处理方法的应用场景进行了展示，下面以车辆200内部的角度展示音频处理方法的应用场景。

请参阅图2，图2为本申请实施例示出的音频处理方法的另一种应用场景示意图。如图2所示，当车载音频设备210被实现为能够与车辆200连接的其他独立的硬件设备时，车载音频设备210可以设置在车辆200的方向盘右侧。此处仅为示例性说明，车载音频设备210也可以设置在驾驶员前方、副驾驶前方等，对此不做限定。

示例性地，在驾驶员或乘客想要将电子设备100的应用程序中的内容传输给车载音频设备210，或者，想要利用车载音频设备210对电子设备100的应用程序中的内容，进行访问、存取、播放等操作之前，需要先建立车载音频设备210和电子设备100之间的通信连接。

例如，可以采用USB线建立车载音频设备210和电子设备100之间的有线通信连接。应理解，无论是首次建立有线通信连接，还是非首次建立有线通信连接，均是将USB线扁平接口的一端接入车载音频设备210，将USB线微型接口的一端接入电子设备100。之后，根据车载音频设备210的显示界面，和/或电子设备100的显示界面上弹出的用于建立有线通信连接的提示信息进行操作，从而建立起车载音频设备210和电子设备100之间的有线通信连接。

又例如，可以采用蓝牙建立车载音频设备210和电子设备100之间的短距离无线通信连接。示例性地，首次采用蓝牙建立车载音频设备210和电子设备100之间的短距离无线通信连接时，需要驾驶员或乘客手动为车载音频设备210和电子设备100做一个配对连接的操作。例如，驾驶员或乘客可以对车载音频设备210和电子设备100进行开启蓝牙操作，使车载音频设备210开启车载蓝牙，电子设备100开启蓝牙，且确保车载音频设备210的车载蓝牙和电子设备100的蓝牙均处于可发现状态。

之后，在电子设备100显示的蓝牙界面点击搜索设备，使电子设备100可以搜索到车载蓝牙。选中电子设备100显示的车载蓝牙，依次进行点击车载蓝牙、蓝牙设置、配对操作，此时电子设备100的显示界面会弹出输入配对码的提示框，在该提示框中输入配对码并点击连接，同时在车载音频设备210显示的蓝牙界面点击配对。若配对码输入正确，会在车载音频设备210显示的蓝牙界面中显示已连接，从而建立起车载音频设备210和电子设备100之间的短距离无线通信连接。

值得说明的是，非首次采用蓝牙建立车载音频设备210和电子设备100之间的短距离无线通信连接时，若车载音频设备210的车载蓝牙和电子设备100的蓝牙均处于开启状态，且车载音频设备210和电子设备100之间的距离满足预设连接阈值，则车载音频设备210的车载蓝牙和电子设备100的蓝牙自动建立短距离无线通信连接。

可以理解的是，上述“预设连接阈值”是指车载音频设备210和电子设备100之间进行蓝牙通信的最大传输距离，譬如8米之内、10米之内、15米之内等等。

建立起车载音频设备210和电子设备100之间的通信连接后，便可将电子设备100的应用程序中的内容传输给车载音频设备，还可将传输的内容显示在车载音频设备210的显示界面中。或者，利用车载音频设备210对电子设备100的应用程序中的内容，进行访问、存取、播放等操作，还可将操作结果显示在车载音频设备210的显示界面中。

下面结合附图，对车载音频设备210的显示界面进行描述。可以理解的是，车载音频设备210和电子设备100在不建立通信连接的情况下，车载音频设备210的显示界面也可以独立显示车辆200的相关信息。该相关信息包括但不限于，导航信息、驾驶信息、音频信息、视频信息、通话信息、电量信息、时间信息、音量信息等。

本申请实施例中，以车载音频设备210和电子设备100在建立通信连接的情况下，车载音频设备210的显示界面所显示的内容为例进行描述。请参阅图3，图3为本申请实施例示出的一种显示界面示意图。例如，电子设备100中的媒体类应用程序(如音乐应用程序)将音乐发送至车载音频设备210，车载音频设备210的显示界面显示该音乐的相关内容，如图3所示，在车载音频设备210的显示界面显示歌曲名称、歌手名字、歌曲所属分类(如我喜欢、本地歌曲、行车电台等类型)，还可以显示上一曲、暂停、下一曲等控件。同时，通过车辆200的扬声器播放音乐，实现通过车辆200的扬声器播放电子设备100的音乐应用程序中的音乐的交互场景。

又例如，电子设备100中的导航类应用程序(如导航应用程序)将导航数据发送至车载音频设备210，车载音频设备210的显示界面显示该导航数据的相关内容，如图3所示，在车载音频设备210的显示界面显示路线信息，如“50km左转，进入XX路”，还可以显示驾驶时长(Time)、距目的地距离(Distance)、到达时间(Arrival)、“结束导航”控件等。同时，通过车辆200的扬声器播放导航音频，实现通过车辆200的扬声器播放电子设备100的导航应用程序中的导航声音的交互场景。

再例如，电子设备100中的通话类应用程序(如电话应用程序)将通话数据发送至车载音频设备210，车载音频设备210的显示界面显示控制通话数据的相关控件，如图3所示，在车载音频设备210的显示界面显示“接听”、“挂断”、“静音”等控件，根据驾驶员或乘客针对不同控件的点击操作，车辆200采取不同的响应方式。譬如当驾驶员或乘客点击“接听”控件时，通过车辆200的扬声器播放通话声音，同时，驾驶员或乘客可以通过车辆200的麦克风输入自己的声音，实现通过车辆200的扬声器和麦克风接听电子设备100的电话的交互场景。

如图3所示，车载音频设备210的显示界面还可以显示电量信息、时间信息、闹钟信息、主菜单信息、耳机信息等，此处仅为示例性说明，以实际显示为准，对此不做限定。

相关技术中，电子设备在将音乐、导航数据、通话数据等不同类型的音频数据发送至车载音频设备时，电子设备会对这些不同类型的音频数据进行混音处理，得到混音数据，再将该混音数据发送给车载音频设备。由于混音处理是个不可逆的过程，车载音频设备接收到混音数据后，无法对混音数据进行拆分，即无法从混音数据中单独拆分出音乐、导航数据以及通话数据。

因此，车载音频设备只能对混音数据进行统一播放、调整等操作，无法单独调整各个类型的音频数据。譬如只能将混音数据对应的播放音量统一增大或减小，这样导致音乐、导航声音以及通话声音的音量统一增大或减小，无法独立调整音乐、导航声音以及通话声音各自对应的音量大小。又譬如只能将混音数据在统一的扬声器播放，无法指定不同的扬声器播放不同的音频数据。

本申请实施例提供的音频处理方法中，电子设备将多个应用程序生成的音频数据处理为子音频数据，子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个，通过为子音频数据创建的对应数量的编码器，对各个子音频数据进行编码处理，得到编码音频，通过预设的传输通道，将编码音频发送至车载音频设备。

下面结合软件结构对本申请实施例提供的音频处理方法进行描述。请参阅图4，图4为本申请一示例性实施例示出的电子设备的软件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，以电子设备100是Android系统为例进行说明，Android系统分为三层，从上至下分别为应用程序层，应用程序框架层，以及虚拟硬件抽象层。

应用程序层可以包括一系列应用程序包。在本申请实施例中，应用程序层可以包括媒体类应用程序、导航类应用程序、通话类应用程序、购物类应用程序、工具类应用程序、其他应用程序等。

其中，媒体类应用程序可以包括但不限于，各种音乐应用、各种视频应用、各种短视频应用、各种社交应用、各种游戏应用、各种资讯应用。

购物类应用程序可以包括各种购物应用。

值得说明的是，在本申请实施例中，无论是哪种应用程序，均可以在使用过程中生成音频数据。

如图4所示，应用程序包可以包括媒体应用、导航应用、其他应用以及通话应用。其中，媒体应用可以包括音乐应用、视频应用、短视频应用；导航应用可以包括地图应用、出行应用、定位应用；其他应用可以包括通知应用、短信息应用；通话应用可以包括电话应用。

应理解，不同应用可以生成不同类型的音频数据，例如，媒体应用可以生成媒体音频数据，导航应用可以生成导航音频数据，通话应用可以生成通话音频数据，其他应用可以生成通知音频数据、警示音频数据、铃声音频数据等。这些不同类型的音频数据都将传输至应用程序框架层的音频框架中，依次经过音频框架、虚拟硬件抽象层以及设备虚拟化服务的处理后，最终发送给车载音频设备。

可选地，应用程序层还可以包括车机应用。该车机应用内置在电子设备的应用程序层中，当检测到电子设备和车载音频设备建立通信连接时，车机应用向应用程序框架层的音频框架发送音频分流指令，以及向应用程序框架层的设备虚拟化服务发送跨设备音频流转能力启动指令。

其中，音频分流指令用于指示音频框架将多个应用程序生成的音频数据处理为子音频数据。可以理解为，音频分流指令用于指示音频框架对媒体音频数据、导航音频数据以及通话音频数据不进行混音处理，对其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)进行混音处理。

跨设备音频流转能力启动指令用于，指示设备虚拟化服务为不同类型的子音频数据创建对应的编码器，以及对子音频数据进行编码处理，得到编码音频。

可选地，在一种可能地实现方式中，该车机应用没有对应的应用显示界面，且对用户不可见。

应用程序框架层可以包括音频框架和设备虚拟化服务。下面先对音频框架进行介绍。

音频框架用于接收车机应用发送的音频分流指令，以及接收应用程序层的各个应用发送的不同类型的音频数据。应理解，音频分流指令是车机应用在感知到电子设备和车载音频设备建立通信连接时，立刻向音频框架发送的。因此，对于音频框架来说，其先接收到车机应用发送的音频分流指令，之后根据用户对各个应用的使用情况，接收到应用程序层的各个应用发送的不同类型的音频数据。

可选地，在一种可能地实现方式中，当音频框架接收到车机应用发送的音频分流指令后，对接收到的媒体音频数据、导航音频数据、通话音频数据、以及其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)均不再进行混音处理。

可选地，在另一种可能地实现方式中，当音频框架接收到车机应用发送的音频分流指令后，对接收到的媒体音频数据、导航音频数据以及通话音频数据不再进行混音处理，而对接收到的其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)进行混音处理。

音频框架还用于识别各个音频数据的音频类型。音频类型可以包括媒体音频类型、导航音频类型、通话音频类型以及其他音频类型。其中，其他音频类型可以包括通知音频类型、警示音频类型、铃声音频类型等。

通常情况下，电子设备的系统会对应用程序层的各个应用所生成的音频数据进行标识，音频框架根据各个音频数据的音频类型标识可以识别出各个音频数据的音频类型。

例如，系统对音乐应用生成的音频数据标识“媒体(media)-音乐(music)”信息，音频框架在接收到该音频数据时，识别出音频数据中的音频类型标识为“media-music”，确定该音频数据的音频类型为媒体音频类型。

又例如，系统对导航应用生成的音频数据标识“导航(navigation)”信息，音频框架在接收到该音频数据时，识别出音频数据中的音频类型标识为“navigation”，确定该音频数据的音频类型为导航音频类型。

可选地，在一种可能地实现方式中，预先在音频框架中设置应用白名单，该应用白名单中可以记录导航类应用程序的包名。音频框架接收到音频数据时，确定发送该音频数据的应用程序的包名；若检测到该包名在应用白名单中，则确定该音频数据的音频类型为导航音频类型。这种实现方式中，可在系统未对导航类应用程序生成的音频数据进行标识的情况下，利用音频框架中的应用白名单，识别出该音频数据的音频类型。

音频框架还用于在识别出各个音频数据的音频类型后，将多个应用程序生成的音频数据处理为子音频数据。子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个。

其中，混音子音频数据是音频框架对除媒体子音频数据、导航子音频数据以及通话子音频数据外的其他子音频数据进行混音处理得到的。

例如，多个应用程序生成的音频数据可以包括媒体音频数据、导航音频数据、通话音频数据、通知音频数据、警示音频数据、铃声音频数据等。此处仅为示例性说明，实际生成的音频数据的数量与类型，与用户所使用的应用程序有关，对此不做限定。

音频框架识别出媒体音频数据的音频类型为媒体音频类型，导航音频数据的音频类型为导航音频类型，通话音频数据的音频类型为通话音频类型，通知音频数据、警示音频数据以及铃声音频数据的音频类型均为其他音频类型。

音频框架对音频类型为媒体音频类型、导航音频类型以及通话音频类型的音频数据不进行混音处理。在一种可能地实现方式中，音频框架在确定出媒体音频数据、导航音频数据以及通话音频数据的音频类型后，直接将媒体音频数据、导航音频数据以及通话音频数据发送至虚拟硬件抽象层。

另一种可能地实现方式中，音频框架在确定出媒体音频数据、导航音频数据以及通话音频数据的音频类型后，将媒体音频数据确定为媒体子音频数据，将导航音频数据确定为导航子音频数据，将通话音频数据确定为通话子音频数据，之后，将媒体子音频数据、导航子音频数据以及通话子音频数据发送至虚拟硬件抽象层。

音频框架对音频类型为其他音频类型的音频数据进行混音处理。示例性地，音频框架对通知音频数据、警示音频数据以及铃声音频数据进行混音处理，得到混音子音频数据，之后，将混音子音频数据发送至虚拟硬件抽象层。

虚拟硬件抽象层为子音频数据创建对应数量的音频路由，或者说，虚拟硬件抽象层为每种音频类型的子音频数据创建对应的音频路由，使得创建出来的音频路由与各个子音频数据的音频类型相匹配。

虚拟硬件抽象层创建的音频路由用于，将与该音频路由对应的子音频数据，转发至与该子音频数据相匹配的编码器中。该编码器由应用程序框架层中的设备虚拟化服务创建，后文进行详细描述。

相较于相关技术中，通过一个音频路由转发混音数据(手机对不同类型的音频进行混音处理后得到的数据)，本实现方式中，为不同音频类型的子音频数据创建各自对应的音频路由，使一个类型的音频路由只需对一种音频类型的子音频数据进行转发处理，不仅有利于设备虚拟化服务快速区分其接收到的子音频数据的音频类型，还能够提升转发效率。

可选地，在一种可能地实现方式中，若音频框架对接收到的音频数据均未做混音处理，而是将媒体音频数据确定为媒体子音频数据，导航音频数据确定为导航子音频数据，通话音频数据确定为通话子音频数据，通知音频数据确定为通知子音频数据，警示音频数据确定为警示子音频数据，铃声音频数据确定为铃声子音频数据，则虚拟硬件抽象层为每种子音频数据创建其对应的音频路由。

例如，虚拟硬件抽象层为媒体子音频数据创建第一音频路由，为导航子音频数据创建第二音频路由，为通话子音频数据创建第三音频路由，为通知子音频数据创建第四音频路由，为警示子音频数据创建第五音频路由，为铃声子音频数据创建第六音频路由。

可选地，在另一种可能地实现方式中，若音频框架对音频类型为其他音频类型的音频数据进行了混音处理，则虚拟硬件抽象层为媒体子音频数据创建第一音频路由，为导航子音频数据创建第二音频路由，为混音子音频数据创建第三音频路由，为通话子音频数据创建通话音频路由。

可选地，虚拟硬件抽象层在创建音频路由时，根据子音频数据的音频类型对创建的音频路由进行标识，这样有利于区分创建好的各个音频路由，也有利于后续音频框架根据标识将与各个音频路由匹配的子音频数据快速转发至各个音频路由，还有利于设备虚拟化服务快速区分其接收到的子音频数据的音频类型(可以通俗理解为，从某个音频路由转发出去的子音频数据，该子音频数据的音频类型可根据该音频路由的标识快速确定)。

应理解，对创建的音频路由进行标识的方式不做限定。示例性地，可以通过不同的音频路由名称进行标识，例如，媒体音频路由、导航音频路由、混音音频路由、通话音频路由等。又例如，第一音频路由、第二音频路由、第三音频路由、第四音频路由等。再例如，路由1、路由2、路由3等。

可选地，还可以通过音频框架为不同的音频路由设置不同的音频类型。例如，通过音频框架将第一音频路由对应的音频类型设置为媒体音频类型，将第二音频路由对应的音频类型设置为导航音频类型，将第三音频路由对应的音频类型设置为混音音频类型，将通话音频路由对应的音频类型设置为通话音频类型等。

可选地，在一种可能地实现方式中，虚拟硬件抽象层创建音频路由，可以是预先针对每个音频类型的子音频数据创建好对应的音频路由，并长期存储在虚拟硬件抽象层中，便于后期快速通过创建好的音频路由转发各个子音频数据至编码器中。

可选地，在另一种可能地实现方式中，以电子设备与车载音频设备建立连接开始、电子设备与车载音频设备断开连接结束为一个周期，在每个周期内，针对每个音频类型的子音频数据，虚拟硬件抽象层创建一次对应的音频路由。例如，虚拟硬件抽象层在初次接收到音频框架发送的某个音频类型的子音频数据时，创建与该音频类型对应的音频路由，之后，在该周期内，可直接通过该音频路由转发与该音频路由对应的子音频数据至编码器中。

可选地，当检测到电子设备与车载音频设备断开连接时，虚拟硬件抽象层销毁创建的音频路由。这种实现方式，在一个周期结束时销毁创建的音频路由，有效避免音频路由长期占用系统资源，提高了资源利用率，提升了电子设备的性能。

可以理解的是，若在一个周期内，虚拟硬件抽象层从未接收到音频框架发送的某个音频类型的子音频数据，则在该周期内可以不创建与该音频类型对应的音频路由。这种实现方式，在有需求的情况下创建对应的音频路由，可以有效降低资源的消耗，提高资源利用率。

设备虚拟化服务可以包括虚拟音频服务、虚拟通话服务以及传输通道。

虚拟音频服务用于接收虚拟硬件抽象层通过各个音频路由转发的各个非通话子音频数据，并将各个非通话子音频数据发送至对应的编码器中。其中，非通话子音频数据可以包括媒体子音频数据、导航子音频数据、混音子音频数据等。

虚拟通话服务用于接收通话子音频数据，并将通话子音频数据发送至对应的通话编码器中。

应用程序框架层为子音频数据创建对应数量的编码器，或者说，应用程序框架层为每种音频类型的子音频数据创建对应的编码器，使得创建出来的编码器与各个子音频数据的音频类型相匹配。

应用程序框架层创建的编码器用于，对传输至该编码器中的子音频数据进行编码处理，得到对应的编码音频。之后，通过设备虚拟化服务中的传输通道，将编码音频发送至车载音频设备。

可选地，在一种可能地实现方式中，若音频框架对接收到的音频数据均未做混音处理，虚拟硬件抽象层为每种子音频数据均创建了各自对应的音频路由，则设备虚拟化服务为通过这些音频路由转发至设备虚拟化服务中的每种子音频数据创建对应的编码器。例如，为通过第一音频路由转发至设备虚拟化服务中的媒体子音频数据创建第一编码器，第一编码器用于对媒体子音频数据进行编码处理，得到媒体子音频数据对应的编码音频；为通过第二音频路由转发至设备虚拟化服务中的导航子音频数据创建第二编码器，第二编码器用于对导航子音频数据进行编码处理，得到导航子音频数据对应的编码音频；为通过第三音频路由转发至设备虚拟化服务中的通话子音频数据创建第三编码器，第三编码器用于对通话子音频数据进行编码处理，得到通话子音频数据对应的编码音频；为通过第四音频路由转发至设备虚拟化服务中的通知子音频数据创建第四编码器，第四编码器用于对通知子音频数据进行编码处理，得到通知子音频数据对应的编码音频；为通过第五音频路由转发至设备虚拟化服务中的警示子音频数据创建第五编码器，第五编码器用于对警示子音频数据进行编码处理，得到警示子音频数据对应的编码音频；为通过第六音频路由转发至设备虚拟化服务中的铃声子音频数据创建第六编码器，第六编码器用于对铃声子音频数据进行编码处理，得到铃声子音频数据对应的编码音频。

可选地，在另一种可能地实现方式中，若音频框架对音频类型为其他音频类型的音频数据进行了混音处理，虚拟硬件抽象层为媒体子音频数据创建了第一音频路由，为导航子音频数据创建了第二音频路由，为混音子音频数据创建了第三音频路由，为通话子音频数据创建了通话音频路由。设备虚拟化服务为通过这些音频路由转发至设备虚拟化服务中的每种子音频数据创建对应的编码器。

例如，为通过第三音频路由转发至设备虚拟化服务中的混音子音频数据创建第三编码器，第三编码器用于对混音子音频数据进行编码处理，得到混音子音频数据对应的编码音频；为通过通话音频路由转发至设备虚拟化服务中的通话子音频数据创建通话编码器，通话编码器用于对通话子音频数据进行编码处理，得到通话子音频数据对应的编码音频。

这种实现方式中，为不同音频类型的子音频数据创建各自对应的编码器，使一个类型的编码器只需对一种音频类型的子音频数据进行编码处理，能够提升编码效率，有效避免发生编码卡顿现象，从而使最终在车载音频设备播放的音频更流畅。其中，编码卡顿现象是由于一个类型的编码器对多种音频类型的子音频数据进行编码处理，导致每个子音频数据进行编码的等待时间增加所造成的。

可选地，设备虚拟化服务在创建编码器时，根据接收到的子音频数据的音频类型，或音频路由的标识对创建的编码器进行标识，这样有利于区分创建好的各个编码器，也有利于后续传输通道根据标识将各个编码器的编码音频，快速发送至车载音频设备对应的解码器中。

应理解，对创建的编码器进行标识的方式不做限定。示例性地，可以通过不同的编码器名称进行标识，例如，第一编码器、第二编码器、第三编码器、通话编码器等。又例如，路由1编码器、路由2编码器、路由3编码器等。

可选地，在一种可能地实现方式中，设备虚拟化服务创建编码器，可以是预先针对每个音频类型的子音频数据创建好对应的编码器，并长期存储在设备虚拟化服务中，便于后期快速通过创建好的编码器对各个音频类型的子音频数据进行编码处理。

可选地，在另一种可能地实现方式中，以电子设备与车载音频设备建立连接开始、电子设备与车载音频设备断开连接结束为一个周期，在每个周期内，针对每个音频类型的子音频数据，设备虚拟化服务创建一次对应的编码器。例如，设备虚拟化服务在初次接收到某个音频路由转发的某个音频类型的子音频数据时，创建与该音频类型对应的编码器，之后，在该周期内，可直接通过该编码器对这一音频类型的子音频数据进行编码处理。

可选地，当检测到电子设备与车载音频设备断开连接时，设备虚拟化服务销毁创建的编码器。这种实现方式，在一个周期结束时销毁创建的编码器，有效避免编码器长期占用系统资源，提高了资源利用率，提升了电子设备的性能。

可以理解的是，若在一个周期内，设备虚拟化服务从未接收到某个音频路由发送的某个音频类型的子音频数据，则在该周期内可以不创建与该音频类型对应的编码器。这种实现方式，在有需求的情况下创建对应的编码器，可以有效降低资源的消耗，提高资源利用率。

前述实现方式中，虚拟硬件抽象层为通话子音频数据创建了通话音频路由，可通过该通话音频路由将通话子音频数据转发至设备虚拟化服务的编码器中。可选地，在一种可能地实现方式中，电子设备可以包括自适应数据信号处理(Adaptive Data SignalProcessing，ADSP)框架，通话应用生成的通话音频数据通过ADSP框架直接传输至虚拟硬件抽象层。虚拟硬件抽象层还可以包括预先建立的通话通道，通过该通话通道将通话音频数据传输至设备虚拟化服务的虚拟通话服务中。虚拟通话服务将通话音频数据发送至对应的通话编码器中。这种实现方式中，为通话音频数据建立单独的通话通道以及通话编码器，可以保证通话音频数据的传输过程和编码过程不受干扰，有效提高了通话质量。

设备虚拟化服务包括预设的传输通道，该传输通道用于将各个编码器进行编码处理后得到的编码音频发送至车载音频设备。示例性地，该传输通道可以包括多个发送单元，每个发送单元用于发送一种类型的编码音频。

例如，传输通道可以包括第一发送单元、第二发送单元、第三发送单元以及第四发送单元。通过第一发送单元将媒体子音频数据对应的编码音频发送至车载音频设备；通过第二发送单元将导航子音频数据对应的编码音频发送至车载音频设备；通过第三发送单元将混音子音频数据对应的编码音频发送至车载音频设备；通过第四发送单元将通话子音频数据对应的编码音频发送至车载音频设备。

这种实现方式中，通过一个传输通道传输各个编码音频，降低了资源消耗，有效节省了电子设备的资源。

可选地，在一种可能地实现方式中，传输通道可以包括第一传输通道和第二传输通道，第一传输通道用于传输非通话音频子数据对应的编码音频，第二传输通道用于传输通话子音频数据对应的编码音频。

其中，第一传输通道可以包括多个发送单元，每个发送单元用于发送一种类型的编码音频。非通话子音频数据可以包括媒体子音频数据、导航子音频数据、混音子音频数据。

这种实现方式中，为通话子音频数据建立单独的传输通道，可以保证通话子音频数据对应的编码音频在传输过程中不受干扰，有效提高了通话质量。

本申请实施例提供的音频处理方法，应用于电子设备的应用程序框架层，该电子设备与车载音频设备连接，电子设备的应用程序框架层接收多个应用程序生成的音频数据，将音频数据处理为子音频数据，子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个，通过为子音频数据创建的对应数量的编码器，对各个子音频数据进行编码处理，得到编码音频，通过预设的传输通道，将编码音频发送至车载音频设备。

上面结合软件结构对本申请实施例提供的音频处理方法进行了描述，下面结合系统架构对本申请实施例提供的音频处理方法进行描述。请参阅图5，图5为本申请一示例性实施例示出的系统架构框图。如图5所示，系统架构框图在图4对应的电子设备的软件结构框图基础上，增加了车载音频设备的软件结构。关于图4对应的电子设备的软件结构此处不再赘述，下面对车载音频设备的软件结构进行详细描述。

在本申请实施例中，车载音频设备的系统分为两层，分别为应用程序层和应用程序框架层，应用程序层和应用程序框架层之间通过软件接口通信。

车载音频设备的应用程序层可以包括车机应用，该车机应用可用于感知电子设备和车载音频设备建立通信连接，以及感知电子设备和车载音频设备断开连接。

车载音频设备的应用程序框架层可以包括设备虚拟化服务和音频框架。

其中，设备虚拟化服务可以包括传输通道、解码器以及音频播放模块。

设备虚拟化服务包括传输通道，该传输通道用于将电子设备发送的各个编码音频传输至各自对应的解码器中。示例性地，该传输通道可以包括多个接收单元，每个接收单元用于接收电子设备发送的一种类型的编码音频，同时，将该种类型的编码音频传输至对应的解码器中。

例如，传输通道可以包括第一接收单元、第二接收单元、第三接收单元以及第四接收单元。通过第一接收单元传输媒体子音频数据对应的编码音频；通过第二接收单元传输导航子音频数据对应的编码音频；通过第三发送单元传输混音子音频数据对应的编码音频；通过第四接收单元传输通话子音频数据对应的编码音频。

可选地，在一种可能地实现方式中，传输通道可以包括第三传输通道和第四传输通道，第三传输通道用于传输电子设备发送的非通话音频子数据对应的编码音频，第四传输通道用于传输电子设备发送的通话子音频数据对应的编码音频。

其中，第三传输通道可以包括多个接收单元，每个接收单元用于接收一种类型的编码音频，同时，将一种类型的编码音频传输至对应的解码器中。非通话子音频数据可以包括媒体子音频数据、导航子音频数据、混音子音频数据。

这种实现方式中，为通话子音频数据对应的编码音频建立单独的传输通道，可以保证通话子音频数据对应的编码音频在传输过程中不受干扰，有效提高了通话质量。

应用程序框架层为编码音频创建对应数量的解码器，或者说，应用程序框架层为每种音频类型的编码音频创建对应的解码器，使得创建出来的解码器与各个编码音频的音频类型相匹配。应理解，编码音频的音频类型即为被编码为该编码音频的子音频数据所对应的音频类型。

应用程序框架层创建的解码器用于，对传输至该解码器中的编码音频进行解码处理，得到解码音频。之后，将解码音频发送至车载音频设备的音频框架中。

可选地，在一种可能地实现方式中，若电子设备的音频框架对接收到的音频数据均未做混音处理，使得电子设备侧最终创建了多个编码器，如前文所述创建了第一编码器、第二编码器、第三编码器、第四编码器、第五编码器以及第六编码器。

相应地，车载音频设备的应用程序框架层为媒体子音频数据对应的编码音频创建第一解码器，第一解码器用于对媒体子音频数据对应的编码音频进行解码处理，得到媒体子音频数据对应的解码音频；为导航子音频数据对应的编码音频创建第二解码器，第二解码器用于对导航子音频数据对应的编码音频进行解码处理，得到导航子音频数据对应的解码音频；为通话子音频数据对应的编码音频创建第三解码器，第三解码器用于对通话子音频数据对应的编码音频进行解码处理，得到通话子音频数据对应的解码音频；为通知子音频数据对应的编码音频创建第四解码器，第四解码器用于对通知子音频数据对应的编码音频进行解码处理，得到通知子音频数据对应的解码音频；为警示子音频数据对应的编码音频创建第五解码器，第五解码器用于对警示子音频数据对应的编码音频进行解码处理，得到警示子音频数据对应的解码音频；为铃声子音频数据对应的编码音频创建第六解码器，第六解码器用于对铃声子音频数据对应的编码音频进行解码处理，得到铃声子音频数据对应的解码音频。

可选地，在另一种可能地实现方式中，若电子设备的音频框架对音频类型为其他音频类型的音频数据进行了混音处理，使得电子设备侧最终创建了第一编码器、第二编码器、第三编码器以及通话编码器。相应地，车载音频设备的应用程序框架层为每种编码器传输的编码音频创建对应的解码器。

例如，电子设备侧为混音子音频数据创建了第三编码器，车载音频设备的应用程序框架层为混音子音频数据对应的编码音频创建第三解码器，第三解码器用于对混音子音频数据对应的编码音频进行解码处理，得到混音子音频数据对应的解码音频；电子设备侧为通话子音频数据创建了通话编码器，车载音频设备的应用程序框架层为通话子音频数据对应的编码音频创建通话解码器，通话解码器用于对通话子音频数据对应的编码音频进行解码处理，得到通话子音频数据对应的解码音频。

这种实现方式中，为不同音频类型的编码音频创建各自对应的解码器，使一个类型的解码器只需对一种音频类型的编码音频进行解码处理，有效避免了音频卡顿现象的发生，从而提升了最终播放的音频的流畅性，进而提升了用户体验。其中，音频卡顿现象是由于一个类型的解码器对多种音频类型的编码音频进行解码处理，导致每个编码音频进行解码的等待时间增加所造成的。

可选地，设备虚拟化服务在创建解码器时，根据接收到的编码音频的音频类型对创建的解码器进行标识，这样有利于区分创建好的各个解码器，也有利于后续音频播放模块对各个解码器传输的解码音频进行单独调整、播放操作。

应理解，对创建的解码器进行标识的方式不做限定。示例性地，可以通过不同的解码器名称进行标识，例如，第一解码器、第二解码器、第三解码器、通话解码器等。又例如，路由1解码器、路由2解码器、路由3解码器等。

可选地，在一种可能地实现方式中，设备虚拟化服务创建解码器，可以是预先针对每个音频类型的编码音频创建好对应的解码器，并长期存储在设备虚拟化服务中，便于后期快速通过创建好的解码器对各个音频类型的编码音频进行解码处理。

可选地，在另一种可能地实现方式中，以电子设备与车载音频设备建立连接开始、电子设备与车载音频设备断开连接结束为一个周期，在每个周期内，针对每个音频类型的编码音频，设备虚拟化服务创建一次对应的解码器。例如，设备虚拟化服务在初次接收到电子设备发送的某个音频类型的编码音频时，创建与该音频类型对应的解码器，之后，在该周期内，可直接通过该解码器对这一音频类型的编码音频进行解码处理。

可选地，当检测到电子设备与车载音频设备断开连接时，设备虚拟化服务销毁创建的解码器。这种实现方式，在一个周期结束时销毁创建的解码器，有效避免解码器长期占用系统资源，提高了资源利用率，提升了车载音频设备的性能。

可以理解的是，若在一个周期内，设备虚拟化服务从未接收到电子设备发送的某个音频类型的编码音频，则在该周期内可以不创建与该音频类型对应的解码器。这种实现方式，在有需求的情况下创建对应的解码器，可以有效降低资源的消耗，提高资源利用率。

音频播放模块为车载音频设备封装的接口，用于暂时存储各个解码音频，还用于将各个解码音频发送给音频框架。示例性地，各个解码器将解码处理后得到的解码音频发送至音频播放模块，音频播放模块暂时存储各个解码音频，每间隔预设时长，将暂时存储的各个解码音频发送给音频框架。

可以理解的是，上述“预设时长”可根据实际情况进行设置、调整，譬如预设时长可以为10毫秒、20毫秒、30毫秒等等。

音频框架获取播放策略，在接收到音频播放模块发送的各个解码音频后，根据播放策略播放和/或调整解码音频。播放策略可以包括独立调整解码音频对应的播放音量，和/或通过指定扬声器播放与指定扬声器对应的解码音频。

例如，播放策略具体包括增大媒体音频(如音乐音频)的播放音量，音频框架增大媒体子音频数据对应的解码音频的播放音量，使最终扬声器播放出的媒体音频的音量增大。

又例如，播放策略具体包括通过驾驶座扬声器播放导航音频，音频框架指定驾驶座扬声器播放导航子音频数据对应的解码音频，最终由驾驶座扬声器播放导航子音频数据对应的解码音频。

可选地，在一种可能地实现方式中，车载音频设备的车机应用根据驾驶员或乘客的需求生成播放策略，并将播放策略发送给音频框架。

上面结合系统架构对本申请实施例提供的音频处理方法进行了描述，下面结合流程图，对本申请实施例提供的音频处理方法进行描述。

请参阅图6，图6为本申请实施例示出的一种音频处理方法的流程示意图。该方法包括：

S101、发送音频分流指令以及跨设备音频流转能力启动指令。

电子设备的应用程序层可以包括车机应用。车机应用能够感知电子设备和车载音频设备之间建立通信连接，或断开连接，当感知到电子设备和车载音频设备建立通信连接时，车机应用向应用程序框架层的音频框架发送音频分流指令，以及向应用程序框架层的设备虚拟化服务发送跨设备音频流转能力启动指令。

其中，音频分流指令用于指示音频框架将多个应用程序生成的音频数据处理为子音频数据。可以通俗理解为，音频分流指令用于指示音频框架对媒体音频数据、导航音频数据以及通话音频数据不进行混音处理，对其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)进行混音处理。

跨设备音频流转能力启动指令用于，指示设备虚拟化服务为不同音频类型的子音频数据创建对应的编码器，以及对子音频数据进行编码处理，从而得到编码音频。

其中，子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个，混音子音频数据是对除媒体子音频数据、导航子音频数据以及通话子音频数据外的其他子音频数据进行混音处理得到的。

S102、开启音频分流功能和跨设备音频流转功能。

电子设备中的音频框架接收到音频分流指令后，开启音频分流功能。

其中，音频分流功能指音频框架将多个应用程序生成的音频数据处理为子音频数据的功能。可以通俗理解为，音频分流功能为音频框架对媒体音频数据、导航音频数据以及通话音频数据不进行混音处理，对其他音频数据(如通知音频数据、警示音频数据、铃声音频数据等)进行混音处理的功能。

可以理解为，开启音频分流功能后，音频框架在接收到媒体音频数据、导航音频数据以及通话音频数据时，不对媒体音频数据、导航音频数据以及通话音频数据进行混音处理，而在接收到通知音频数据、警示音频数据、铃声音频数据等时，对通知音频数据、警示音频数据、铃声音频数据等进行混音处理。

可选地，在一种可能地实现方式中，音频分流功能还可以指音频框架对任何音频数据均不作混音处理的功能，这样有利于后续车载音频设备对任一种音频类型的解码音频都可以独立调整、播放。

电子设备中的设备虚拟化服务接收到跨设备音频流转能力启动指令后，开启跨设备音频流转功能。

其中，跨设备音频流转功能指设备虚拟化服务创建编码器以及利用编码器进行编码处理的功能。具体地，跨设备音频流转功能指设备虚拟化服务为不同音频类型的子音频数据创建对应的编码器，以及利用编码器对与该编码器相匹配的子音频数据进行编码处理的功能。

S103、用户触发输入操作。

示例性地，电子设备中预先安装有多个应用程序。在本申请实施例中，多个应用程序可以为媒体类应用程序、导航类应用程序、通话类应用程序、购物类应用程序、工具类应用程序、其他应用程序等中的一类或多类。

本申请实施例中，以多个应用程序为媒体应用(如音乐应用)、导航应用(如地图应用)、通话应用(如电话应用)以及其他应用(如短信息应用)为例进行说明。

输入操作可以为点击操作。例如，用户对电子设备中应用程序对应的图标进行点击操作。

可选地，在本申请的实施例中，输入操作也可以为通过语音指示启动应用程序的操作，输入操作也可以为通过手势指示启动应用程序的操作，输入操作还可以为通过眼球指示启动应用程序的操作等等，本申请对此不作任何限定。

示例性地，电子设备检测到用户对某个应用程序对应图标的输入操作后，响应用户触发的输入操作，启动并运行某个应用程序。例如，用户可以通过单击音乐应用的图标，指示电子设备启动并运行音乐应用。之后，音乐应用开始播放音乐。

S104、接收多个应用程序生成的音频数据。

示例性地，不同的应用程序在运行时会生成不同类型的音频数据。音频数据可以包括媒体音频数据、导航音频数据、通话音频数据、通知音频数据、警示音频数据、铃声音频数据、提示音频数据等。

例如，媒体应用可以生成媒体音频数据，导航应用可以生成导航音频数据，通话应用可以生成通话音频数据，其他应用可以生成通知音频数据、警示音频数据、铃声音频数据、提示音频数据等。

其中，媒体音频数据可以包括但不限于，各种音乐应用、各种视频应用、各种短视频应用、各种社交应用、各种游戏应用以及各种资讯应用生成的音频数据。

导航音频数据可以包括但不限于，各种地图应用、各种出行应用、各种打车应用、各种定位应用生成的音频数据。

通话音频数据可以包括但不限于，电话应用、各种网络电话应用生成的音频数据。

应用程序层的多个应用程序生成音频数据后，将音频数据发送给应用程序框架层的音频框架，音频框架接收多个应用程序生成的音频数据。应理解，实际生成的音频数据的数量与类型，与用户所使用的应用程序有关，对此不做限定。

S105、将音频数据处理为子音频数据。

相关技术中，音频框架在接收到多个应用程序生成的音频数据后，无论接收到的音频数据是什么音频类型，都会对接收到的所有的音频数据进行混音处理，最终将混音处理后的数据发送给车载音频设备。由于混音处理是个不可逆的过程，车载音频设备接收到混音数据后，无法对混音数据进行拆分，即无法从混音数据中拆分出各个类型的音频数据。只能对混音数据进行统一播放、调整等操作，无法对各个类型的音频数据进行单独播放、调整等操作，导致电子设备与车辆之间很多用于提升用户体验的优化场景无法实现，降低了用户的驾乘体验。

本申请实施例提供的音频处理方法中，音频框架在接收到多个应用程序生成的音频数据时，识别各个音频数据的音频类型。

其中，音频类型可以包括媒体音频类型、导航音频类型、通话音频类型以及其他音频类型。其中，其他音频类型可以包括通知音频类型、警示音频类型、铃声音频类型、提示音频类型等。

在一种可能地实现方式中，音频框架对媒体音频类型、导航音频类型、通话音频类型以及其他音频类型的音频数据均不进行混音处理。

在另一种可能地实现方式中，音频框架对媒体音频类型、导航音频类型以及通话音频类型的音频数据不进行混音处理，而对其他音频类型(如通知音频类型、警示音频类型、铃声音频类型、提示音频类型等)的音频数据进行混音处理。

示例性地，在识别各个音频数据的音频类型时，通常情况下，电子设备的系统会对应用程序层的各个应用程序所生成的音频数据进行标识，音频框架根据各个音频数据携带的音频类型标识识别出各个音频数据的音频类型。

应理解，各个音频数据的音频类型与子音频数据的音频类型一致。因此，也可以根据音频数据携带的不同的音频类型标识，从音频数据中识别出媒体子音频数据、导航子音频数据、通话子音频数据以及其他子音频数据中的至少两种。

例如，音频框架在确定出媒体音频数据、导航音频数据以及通话音频数据的音频类型后，将媒体音频数据确定为媒体子音频数据，将导航音频数据确定为导航子音频数据，将通话音频数据确定为通话子音频数据。

示例性地，若识别出其他子音频数据，对其他子音频数据进行混音处理，得到混音子音频数据。

例如，音频框架在确定出通知音频数据、警示音频数据、铃声音频数据以及提示音频数据的音频类型后，将通知音频数据确定为通知子音频数据，将警示音频数据确定为警示子音频数据，将铃声音频数据确定为铃声子音频数据，将提示音频数据确定为提示子音频数据。对通知子音频数据、警示子音频数据、铃声子音频数据以及提示子音频数据进行混音处理，得到混音子音频数据。

S106、通过音频路由转发子音频数据。

本申请实施例提供的音频处理方法还包括，通过虚拟硬件抽象层创建音频路由。

示例性地，虚拟硬件抽象层为子音频数据创建对应数量的音频路由，或者说，虚拟硬件抽象层为每种音频类型的子音频数据创建对应的音频路由，使得创建出来的音频路由与各个子音频数据的音频类型相匹配。

可选地，在一种可能地实现方式中，音频框架对接收到的音频数据均未做混音处理，虚拟硬件抽象层为每一种子音频数据都创建一个其对应的音频路由。

可选地，在另一种可能地实现方式中，音频框架对音频类型为其他音频类型的音频数据进行了混音处理，虚拟硬件抽象层为媒体子音频数据创建第一音频路由，为导航子音频数据创建第二音频路由，为混音子音频数据创建第三音频路由，为通话子音频数据创建通话音频路由。

可以理解的是，在本申请一些实现方式中，通话音频数据与通话子音频数据表示的信息一致，只是名称不同。

S107、通过虚拟音频服务转发子音频数据。

设备虚拟化服务可以包括虚拟音频服务和虚拟通话服务。示例性地，虚拟硬件抽象层的音频路由先将非通话子音频数据传输至设备虚拟化服务的虚拟音频服务中，将通话子音频数据传输至设备虚拟化服务的虚拟通话服务中。

其中，非通话子音频数据可以包括媒体子音频数据、导航子音频数据、混音子音频数据。

虚拟音频服务将非通话子音频数据传输至对应的编码器中，虚拟通话服务将通话子音频数据传输至对应的通话编码器中。

本申请实施例提供的音频处理方法还包括，通过应用程序框架层中的设备虚拟化服务创建编码器。

示例性地，应用程序框架层中的设备虚拟化服务为子音频数据创建对应数量的编码器，或者说，应用程序框架层中的设备虚拟化服务为每种音频类型的子音频数据创建对应的编码器，使得创建出来的编码器与各个子音频数据的音频类型相匹配。

S108、对子音频数据进行编码处理，发送编码音频。

本申请实施例中，编码处理是指对子音频数据进行压缩，这样可以减小子音频数据的数据量，有利于后续传输编码音频时降低带宽。

可选地，编码处理也可以是将子音频数据转换为网络信号。

示例性地，通过为子音频数据创建的编码器，对与各编码器匹配的子音频数据进行编码处理，得到编码音频。之后，将编码音频发送至传输通道中。

S109、通过传输通道发送编码音频。

这种实现方式中，通过一个传输通道传输各个编码音频，在保证性能的前提下降低了资源消耗，有效节省了电子设备的资源。

可选地，在一种可能地实现方式中，为不同音频类型的编码音频建立不同的传输通道，每个传输通道用于传输一种音频类型的编码音频。这种实现方式中，可在同一时间传输多种不同音频类型的编码音频，提升传输速率，且每个传输通道用于传输一种音频类型的编码音频，有效避免编码音频在传输过程中互相干扰。

可选地，在通过传输通道发送编码音频时，可以为每个编码音频添加一个数据头，该数据头用于标识编码音频的音频类型(也即该编码音频对应的子音频数据的音频类型)，这样有利于车载音频设备的传输通道接收到该编码音频时，能够通过识别编码音频的数据头快速确定出编码音频的音频类型，从而快速将编码音频发送至对应的解码器中。

请参阅图7，图7为本申请实施例示出的另一种音频处理方法的流程示意图。该方法包括：

S201、发送音频分流指令以及跨设备音频流转能力启动指令。

S202、开启音频分流功能和跨设备音频流转功能。

S203、用户触发输入操作。

S204、接收多个应用程序生成的音频数据。

S205、将音频数据处理为子音频数据。

S206、通过音频路由转发子音频数据。

S207、通过虚拟音频服务转发子音频数据。

S208、对子音频数据进行编码处理，发送编码音频。

S209、通过传输通道发送编码音频。

步骤S201至步骤S209的具体内容，可参考前述步骤S101至步骤S109中所描述的方法，此处不再赘述。

S210、接收并发送编码音频。

车载音频设备的应用程序框架层可以包括设备虚拟化服务和音频框架。其中，设备虚拟化服务可以包括传输通道、解码器以及音频播放模块。

示例性地，电子设备的传输通道将各个编码音频发送至车载音频设备的传输通道中，车载音频设备的传输通道接收到各个编码音频后，将各个编码音频传输至各自对应的解码器中。

S211、对编码音频进行解码处理，得到解码音频。

本申请实施例中，解码处理是指对编码音频进行解压缩，这样可以恢复子音频数据的数据量，有利于后续流畅播放解码音频。

可选地，解码处理也可以是将网络信号转换为音频信号。

示例性地，车载音频设备的设备虚拟化服务为编码音频创建对应数量的解码器，通过创建的解码器对传输至该解码器中的编码音频进行解码处理，得到解码音频。之后，将解码音频发送至车载音频设备的音频播放模块中。

S212、发送解码音频。

示例性地，音频播放模块暂时存储解码器发送的各个解码音频，每间隔预设时长，将暂时存储的各个解码音频发送给音频框架。

S213、根据播放策略播放解码音频。

示例性地，音频框架获取播放策略，在接收到音频播放模块发送的各个解码音频后，根据播放策略播放和/或调整解码音频。播放策略可以包括独立调整解码音频对应的播放音量，和/或通过指定扬声器播放与指定扬声器对应的解码音频。

例如，播放策略具体包括在岔路口增大导航音频的播放音量，减小音乐音频的播放音量。又例如，播放策略具体包括通过驾驶座扬声器和副驾驶座扬声器播放导航音频。再例如，播放策略具体包括通过车辆内的所有扬声器播放音乐音频等等。

可选地，在一种可能地实现方式中，播放策略可以根据车辆内人员的分布状态来确定。例如，检测到车辆内只有驾驶员一人，则播放策略可以包括通过驾驶座扬声器播放导航音频和媒体音乐。又例如，检测到车辆内有驾驶员和副驾驶乘客两人，则播放策略可以包括通过驾驶座扬声器和副驾驶座扬声器共同播放导航音频和媒体音乐。再例如，检测到车辆内驾驶座、副驾驶座以及后排座椅均有人，则播放策略可以包括通过驾驶座扬声器播放导航音频，通过车辆内的所有扬声器播放音乐音频等等。此处仅为示例性说明，对此不做限定。

请参阅图8，图8为本申请实施例示出的另一种系统结构框图。如图8所示，电子设备可以包括音频框架、虚拟硬件抽象层以及设备虚拟化服务，车载音频设备可以包括设备虚拟化服务和音频框架。

本申请实施例中，以应用程序为音乐应用和导航应用为例进行说明。用户对音乐应用和导航应用进行输入操作，音乐应用生成音乐音频数据，导航应用生成导航音频数据，音频框架识别出音乐音频数据和导航音频数据的音频类型后，将音乐音频数据和导航音频数据分别处理为音乐子音频数据和导航子音频数据。音频框架将音乐子音频数据和导航子音频数据发送至虚拟硬件抽象层，虚拟硬件抽象层通过为音乐子音频数据和导航子音频数据分别创建的音频路由，将音乐子音频数据和导航子音频数据转发至设备虚拟化服务中。

设备虚拟化服务通过为音乐子音频数据创建的第一编码器，对音乐子音频数据进行编码处理，得到第一编码音频，并将第一编码音频发送至传输通道。设备虚拟化服务通过为导航子音频数据创建的第二编码器，对导航子音频数据进行编码处理，得到第二编码音频，并将第二编码音频发送至传输通道。

这种实现方式中，通过不同的编码器对不同音频类型的子音频数据进行编码处理，能够提升编码效率，有效避免发生编码卡顿现象，从而使最终在车载音频设备播放的音频更流畅。

通过设备虚拟化服务中的传输通道，将第一编码音频和第二编码音频发送至车载音频设备的传输通道中。这种实现方式中，通过一个传输通道传输不同音频类型的编码音频，实现了传输通道的复用，在保证性能的前提下降低了资源消耗，有效节省了电子设备的资源。

车载音频设备的传输通道接收电子设备发送的第一编码音频和第二编码音频，并将第一编码音频发送至第一解码器，将第二编码音频发送至第二解码器。其中，第一解码器是车载音频设备的设备虚拟化服务为媒体音频类型的编码音频创建的解码器，第二解码器是车载音频设备的设备虚拟化服务为导航音频类型的编码音频创建的解码器。

这种实现方式中，在车载音频设备端，通过一个传输通道传输不同音频类型的编码音频，实现了传输通道的复用，在保证性能的前提下降低了资源消耗，有效节省了车载音频设备的资源。

通过第一解码器对第一编码音频进行解码处理，得到第一解码音频，将第一解码音频发送至车载音频设备的音频框架中；通过第二解码器对第二编码音频进行解码处理，得到第二解码音频，将第二解码音频发送至车载音频设备的音频框架中。

这种实现方式中，通过不同的解码器对不同音频类型的编码音频进行解码处理，有效避免了音频卡顿现象的发生，从而提升了最终播放的音频的流畅性，进而提升了用户体验。

车载音频设备的音频框架根据播放策略播放第一解码音频和第二解码音频。例如，通过第一播放器(如副驾驶座扬声器)播放第一解码音频，通过第一播放器(如驾驶座扬声器)播放第二解码音频等。

由于车载音频设备接收到的不是混音数据，而是一个个单独的编码音频，对编码音频进行解码处理后，得到的解码音频也是一个个单独的音频(或者说，解码得到的每个解码音频都是不同音频类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此，本申请提供的音频处理方法，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

且相较于相关技术，本申请在传输数据的方式以及音频路由设计上大有不同，实现了传输通道的复用，在保证性能的前提下降低了资源消耗，有效节省了电子设备和车载音频设备的资源，提升了电子设备与车辆之间的交互体验。

下面以电子设备侧为主，描述本申请提供的音频处理方法，请参阅图9，图9为本申请实施例示出的又一种音频处理方法的流程示意图。该方法包括：

S301、接收多个应用程序生成的音频数据。

S302、将音频数据处理为子音频数据。

S303、通过为子音频数据创建的对应数量的编码器，对子音频数据进行编码处理，得到编码音频。

S304、通过预设的传输通道，将编码音频发送至车载音频设备。

步骤S301至步骤S304的具体内容，可参考前文描述，此处不再赘述。

下面以车载音频设备侧为主，描述本申请提供的音频处理方法，请参阅图10，图10为本申请实施例示出的再一种音频处理方法的流程示意图。该方法包括：

S401、接收通过预设的传输通道发送的编码音频。

S402、通过为编码音频创建的解码器，对编码音频进行解码处理，得到解码音频。

S403、根据播放策略播放解码音频。

步骤S401至步骤S403的具体内容，可参考前文描述，此处不再赘述。

可选地，本申请实施例提供的音频处理方法，还可应用于电子设备之间有跨设备音频流转的交互场景中。例如，手机与平板电脑、手机与智慧屏、手机与计算机、平板电脑与智慧屏、平板电脑与计算机等的交互场景中。

示例性地，以手机与平板电脑之间的交互场景为例进行说明。例如，手机与平板电脑通过蓝牙建立通信连接，手机与平板电脑之间进行音频数据传输和音频数据处理。对于具体如何进行音频数据传输和音频数据处理，可以参考上述步骤S201至步骤S213中的描述，此处不再赘述。

值得说明的是，平板电脑本身带有扬声器，还可以连接有线耳机或无线耳机作为扬声器。该平板电脑对应的播放策略可以为，独立调整不同扬声器播放的解码音频的音量。例如，通过无线耳机播放通话音频时，增大通话音量。

该平板电脑对应的播放策略还可以为，通过指定扬声器播放与指定扬声器对应的解码音频。例如，通过无线耳机播放通话音频，通过平板电脑本身的扬声器播放音乐音频等。

本申请提供的音频处理方法，能够满足电子设备音频播放的个性化需求，提高了用户体验。

在前述的音频处理方法中，复用一个传输通道，即电子设备端将不同音频类型的编码音频通过一个传输通道发送至车载音频设备端。这种情况下，通常是每获取到一个编码音频，通过传输通道发送一个编码音频，导致对带宽的利用率不高。为了提升带宽利用率，本申请还提供了一种音频传输方法，能够有效提升带宽利用率，提高编码音频的传输速度。

下面结合软件结构对本申请实施例提供的音频传输方法进行描述。请参考图11，图11为本申请一示例性实施例示出的又一种电子设备的软件结构框图。

图11所展示的电子设备的软件结构框图，是在图4所展示的电子设备的软件结构框图基础上，增加了合包模块。如图11所示，电子设备的设备虚拟化服务还可以包括合包模块。下面主要对合包模块进行描述，其他软件结构可以参考前面关于图4的描述，此处不再赘述。

示例性地，设备虚拟化服务中的各个编码器对子音频数据进行编码处理，得到多个编码音频；通过合包模块对多个编码音频进行合包处理，得到合包数据；合包模块将合包数据发送至传输通道，传输通道将合包数据发送至车载音频设备。

其中，合包处理是指将多个编码音频拼接/组合起来，拼接/组合得到的数据即为合包数据。可以通俗理解为，将多个数据包(每个编码音频对应一个数据包)拼接/组合为一个数据包(合包数据对应一个数据包)。

若不对多个编码音频进行合包处理，每获取到一个编码音频，通过传输通道发送一个编码音频，会导致带宽利用率低。例如，一个编码音频的数据量为400字节，则通过该传输通道一次只能传输400字节大小的数据，下一个编码音频需要等待前一个编码音频传输完成才能传输。而本申请提供的音频传输方法，每次对多个编码音频进行合包处理，再将合包处理得到的合包数据，通过传输通道一次性发送给车载音频设备，增大了每次传输的数据量，提升了带宽利用率，提高了编码音频的传输速度。

可选地，在一种可能地实现方式中，所有编码器(包括通话编码器)将各自编码处理后得到的编码音频发送给合包模块；合包模块对接收到的所有编码音频进行合包处理，得到合包数据；合包模块将该合包数据发送至传输通道，传输通道将合包数据发送至车载音频设备。

这种实现方式中，合包模块对所有音频类型的编码音频都进行合包处理，大大压缩了编码音频的数据量，使通过传输通道一次能够传输更多数据量的编码音频，提升了带宽利用率，提高了编码音频的传输速度。

可选地，在一种可能地实现方式中，除通话编码器外，其他编码器将各自编码处理后得到的编码音频发送给合包模块；合包模块对接收到的编码音频进行合包处理，得到合包数据；合包模块将该合包数据发送至传输通道，传输通道将合包数据发送至车载音频设备。通话编码器将通话音频数据对应的编码音频单独发送给传输通道，传输通道单独将通话音频数据对应的编码音频发送至车载音频设备。

这种实现方式中，为通话音频数据对应的编码音频建立单独的传输通道，可以保证通话音频数据对应的编码音频在传输过程中不受干扰，从而提升了通话质量。同时，合包模块对除通话编码器外其他编码器发送的编码音频进行合包处理，压缩了编码音频的数据量，使通过传输通道一次能够传输更多数据量的编码音频，提升了带宽利用率，提高了编码音频的传输速度。

下面结合附图对合包处理过程进行详细描述。请参考图12，图12为本申请一示例性实施例示出的合包处理示意图。

示例性地，合包模块为每个编码器创建一个输入缓冲区(inBuffer)，即一个编码器对应一个inBuffer，inBuffer用于接收并存储其对应的编码器发送过来的编码音频。为不同的编码器创建各自对应的输入缓冲区，使一个缓冲区只需存储一种音频类型的编码音频，能够保证不同音频类型之间的编码音频的读取、存储等操作不受干扰。

例如，合包模块为第一编码器创建第一输入缓冲区，为第二编码器创建第二输入缓冲区。

在一个示例中，合包模块创建输入缓冲区，可以是预先针对不同音频类型的编码器创建好对应的输入缓冲区，并长期存储在合包模块中，便于后期快速通过创建好的输入缓冲区接收并存储编码音频。

在另一个示例中，以电子设备与车载音频设备建立连接开始、电子设备与车载音频设备断开连接结束为一个周期，在每个周期内，合包模块为设备虚拟化服务创建的每个编码器，创建一次对应的输入缓冲区。例如，合包模块初次接收到某个编码器发送的某个音频类型的编码音频时，创建与该编码器对应的输入缓冲区，之后，在该周期内，可直接通过该输入缓冲区接收并存储与该输入缓冲区对应的编码器发送的编码音频。

可选地，当检测到电子设备与车载音频设备断开连接时，合包模块销毁创建的输入缓冲区。这种实现方式，在一个周期结束时销毁创建的输入缓冲区，有效避免输入缓冲区长期占用系统资源，提高了资源利用率，提升了电子设备的性能。

可以理解的是，若在一个周期内，合包模块从未接收到某个音频类型的编码器发送的编码音频，则在该周期内可以不创建与该编码器对应的输入缓冲区。这种实现方式，在有需求的情况下创建对应的输入缓冲区，可以有效降低资源的消耗，提高资源利用率。

可选地，合包模块还可以为每个编码器建立一个线程(thread)，线程用于提升该线程对应的流程的流畅性，保障该线程对应的流程不被其他线程对应的流程干扰。

例如，合包模块为第一编码器建立第一线程，为第二编码器建立第二线程，第一线程对应的流程为第一编码器将第一编码音频发送(或者说写入)至第一输入缓冲区，第二线程对应的流程为第二编码器将第二编码音频发送(或者说写入)至第二输入缓冲区。有了第一线程和第二线程的存在，第一编码器将第一编码音频发送至第一输入缓冲区的过程，与第二编码器将第二编码音频发送至第二输入缓冲区的过程互不干扰，提升了发送编码音频的流畅性。

可选地，合包模块还可以包括发包器。发包器用于从各个输入缓冲区中读取编码音频，将读取到的编码音频拼接/组合起来，得到合包数据，将合包数据发送至传输通道。

值得说明得是，发包器周期性工作，例如，每到一个发送周期(即预设周期)，该发包器从各个输入缓冲区中读取编码音频，将当前输入缓冲区中的编码音频都读取出来。无论这个发送周期内读取到多少编码音频，都将读取到的编码音频拼接/组合起来，得到合包数据，将合包数据发送至传输通道。之后，继续等待下一个发送周期的到来，然后重复执行读取编码音频、拼接/组合编码音频以及发送合包数据的流程，直至电子设备与车载音频设备断开连接。

其中，发送周期可根据编码器的编码周期进行设置、调整，譬如编码周期可以为10毫秒、20毫秒、30毫秒、40毫秒等，相应地，发送周期可以为10毫秒、20毫秒、30毫秒、40毫秒等等。

值得说明的是，若各个编码器的编码周期不同，为例保证音频不卡顿，根据最小的编码周期设置发送周期。例如，第一编码器的编码周期为10毫秒，第二编码器的编码周期为20毫秒，则发送周期为10毫秒。

可以理解的是，由于发包器每到一个发送周期，从各个输入缓冲区中读取编码音频，那么编码音频在输入缓冲区暂时存储的存储时长便与发送周期相同。例如，当发送周期为20毫秒时，编码音频在输入缓冲区暂时存储的时长也为20毫秒。此处仅为示例性说明，对此不做限定。

可选地，合包模块还可以为发包器建立一个线程，该线程用于提升发包器所要执行的流程(如读取编码音频、拼接/组合编码音频以及发送合包数据的流程)的流畅性，保障发包器所要执行的流程不被其他线程对应的流程干扰。例如，合包模块为发包器建立第三线程。

可选地，在一种可能地实现方式中，发包器对读取到的编码音频进行拼接/组合后，获取合包数据。若成功获取到合包数据，则将合包数据发送至传输通道。之后，发包器进行发送间隔等待，或者说，发包器继续等待下一个发送周期的到来。

若未获取到合包数据，则返回执行获取合包数据的步骤。应理解，可能由于编码器发生抖动、网络卡顿等原因，会导致某个发送周期内发包器没有读取到编码音频，进而导致未获取到合包数据。

这种实现方式中，通过发包器可以将一个发送周期内的编码音频都拼接/组合起来，通过传输通道一并发送给车载音频设备，实现了一个发送周期发送大量的编码音频，提升了带宽利用率，提高了编码音频的传输速度。

请参考图13，图13为本申请一示例性实施例示出的发送周期示意图。如图13所示，两个发送点之间为一个发送周期。例如，第一发送点到第二发送点之间为一个发送周期，记为第一发送周期；第二发送点到第三发送点之间为一个发送周期，记为第二发送周期；第三发送点到第四发送点之间为一个发送周期，记为第三发送周期；第四发送点到第五发送点之间为一个发送周期，记为第四发送周期。

示例性地，在第一发送周期内接收到三个编码音频，分别为第一行的媒体音频类型的编码音频、第二行的导航音频类型的编码音频、第三行的混音音频类型的编码音频，对这三个编码音频进行合包处理，得到合包数据，在第二发送点将该合包数据发送至传输通道。在第二发送周期内接收到一个编码音频，对该编码音频进行合包处理，得到合包数据，在第三发送点将该合包数据发送至传输通道。在第三发送周期内接收到五个编码音频，对这五个编码音频进行合包处理，得到合包数据，在第四发送点将该合包数据发送至传输通道。

应理解，第三发送周期内接收到的带有叉号符号的编码音频，原本应在第二发送周期内接收到，可能由于编码器发生抖动、网络卡顿等原因，导致它们在第三发送周期内接收到。

值得说明的是，对合包数据的数据量不做限定。在一个发送周期内接收到的编码音频越多，生成的合包数据越大；相应地，在一个发送周期内接收到的编码音频越少，生成的合包数据越小。例如，一个编码音频对应的数据量为400字节，在一个发送周期内接收到三个编码音频，生成的合包数据的数据量为1200字节。又例如，一个编码音频对应的数据量为400字节，在一个发送周期内接收到五个编码音频，生成的合包数据的数据量为2000字节。

请参考图14，图14为本申请一示例性实施例示出的合包数据示意图。

在一个示例性中，对多个编码音频进行合包处理，得到合包数据，可以包括：设置传输协议报头，拼接/组合每个编码音频(每个编码音频为一个数据包)，同时，在拼接/组合各个编码音频的过程中，为每个编码音频设置数据头。

其中，传输协议报头用于表示该合包数据是经过合包处理得到的数据，或者说表示该合包数据是经过封装的数据。后续车载音频设备接收到合包数据后，通过识别合包数据中的传输协议报头，可快速确定该合包数据是经过合包处理得到的数据，从而对该合包数据进行分包处理。

数据头可以包括编码音频的属性信息。例如，在数据头中存储编码音频对应的音频路由的标识、编码音频对应的音频类型、编码音频对应的应用程序、编码音频对应的数据包长度等属性信息。可选地，在数据头中还可以存储预留字段，便于后续通过该预留字段为编码音频增加标识、备注等信息，有利于提升电子设备的兼容性。

值得说明的是，拼接/组合每个编码音频的顺序可以根据读取到每个编码音频的顺序确定。例如，依次从第一输入缓冲区中读取到第一编码音频，从第二输入缓冲区中读取到第二编码音频。设置传输协议报头，为第一编码音频设置第一数据头，拼接/组合第一数据头和第一数据包(第一编码音频对应的数据包)；为第二编码音频设置第二数据头，拼接/组合第二数据头和第人数据包(第二编码音频对应的数据包)，得到合包数据。如图14所示，合包数据包括传输协议报头、第一数据头、第一数据包、第二数据头、第二数据包。

这种实现方式，在拼接/组合编码音频的过程中，为编码音频添加数据头，便于后续车载音频设备根据数据头快速对合包数据进行分包处理，以及快速获取到每个编码音频的属性信息。

在另一个示例性中，对多个编码音频进行合包处理，得到合包数据，可以包括：设置传输协议报头，依次拼接/组合每个编码音频(每个编码音频对应一个数据包)。

这种实现方式，直接拼接/组合编码音频，不为编码音频添加数据头，提升了合包处理的速度，进而提升了生成合包数据的速度。

上面结合软件结构对本申请实施例提供的音频传输方法进行了描述，下面结合系统架构对本申请实施例提供的音频传输方法进行描述。请参考图15，图15为本申请一示例性实施例示出的另一种系统架构框图。如图15所示，系统架构框图在图5对应的系统架构框图基础上，增加了合包模块和分包模块。下面主要对车载音频设备的分包模块进行描述，其他软件结构可以参考前面关于图5以及图11的描述，此处不再赘述。

示例性地，电子设备的传输通道将合包数据发送至车载音频设备的传输通道。其中，电子设备的传输通道可以包括发送单元，通过该发送单元将合包数据发送至车载音频设备的传输通道。

在这种实现方式中，由于对多个编码音频进行了合包处理，最终是将合包数据发送至车载音频设备的传输通道，而不是将多个编码音频直接发送至车载音频设备的传输通道。因此，发送单元的数量大大减少(例如，原本发送三个编码音频需要三个发送单元，而这里只需一个发送单元即可)，有效提升了发送合包数据的效率，提升了电子设备与车载音频设备之间的带宽利用率。

示例性地，车载音频设备的传输通道接收到合包数据后，通过设备虚拟化服务中的分包模块对合包数据进行分包处理，得到多个编码音频；设备虚拟化服务中的各个解码器对各个编码音频进行解码处理，得到多个解码音频。各个解码器将解码处理后得到的解码音频发送至音频播放模块，音频播放模块暂时存储各个解码音频，每间隔预设时长，将暂时存储的各个解码音频发送给音频框架。

其中，分包处理是指将合包数据拆分为一个或多个编码音频。

对于车载音频设备来说，其在通过传输通道接收合包数据时，一次便可接收大量的数据，提高了数据传输速率，提升了带宽利用率。

可选地，在一种可能地实现方式中，若在电子设备端，所有编码器(包括通话编码器)将各自编码处理后得到的编码音频发送给合包模块；合包模块对接收到的所有编码音频进行合包处理，得到合包数据；合包模块将该合包数据发送至传输通道，传输通道将合包数据发送至车载音频设备。相应地，车载音频设备的传输通道接收这种场景下的合包数据。

这种实现方式中，由于电子设备端的合包模块对所有音频类型的编码音频都进行合包处理，大大压缩了编码音频的数据量，使通过电子设备的传输通道一次能够传输更多数据量的编码音频，从而使得车载音频设备的传输通道一次能够接收更多数据量的编码音频，提升了电子设备和车载音频设备之间的带宽利用率，提高了编码音频的传输速度。

可选地，在一种可能地实现方式中，若在电子设备端，除通话编码器外，其他编码器将各自编码处理后得到的编码音频发送给合包模块；合包模块对接收到的编码音频进行合包处理，得到合包数据；合包模块将该合包数据发送至传输通道，传输通道将合包数据发送至车载音频设备。相应地，车载音频设备的传输通道接收这种场景下的合包数据。电子设备端的通话编码器将通话音频数据对应的编码音频单独发送给传输通道，传输通道单独将通话音频数据对应的编码音频发送至车载音频设备。相应地，车载音频设备的传输通道单独接收通话音频数据对应的编码音频。

这种实现方式中，为通话音频数据对应的编码音频建立单独的传输通道，可以保证通话音频数据对应的编码音频在传输过程中不受干扰，从而提升了通话质量。同时，由于电子设备端的合包模块对除通话编码器外其他编码器发送的编码音频进行合包处理，压缩了编码音频的数据量，使通过电子设备的传输通道一次能够传输更多数据量的编码音频，从而使得车载音频设备的传输通道一次能够接收更多数据量的编码音频，提升了电子设备和车载音频设备之间的带宽利用率，提高了编码音频的传输速度。

下面结合附图对分包处理过程进行详细描述。请参考图16，图16为本申请一示例性实施例示出的分包处理示意图。

示例性地，分包模块为每个解码器创建一个输入缓冲区，即一个解码器对应一个inBuffer，inBuffer用于接收并存储从合包数据中拆分出来的编码音频。

例如，分包模块为第一解码器创建第一输入缓冲区，为第二解码器创建第二输入缓冲区。

在一个示例中，分包模块创建输入缓冲区，可以是预先针对不同音频类型的解码器创建好对应的输入缓冲区，并长期存储在分包模块中，便于后期快速通过创建好的输入缓冲区接收并存储编码音频。

在另一个示例中，以电子设备与车载音频设备建立连接开始、电子设备与车载音频设备断开连接结束为一个周期，在每个周期内，分包模块为设备虚拟化服务创建的每个解码器，创建一次对应的输入缓冲区。例如，分包模块初次拆分出来的某个音频类型的编码音频时，创建与该音频类型对应的解码器的输入缓冲区，之后，在该周期内，可直接通过该输入缓冲区接收并存储与该输入缓冲区对应的编码音频。

可选地，当检测到电子设备与车载音频设备断开连接时，分包模块销毁创建的输入缓冲区。这种实现方式，在一个周期结束时销毁创建的输入缓冲区，有效避免输入缓冲区长期占用系统资源，提高了资源利用率，提升了电子设备的性能。

可以理解的是，若在一个周期内，分包模块从未拆分出来某个音频类型对应的编码音频，则在该周期内可以不创建与该音频类型对应的解码器的输入缓冲区。这种实现方式，在有需求的情况下创建对应的输入缓冲区，可以有效降低资源的消耗，提高资源利用率。

可选地，分包模块还可以为每个解码器建立一个线程(thread)，线程用于提升该线程对应的流程的流畅性，保障该线程对应的流程不被其他线程对应的流程干扰。

例如，分包模块为第一解码器建立第一线程，为第二解码器建立第二线程，第一线程对应的流程为第一解码器从第一输入缓冲区中读取第一编码音频，第二线程对应的流程为第二解码器从第二输入缓冲区中读取第二编码音频。有了第一线程和第二线程的存在，第一解码器从第一输入缓冲区中读取第一编码音频的过程，与第二解码器从第二输入缓冲区中读取第二编码音频的过程互不干扰，提升了读取编码音频的流畅性。

可选地，合包模块还可以为拆分合包数据建立一个线程，如第三线程。该第三线程用于拆分合包数据的流程不被其他线程对应的流程干扰。

示例性地，各个解码器读取到编码音频后，对编码音频进行解码处理，得到解码音频。各个解码器将解码处理后得到的解码音频发送至音频播放模块，音频播放模块暂时存储各个解码音频，每间隔预设时长，将暂时存储的各个解码音频发送给音频框架。

可选地，音频播放模块还可以包括多个播放接口，通过播放接口可以访问音频框架。示例性地，各个解码器将解码处理后得到的解码音频通过播放接口发送给音频框架。例如，第一解码器将解码处理后得到的解码音频通过第一播放接口发送给音频框架；第二解码器将解码处理后得到的解码音频通过第二播放接口发送给音频框架。

音频框架获取播放策略，在接收到音频播放模块发送的各个解码音频后，根据播放策略播放和/或调整解码音频。这样使得车载音频设备可以独立地对每个音频进行播放、调整等操作，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

在一个示例性中，对合包数据进行分包处理，得到编码音频，可以包括：识别传输协议报头，解析合包数据中每个编码音频对应的数据头，根据每个数据头中的编码音频的数据包长度，依次拆分出每个编码音频(每个编码音频为一个数据包)。

示例性地，车载音频设备接收到合包数据后，识别出合包数据中的传输协议报头，快速确定该合包数据是经过合包处理得到的数据，从而对该合包数据进行解析。

针对每个编码音频，通过解析数据头中的属性信息，确定出编码音频对应的音频路由的标识、编码音频对应的音频类型、编码音频对应的应用程序、编码音频对应的数据包长度等。

再通过编码音频对应的数据包长度，在合包数据中准确地提取出编码音频。例如，获取数据头的结束位置，根据数据头的结束位置确定编码音频的起始位置，根据编码音频的起始位置和数据包长度，在合包数据中提取出该编码音频。

这种实现方式中，通过解析合包数据中的数据头，能够准确、快速地解析出每个编码音频，有利于后续车载音频设备快速对编码音频进行解码处理，从而独立地对每个音频进行播放、调整等操作。

上面结合系统架构对本申请实施例提供的音频传输方法进行了描述，下面结合流程图，对本申请实施例提供的音频传输方法进行描述。

请参阅图17，图17为本申请实施例示出的一种音频传输方法的流程示意图。该方法包括：

S501、发送音频分流指令以及跨设备音频流转能力启动指令。

S502、开启音频分流功能和跨设备音频流转功能。

S503、用户触发输入操作。

S504、接收多个应用程序生成的音频数据。

S505、将音频数据处理为子音频数据。

S506、通过音频路由转发子音频数据。

S507、通过虚拟音频服务转发子音频数据。

S508、对子音频数据进行编码处理，发送编码音频。

S509、对多个编码音频进行合包处理，得到合包数据。

S510、通过传输通道发送合包数据。

步骤S501至步骤S510的具体内容，可参考前文描述，此处不再赘述。

本申请实施例提供的音频传输方法，一方面，由于电子设备处理后的子音频数据所包含的数据是一个个单独的音轨数据(或者说子音频数据包含的每个数据都是不同类型的音频数据)，对这些单独的音轨数据分别编码后发送给车载音频设备，车载音频设备通过为编码音频创建的解码器，对编码音频进行解码处理后，得到解码音频也是一个个单独的音频(或者说得到的每个解码音频都是不同类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

另一方面，电子设备对编码音频进行合包处理，大大压缩了编码音频的数据量，使通过传输通道一次能够传输更多数据量的编码音频，提升了带宽利用率，提高了编码音频的传输速度。

请参阅图18，图18为本申请实施例示出的另一种音频传输方法的流程示意图。该方法包括：

S601、发送音频分流指令以及跨设备音频流转能力启动指令。

S602、开启音频分流功能和跨设备音频流转功能。

S603、用户触发输入操作。

S604、接收多个应用程序生成的音频数据。

S605、将音频数据处理为子音频数据。

S606、通过音频路由转发子音频数据。

S607、通过虚拟音频服务转发子音频数据。

S608、对子音频数据进行编码处理，发送编码音频。

S609、对编码音频进行合包处理，得到合包数据。

S610、通过传输通道发送合包数据。

S611、接收并发送合包数据。

S612、对合包数据进行分包处理，得到多个编码音频。

S613、对多个编码音频进行解码处理，得到多个解码音频。

S614、发送多个解码音频。

S615、根据播放策略播放多个解码音频。

步骤S601至步骤S615的具体内容，可参考前文描述，此处不再赘述。

在这种实现方式中，一方面，由于对多个编码音频进行了合包处理，最终是将合包数据发送至车载音频设备的传输通道，而不是将多个编码音频直接发送至车载音频设备的传输通道。因此，发送单元的数量大大减少(例如，原本发送三个编码音频需要三个发送单元，而这里只需一个发送单元即可)，有效提升了发送合包数据的效率，提升了电子设备与车载音频设备之间的带宽利用率。

另一方面，由于车载音频设备接收到的不是混音数据，而是一个个单独的编码音频，对编码音频进行解码处理后，得到的解码音频也是一个个单独的音频(或者说，解码得到的每个解码音频都是不同音频类型的音频)。因此，车载音频设备可以独立地对每个音频进行播放、调整等操作，譬如可以分别调整音乐、导航声音以及通话声音各自对应的音量大小，可以指定不同的扬声器播放不同类型的音频等。由此，本申请提供的音频处理方法，能够实现电子设备和车辆之间很多用于提升用户体验的优化场景，能够满足车辆音频播放的个性化需求，提高了车辆驾驶员和车辆乘客的驾乘体验。

下面以电子设备侧为主，描述本申请提供的音频传输方法，请参阅图19，图19为本申请实施例示出的又一种音频传输方法的流程示意图。该方法包括：

S701、获取多个编码音频。

S702、对多个编码音频进行合包处理，得到合包数据。

S703、通过预设的传输通道，将合包数据发送至车载音频设备。

步骤S701至步骤S703的具体内容，可参考前文描述，此处不再赘述。

在这种实现方式中，由于电子设备对编码音频进行合包处理，大大压缩了编码音频的数据量，使通过传输通道一次能够传输更多数据量的编码音频，提升了带宽利用率，提高了编码音频的传输速度。

下面以车载音频设备侧为主，描述本申请提供的音频传输方法，请参阅图20，图20为本申请实施例示出的又一种音频传输方法的流程示意图。该方法包括：

S801、接收通过预设的传输通道发送的合包数据。

S802、对合包数据进行分包处理，得到多个编码音频。

步骤S801至步骤S802的具体内容，可参考前文描述，此处不再赘述。

可选地，本申请实施例提供的音频传输方法，还可应用于电子设备之间有跨设备音频流转的交互场景中。例如，手机与平板电脑、手机与智慧屏、手机与计算机、平板电脑与智慧屏、平板电脑与计算机等的交互场景中。

示例性地，以手机与平板电脑之间的交互场景为例进行说明。例如，手机与平板电脑通过蓝牙建立通信连接，手机与平板电脑之间进行音频数据传输和音频数据处理。对于具体如何进行音频数据传输和音频数据处理，可以参考上述步骤S601至步骤S614中的描述，此处不再赘述。

本申请提供的音频传输方法，对发送的编码音频进行合包处理，大大压缩了编码音频的数据量，使得通过传输通道一次传输更多数据量的编码音频，提升了带宽利用率，提高了编码音频的传输速度，提高了用户体验。

下面结合附图对本申请实施例中涉及的电子设备的硬件结构进行简单介绍。

请参阅图21，图21为本申请一示例性实施例示出的电子设备的硬件结构示意图。

如图21所示，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本申请实施例示意的结构并不构成对电子设备100的具体限定。在本申请另一些实施例中，电子设备100可以包括比图21所示的部件更多或更少的部件，或者，电子设备100可以包括图21所示的部件中某些部件的组合，或者，电子设备100可以包括图21所示的部件中某些部件的子部件。图21所示的部件可以以硬件、软件、或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。

其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。其中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在本申请的实施例中，处理器110可以执行音频处理方法以及音频传输方法中的各个步骤。譬如处理器110可以运行本申请实施例提供的音频处理方法以及音频传输方法的软件代码。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器(mobileindustry processor interface，MIPI)接口，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

电子设备100的无线通信功能可以通过天线1、天线2、移动通信模块150、无线通信模块160、调制解调处理器以及基带处理器等器件实现。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及车载音频设备通信。

电子设备100可以通过GPU、显示屏194以及应用处理器实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU还可以用于执行数学和位姿计算，用于图形渲染等。处理器110可以包括一个或多个GPU，其执行程序指令可以生成或改变显示信息。

在本申请实施例中，显示屏194可以用于显示各个应用程序的界面。

本申请实施例中的显示屏194可以是触摸屏。该显示屏194中可以集成有触摸传感器180K。该触摸传感器180K也可以称为“触控面板”。也就是说，显示屏194可以包括显示面板和触摸面板，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触控操作。触摸传感器180K检测到的触摸操作后，可以由内核层的驱动(如TP驱动)传递给上层，以确定触控事件类型。可以通过显示屏194提供与触控操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

本申请实施例中提供的音频处理方法以及音频传输方法，可以在具有上述硬件结构的电子设备100中实现。

上文详细介绍了本申请实施例提供的音频处理方法以及音频传输方法的示例。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分为各个功能模块，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述音频处理方法以及音频传输方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备还可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、WiFi芯片等与其他电子设备交互的设备。

本申请实施例还提供了一种车载音频设备，该车载音频设备包括一个或多个处理器；一个或多个存储器；安装有多个应用程序的模块；存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得车载音频设备执行上述实施例中的音频处理方法以及音频传输方法。

本申请实施例还提供了一种车辆，该车辆包括：一个或多个处理器；一个或多个存储器；存储器存储有一个或多个程序，当一个或者多个程序被处理器执行时，使得该车辆执行上述实施例中的音频处理方法以及音频传输方法。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的音频处理方法以及音频传输方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的音频处理方法以及音频传输方法。

本申请实施例还提供了一种芯片。请参阅图22，图22为本申请实施例提供的一种芯片的结构示意图。图22所示的芯片可以为通用处理器，也可以为专用处理器。该芯片包括处理器310。其中，处理器310用于执行上述任一实施例的音频处理方法以及音频传输方法。

可选的，该芯片还包括收发器320，该收发器320用于接受处理器的控制，用于支持通信装置执行前述所示的技术方案。

可选的，图22所示的芯片还可以包括：存储介质330。

需要说明的是，图22所示的芯片可以使用下述电路或者器件来实现：一个或多个现场可编程门阵列(field programmable gate array，FPGA)、可编程逻辑器件(programmable logic device，PLD)、控制器、状态机、门逻辑、分立硬件部件、任何其他适合的电路、或者能够执行本申请通篇所描述的各种功能的电路的任意组合。

其中，本实施例提供的电子设备、车载音频设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims

1.一种音频处理方法，其特征在于，应用于电子设备的应用程序框架层，所述电子设备与车载音频设备连接，所述方法包括：

接收多个应用程序生成的音频数据；

将所述音频数据处理为子音频数据，所述子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个；所述混音子音频数据是对除所述媒体子音频数据、所述导航子音频数据以及所述通话子音频数据外的其他子音频数据进行混音处理得到的；

通过为所述子音频数据创建的对应数量的编码器，对所述子音频数据进行编码处理，得到编码音频；

通过预设的传输通道，将所述编码音频发送至所述车载音频设备；所述编码音频用于触发所述车载音频设备通过为所述编码音频创建的解码器，对所述编码音频进行解码处理，得到解码音频；所述解码音频用于所述车载音频设备根据播放策略播放所述解码音频；所述播放策略包括独立调整所述解码音频对应的播放音量，和/或通过指定扬声器播放与所述指定扬声器对应的解码音频。

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

获取所述子音频数据的音频类型；所述媒体子音频数据的音频类型为媒体音频类型，所述导航子音频数据的音频类型为导航音频类型，所述通话子音频数据的音频类型为通话音频类型，所述混音子音频数据的音频类型为混音音频类型；

创建与所述子音频数据的音频类型相匹配的编码器。

3.根据权利要求2所述的方法，其特征在于，所述电子设备还包括虚拟硬件抽象层，所述方法还包括：

通过所述虚拟硬件抽象层创建的音频路由，将所述子音频数据转发至与所述子音频数据相匹配的编码器中；所述音频路由与所述子音频数据的音频类型相匹配。

4.根据权利要求3所述的方法，其特征在于，所述子音频数据为所述通话子音频数据时，所述方法还包括：

通过所述虚拟硬件抽象层中的通话通道，将所述通话子音频数据传输至与所述通话子音频数据相匹配的编码器中。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述传输通道包括第一传输通道和第二传输通道，所述第一传输通道用于传输非通话音频子数据对应的编码音频，所述第二传输通道用于传输所述通话子音频数据对应的编码音频。

6.根据权利要求2至5任一项所述的方法，其特征在于，所述将所述音频数据处理为子音频数据，包括：

根据所述音频数据携带的不同的音频类型标识，从所述音频数据中识别出所述媒体子音频数据、所述导航子音频数据、所述通话子音频数据以及所述其他子音频数据中的至少两种；

若识别出所述其他子音频数据，对所述其他子音频数据进行混音处理，得到所述混音子音频数据。

7.根据权利要求6所述的方法，其特征在于，所述其他子音频数据包括通知子音频数据、警示子音频数据以及铃声子音频数据中的至少一个。

8.根据权利要求1至7任一项所述的方法，其特征在于，在所述接收多个应用程序生成的音频数据之前，所述方法还包括：

接收音频分流指令，所述音频分流指令用于指示将所述音频数据处理为所述子音频数据。

9.根据权利要求1至8任一项所述的方法，其特征在于，在所述接收多个应用程序生成的音频数据之前，所述方法还包括：

响应于针对所述多个应用程序的输入操作，生成所述音频数据；所述应用程序包括媒体类应用程序、导航类应用程序以及通话类应用程序中的至少一种。

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

接收所述电子设备与所述车载音频设备断开连接的指令，销毁所述编码器，并指示所述虚拟硬件抽象层销毁所述音频路由。

11.一种音频处理方法，其特征在于，应用于车载音频设备的应用程序框架层，所述车载音频设备与电子设备连接，所述方法包括：

接收通过预设的传输通道发送的编码音频；所述编码音频是所述电子设备的应用程序框架层通过为子音频数据创建的编码器，对所述子音频数据进行编码处理得到的；所述子音频数据是所述电子设备的应用程序框架层对音频数据进行处理得到的；所述音频数据是所述电子设备中的多个应用程序生成的；所述子音频数据包括媒体子音频数据、导航子音频数据、通话子音频数据、混音子音频数据中的至少一个；所述混音子音频数据是所述电子设备的应用程序框架层对除所述媒体子音频数据、所述导航子音频数据以及所述通话子音频数据外的其他子音频数据进行混音处理得到的；

通过为所述编码音频创建的解码器，对所述编码音频进行解码处理，得到解码音频；

根据播放策略播放所述解码音频；所述播放策略包括独立调整所述解码音频对应的播放音量，和/或通过指定扬声器播放与所述指定扬声器对应的解码音频。

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

获取所述编码音频对应的音频类型，所述媒体子音频数据的编码音频对应的音频类型为媒体音频类型，所述导航子音频数据的编码音频对应的音频类型为导航音频类型，所述通话子音频数据的编码音频对应的音频类型为通话音频类型，所述混音子音频数据的编码音频对应的音频类型为混音音频类型；

创建与所述编码音频对应的音频类型相匹配的解码器。

13.根据权利要求12所述的方法，其特征在于，所述指定扬声器包括驾驶座扬声器，与所述指定扬声器对应的解码音频的音频类型为所述导航音频类型。

14.一种电子设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行权利要求1至10中任一项所述的方法。

15.一种车载音频设备，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述车载音频设备执行权利要求11至13中任一项所述的方法。

16.一种车辆，其特征在于，包括：一个或多个处理器；一个或多个存储器；所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述车辆执行权利要求11至13中任一项所述的方法。

17.一种芯片，其特征在于，包括：处理器，用于从存储器中调用并运行计算机程序，使得安装有所述芯片的电子设备执行如权利要求1至10中任一项所述的方法，或使得安装有所述芯片的车载音频设备执行如权利要求11至13中任一项所述的方法。

18.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至11中任一项所述的方法，或使得所述处理器执行权利要求10至13中任一项所述的方法。