座舱音频系统的架构设计和音频体验

此前的传统汽车，消费者对座舱的音频体验不太关注，只要能播放音乐、广播就能满足需求，关注更多的是汽车的驾驶性能或是乘坐性能。近两年，随着智能汽车行业逐渐发展之后，消费者开始提出新的要求，例如是否能支持互联网接入、全景声音乐和多声道音乐体验，是否能将游戏APP融入座舱，这些逐渐成为大家购车时的重要考虑因素。

由于座舱的独特性，在驾驶的过程无法长时间通过屏幕观看视频，大众相较于视频会更关注音频，因此，座舱音频的重要性日益提升。座舱音频也得到了车企的广泛重视，音频系统APP在座舱中的推进也越来越快。例如，在这一波智能座舱浪潮当中，蔚来汽车首先将Dolby全景声功能集成到座舱中。半年之后，各个车厂便开始跟进这个功能。目前，Dolby全景声基本已经成为了新发布的新能源车的标配。通过这个案例，可以有效感受到音频功能在座舱推进的速度。

随着消费者对体验的要求越来越高，音频的需求也在不断增加。蔚来汽车每个月都会将许多APP添加到座舱当中，落地后便可以体验。座舱里的麦克风和扬声器的数量在不断地提升，比如蔚来汽车第二代的座舱有23个喇叭，可以满足消费者对于Dolby全景声的体验要求。

音频需求的增加对算力提出了更高的要求。虽然智能座舱芯片SOC的算力，相较于手机有所提升，但是仍旧无法满足座舱的要求，所以算力资源愈发紧张。正是由于算力有瓶颈，所以在来汽车在集成音频功能，包括音频的体验算法时，就需要全方位考虑各类因素。因此后续会谈谈音频领域的新挑战，包括目前在架构设计方面遇到的问题该如何解决，希望能和业界同仁一起推动音频技术在座舱领域更快更多运用。

接下来正式进入今天的主题。今天的主题分为三部分：首先介绍目前智能座舱的主流音频架构设计，其次分析智能座舱音频算法集成方案以及体验影响，最后再谈音频体验与整车功能融合方面的挑战。

在座舱系统领域，目前不同车企采用的架构各有不同。

这点与手机不同，目前手机行业基本分为两大系统，即Android系统和Apple系统。这两个系统在市场上占有率很高，因此消费者很难买到较为个性化的手机，每种手机的体验都较为相似。

而目前各大车企在座舱中采用的架构各不相同，市面上正在销售的汽车的座舱系统，很难找到完全相同的座舱设计，这给消费者带来了个性化、多样化的选择，但同时也给架构设计带来了挑战。

目前，主流的两种硬件方案可以分为单SOC和双SOC。在单SOC中有一个Hypervisor的虚拟机架构。Hypervisor虚拟机上可以跑其他的操作系统，有些支持QNX/Android架构，有些支持QNX/Linux架构的。单SOC和单系统架构，有支持单Android架构的，也有支持单Linux架构的。双SOC一般支持双系统架构，它有QNX/Android架构，也支持Linux/Android架构，以及Android/Android架构。根据不同厂商的设计和需求，可以选择不同的架构。

可以看几个案例：

第一类是单SOC、Hypervisor音频架构。如上图，左边为QNX系统，右边是Android系统。

Android系统分为几个简单的层次，包括APP层、Framework层（中间层）、还有Hal（硬件适配层），以及Kernel层。图上列了一些目前座舱基本都支持使用的典型APP，包括音乐类应用、视频类应用、语音类应用、TTS导航应用、游戏应用、广播应用。

QNX是传统车厂使用的系统，包括仪表盘、一些简单的广播应用，使用的就是QNX系统。报警音、AVAS（车外低速行驶音）、UPA、DVR（行车记录仪）等与车机安全相关的、与车身本身的功能联系较为紧密的功能，一般在QNX系统中做。其中，WTI与AVAS是法规规定要有的，也是传统车机里面所必需的，所以集中在QNX这个轻量化的系统里面做，可以满足法规的延时性需求。

单SOC的两个系统之间通过Hypervisor这一虚拟的通信机制进行通信。底层有专门给Audio（音频）提供算法运行的单独的处理单元，即ADSP，这也是大多数SOC厂商提供的架构。

第二类是单SOC和单Android的音频架构。有些车厂会采用这种架构，因为可以节省一些CPU资源。其中，Android架构基本没有变化，QNX中的一些功能会提升在Android的底层，比如Native层。这类轻量化的功能放在底层运行，延迟更低，处理起来更轻便，也能满足法规要求。

第三类是双SOC音频架构。双SOC架构拥有两个SOC芯片，它的底层有两路ADSP，同时拥有两个CPU，因此算力较为富余。双SOC架构为了兼容Android的生态，能够快速地将Android的APP移植进来，一般需要有一个Android系统。另外一个系统可以根据各个厂商的要求，选择QNX、Linux或Android系统。与法规相关的轻量化的功能，会单独在一个系统里运行。

接着以单SOC与Hypervisor的架构为例，介绍目前座舱音频算法的集成方法。

从系统的层面来讲，常用的集成方法是集成在Android Framework中。音效类的可以集成在Framework、APP、 HAL、Kernel、ADSP中，功放里面也可以集成一个音效算法。在QNX系统中，也可以有专门的Audio-Service来处理，它也可以集成一些音效算法。

常用的算法会集成在Framework、HAL、DSP、功放、QNX中，APP和Kernel则不是系统算法常用的集成方法。如果集成在单个APP中，可能只有单个的APP才能使用，不符合厂商车机的需求。如果集成在kernel中，由于Kernel是一个比较完整的系统，可能不符合架构上的需求，对Kernel影响比较大，所以不常用。

下面介绍一些目前各个厂商的车机都会用到的、已经落地的算法，包括算法的集成以及对体验的影响。

电话ECNR算法是一种很常见的算法，从工程化的角度上来说，它的集成难点在于MIC录音和参考信号相位对齐挑战较大。

电话ENCR算法的一种方案是集成在APP中，多应用于Voip通话方面。这种方案的底层录音和参考信号的获取通道，从底层延伸到最上层，还有一些与进程调度相关的问题。因此，这种方案会带来MIC录音和参考信号相位抖动、难以对齐的问题，回声消除效果难以保证。现在很多APP集成的ENCR算法，包括WebRTC，有些可能不是从底层直接获取到参考信号，而是截流的从VIP应用上播放的声音的参考信号，所以处理效果更难以保证。

另一个方案是集成在Hal层，这种方案更为常见，一般车体里的蓝牙电话就会用到这种方法。这个方法经过的层级比较少，Kernel运行的性能较为稳定，所以这个方案相位对齐较好，回声消除效果也较好。这个方案的劣势是，在CPU算力消耗比较高的情况下，Hal层的进程也会受到影响，这时它的相位抖动和回声消除效果也难以保证。

可以在底层获取到录音信号和参考信号时，将其拼接成一体，再从底层传到上层。通过这种方式，录音信号与参考信号在底层就能够对齐，减少抖动。

第三种方案是集成在音频专用的DSP中，例如ADSP中。这是最靠近录音前端的一个方案，也是最优的方案，适用于蓝牙通话。

这种方案的相位抖动较少，信号对齐问题也不大，最关键的是，它采用一个单独的处理单元，不会影响到CPU的算力。如果集成了较多功能，CPU受到影响，蓝牙通话的回声降噪效果也不会受到影响，这是其很大的优势之一。

目前各个新能源厂商基本都支持Karaoke功能。从集成的角度来看，这一功能最大的难点在于延时，例如通过话筒录音再播放，这个过程的延时要短。如果延时太长，用户就可能听到自己唱歌的声音，体验不佳。

方案一是集成在Hal中。如图所示，Karaoke的APP中带有评分算法，用户能够播放伴奏，用话筒录音，通过防啸叫和修音算法，然后分出一路传到APP上评分，另一路传到ADSP，从AMP功放播出。这是集成在Hal的方案，当然也可以选择集成在APP中，但是因为延时太长，目前各个厂商都放弃了这种方案。

Hal的方案，延时可以达到50毫秒左右。除了延迟较小，这个方案还有一大优势是不依赖于SOC的供应商，可以自主完成，工作量有保障。这个方案的劣势是会受到CPU系统性能的影响，如果算力没有富余，话筒录音可能会有丢帧和杂音的风险，延时难以保证。

方案二是集成在Kernel中，可以进一步缩短Loopback延时，相较于集成在Hal层，可以减少7~8毫秒。

这个方案也会受到系统性能的影响，如果CPU消耗太高，可能也会有丢帧、杂音的风险。它的劣势之一是需要SOC供应商提供技术支持，因为它对靠近底层的SOC硬件、DMV配合的依赖度较高，需要供应商提供技术支持，所有很多厂商放弃了这种集成方案。

最后一种是理论上最好的一个方案，即集成在ADSP中。录音通过Kernel传到ADSP里面，最后直接播出。这个方案延时最短，并且单独使用ADSP的功能，不会受到系统算力的影响。但这种方案的劣势在于，它依赖供应商支持。录音要传到CPU，再从CPU转到ADSP，而话筒多数是用USB接口传输语音，基本现在的SOC厂商都不支持从USB接口传到ADSP的功能，所以此方案虽然在理论上能给用户最好体验，但是推动起来技术难度非常高。目前，市面上基本没有车厂采用这个方案。

再举一个氛围灯的案例。氛围灯功能与车身的ECU联系比较紧密，也是多数厂商都已经落地的一个功能。它的技术难点之一是需要和音乐的节奏同步。

目前的车身ECU通过CAN信号传输而非互联网。互联网传输速度能达到千兆，而CAN的传输速度根据各个ECU的性能，有些ECU目前仅有几十兆的传输带宽，有些ECU能达到百兆的上传带宽，所以它的传输速度比较慢。

方案一是集成在APP里。在获取到音乐的节奏、响度等信号后，通过Android系统的Framework传到QNX系统的CANService，然后把CAN信号传输到氛围灯的ECU中，也就是其他供应商提供的氛围灯的ECU中。

CAN信号的传输路径在系统内部比较长，再通过CAN总线传到ECU上，信号的延时就更长。这种方案因为集成在APP中，所以只有单个APP才能使用氛围灯的节奏同步。整个的CAN信号传输链路，目前可以达到200毫秒，虽然它目前也有很多约束性条件，例如它的同步算法需要在APP里进行，同时如果CPU系统算力消耗过多，音乐和氛围灯的节奏就会出现不同步现象。

总的来看，座舱架构设计影响音频算法效果的因素主要有延时、抖动、性能消耗、集成难度和音频硬件这几点。从技术上看，前四点影响较大。

其中，延时包括音频数据传输本身的延时、车身信号CAN信号传输和处理的延时以及对Karaoke和氛围灯的影响；

抖动包括ECNR相位的需求，与其他相位比较，其处理要求更高、影响更大。此外，语音识别会用到声源定位的算法，其对多MIC相位性要求较高；

从性能消耗因素来看，如果CPU算力不够用，会对算法产生影响，出现丢帧、卡帧等现象；

从集成难度来看，需要考虑能否解决对外依赖的问题，能否推动SOC厂商解决成本问题、人力问题。一些理论上好的方案可能由于实际集成起来难度较大而无法采用；

从音频硬件来看，MIC和喇叭的器件选型布局、电路布线、信噪比和扬声器解析度都会影响声音的播出效果和录音效果。

第二个挑战是复杂的座舱音频需求。一方面，随着座舱内部的MIC和扬声器数越来越多，手机的音频算法挪用到车机时无法满足处理需求，所以需要对算法进行重新开发和适配。同时，许多Android APP希望能在座舱内适配和落地。因此，对音频需求的落地速度和落地质量要求也越来越高。

另一方面，多个大屏的音频需求和分区播放音频已成为未来的座舱发展趋势。比如四座或六座车，每个座位前排都有一个单独的大屏可以分区播放不同的音频，使用不同的娱乐APP。目前谷歌专门给Android系统开发了车机版以适应这些需求，未来其开发方向也沿着分区播放趋势发展。

第三个挑战是Android音频架构的大量定制化。Android系统是针对手机开发的操作系统，它的很多功能与手机融合得较好。由于车机的MIC和扬声器数量较手机都增加较多，所以手机版Android对许多座舱音频功能都不支持，蔚来对Android架构修改较多。虽然谷歌也专门给Android系统开发了car版，但也无法满足音频处理的需求，也不支持Dolby的7.1.4和5.1声道的播放。同时，目前的Android也不支持多个大屏的音频需求定制和分区播放音频定制，都需要进行大量修改。

因此，尽管有些车机上有Android系统，许多APP仍然不能随意安装，需要各个厂商适配。每个厂家的Android系统都定制较多，第三方APP安装到车机上需要考虑是否能和Android系统融合，是否会影响车机的安全性能。

从多声道算法的集成角度来看，各厂商都在将手机的算法进行重新开发和适配以适应车机的多声道等算法要求，搭建多声道算法的集成架构。

第四个挑战是车身ECU的开发滞后。比如氛围灯功能的移植，车身ECU的技术赶不上手机的技术前沿的体验。

车身ECU开发滞后比较突出的体现是CAN信号的延时较大，因为车身ECU本身采用的是一些传输速度较慢的处理单元。这一方面目前各厂商也在进行变革以解决该问题，比如尝试将以太网应用到车机ECU中。后续如果各个ECU能够传输千兆带宽，这一问题可能会得到缓解。目前有少量车机支持千兆以太网，但成本较高。

第五个挑战是座舱系统算力瓶颈。目前，座舱SOC芯片基本是从手机SOC芯片衍生而来的，需要经过一系列的车规认证。例如高通开发的8155和8295车机芯片，相较于同类型的手机芯片，在算力等性能上有所提升。这类SOC芯片基本满足在手机上应用的算力需求，但应用在座舱上时基本满负荷运行。

此外，多MIC多扬声器由于需要多通道处理、声源定位等对座舱的算力消耗也较多。例如，座舱有4MIC、6MIC和四座、六座、七座之分，分区越多、座位越多消耗的算力也越高。座舱的多Camera应用，包括UPA、DVR、360°全景守护功能对算力消耗也较大。还有多屏娱乐需求，比如每个屏幕播放不同音频、视频、游戏等。这些都是手机所不具备的功能。

虽然座舱领域这两年刚受到关注，但随着功能集成越来越多，算力的消耗已无法满足用户的需求，这是目前各个SOC厂商正在考虑的问题。

总体来说，今天介绍的内容可以总结为四点：一是音频对座舱体验正变得越来越重要；二是座舱音频系统软件架构和工程落地对音频体验有很大影响；三是座舱音频需求越来越复杂，用户对音频体验要求越来越高，这些给软件架构设计带来了一些挑战，也需要我们去思考如何解决这些需求带来的问题；最后，问题的解决不能单靠软件结构设计一方，需要我们业界共同努力，把挑战变为机遇。

谢谢大家！