近年來，智能座艙體驗日益成為汽車競爭力的核心，智能座艙的多樣體驗正在成為用戶購車時考慮的重要因素。

LiveVideoStack2023深圳站邀請到蔚來汽車座艙音頻系統軟件負責人高林，從主流音頻架構設計、算法集成方案及體驗影響、音頻體驗與整車融合的挑戰三個方面，為大家介紹音頻軟件架構設計是如何影響智能座艙體驗的。同時他希望通過此次分享，呼吁業界各方共同努力，大膽革新，化機遇為挑戰。

文/高林

整理/LiveVideoStack

大家好，我是高林，蔚來汽車座艙音頻系統軟件負責人，擁有十余年音頻系統開發經驗。

蔚來汽車NT1/NT2平臺座艙音頻系統的軟件架構設計和研發工作都由我負責，涉及到Android、QNX、Hypervisor等系統的音頻設計。今天與大家交流的主題是：汽車座艙音頻軟件架構中算法集成方面的設計，以及對音頻體驗產生的影響。近兩年，新能源汽車座艙這一領域發展較快，大家開始慢慢關注到這一行業。

下面來介紹座艙音頻現狀。

此前的傳統汽車，消費者對座艙的音頻體驗不太關注，只要能播放音樂、廣播就能滿足需求，關注更多的是汽車的駕駛性能或是乘坐性能。近兩年，隨著智能汽車行業逐漸發展之后，消費者開始提出新的要求，例如是否能支持互聯網接入、全景聲音樂和多聲道音樂體驗，是否能將游戲APP融入座艙，這些逐漸成為大家購車時的重要考慮因素。

由于座艙的獨特性，在駕駛的過程無法長時間通過屏幕觀看視頻，大眾相較于視頻會更關注音頻，因此，座艙音頻的重要性日益提升。座艙音頻也得到了車企的廣泛重視，音頻系統APP在座艙中的推進也越來越快。例如，在這一波智能座艙浪潮當中，蔚來汽車首先將Dolby全景聲功能集成到座艙中。半年之后，各個車廠便開始跟進這個功能。目前，Dolby全景聲基本已經成為了新發布的新能源車的標配。通過這個案例，可以有效感受到音頻功能在座艙推進的速度。

隨著消費者對體驗的要求越來越高，音頻的需求也在不斷增加。蔚來汽車每個月都會將許多APP添加到座艙當中，落地后便可以體驗。座艙里的麥克風和揚聲器的數量在不斷地提升，比如蔚來汽車第二代的座艙有23個喇叭，可以滿足消費者對于Dolby全景聲的體驗要求。

音頻需求的增加對算力提出了更高的要求。雖然智能座艙芯片SOC的算力，相較于手機有所提升，但是仍舊無法滿足座艙的要求，所以算力資源愈發緊張。正是由于算力有瓶頸，所以在來汽車在集成音頻功能，包括音頻的體驗算法時，就需要全方位考慮各類因素。因此后續會談談音頻領域的新挑戰，包括目前在架構設計方面遇到的問題該如何解決，希望能和業界同仁一起推動音頻技術在座艙領域更快更多運用。

接下來正式進入今天的主題。今天的主題分為三部分：首先介紹目前智能座艙的主流音頻架構設計，其次分析智能座艙音頻算法集成方案以及體驗影響，最后再談音頻體驗與整車功能融合方面的挑戰。

01

智能座艙主流音頻架構設計

在座艙系統領域，目前不同車企采用的架構各有不同。

這點與手機不同，目前手機行業基本分為兩大系統，即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系統。與法規相關的輕量化的功能，會單獨在一個系統里運行。

02

智能座艙音頻算法集成方案及體驗影響

從系統的角度出發，目前座艙常用的音頻算法可總結為五類。第一是語音交付類，目前使用較廣的是前端的算法、語音識別的算法；第二是語音通話類，包括回聲消除、降噪（即ECNR）等功能；第三是音樂音效類，包括了空間音效和Dolby全景聲、音場模式、AGC、DRC等算法；第四是K歌娛樂類，包括防嘯叫、降噪、評分、修音等功能；最后是與車身功能相關的功能，例如氛圍燈隨音樂律動、AVAS、3D WTI、RNC、ANC，以及主動降噪等功能。

接著以單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錄音和參考信號相位抖動、難以對齊的問題，回聲消除效果難以保證?，F在很多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系統算力消耗過多，音樂和氛圍燈的節奏就會出現不同步現象。

方案二是集成在Hal里。Hal層距離CANService更近，傳輸時間更短。該方案的優勢之一是不會受到單個APP的局限，所有的APP都可以使用氛圍燈算法。同時，與集成在App里相比，該方案氛圍燈CAN信號鏈路的傳輸時間短50ml以上，達到150ms。當在Hal里做音樂播放和氛圍燈節奏同步的算法時，如果CPU算力消耗比較多，Hal的節奏同步方案同樣也會受到影響，出現音樂和氛圍燈節奏不同步的現象。

方案三是集成在ADSP里。從理論上來看，該方案是最好的方案。首先，所有的音樂APP都能使用氛圍燈的功能。其次，氛圍燈CAN信號鏈路的時延最短，可達到100ms以上。此外，在ADSP里做節奏同步算法不會受到系統性能的影響。該方案的難點之一在于，由于SOC廠商提供的是一個約束性較強的處理單元，所以ADSP的內存有限，在CPU系統算力消耗較多時，音樂播放和氛圍燈節奏同步會受到影響，無法滿足需求。因此，雖然理論上這是很好的一個方案，但是由于種種約束條件，目前多數廠商未采用該方案。

總的來看，座艙架構設計影響音頻算法效果的因素主要有延時、抖動、性能消耗、集成難度和音頻硬件這幾點。從技術上看，前四點影響較大。

其中，延時包括音頻數據傳輸本身的延時、車身信號CAN信號傳輸和處理的延時以及對Karaoke和氛圍燈的影響；

抖動包括ECNR相位的需求，與其他相位比較，其處理要求更高、影響更大。此外，語音識別會用到聲源定位的算法，其對多MIC相位性要求較高；

從性能消耗因素來看，如果CPU算力不夠用，會對算法產生影響，出現丟幀、卡幀等現象；

從集成難度來看，需要考慮能否解決對外依賴的問題，能否推動SOC廠商解決成本問題、人力問題。一些理論上好的方案可能由于實際集成起來難度較大而無法采用；

從音頻硬件來看，MIC和喇叭的器件選型布局、電路布線、信噪比和揚聲器解析度都會影響聲音的播出效果和錄音效果。

03

音頻體驗與整車融合的挑戰

第一個挑戰是復雜的座艙內音頻環境。與座艙相比，手機的音頻硬件環境更為簡單。主要表現為手機對MIC和喇叭的數量有一定限制，通常為兩到三個。然而，車艙的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廠商正在考慮的問題。

以上提及的五點既是挑戰又是機遇，需要我們業界包括軟件的音頻架構設計、硬件的SOC廠商和汽車ECU等各方共同努力，積極革新，共同解決這些問題。

總體來說，今天介紹的內容可以總結為四點：一是音頻對座艙體驗正變得越來越重要；二是座艙音頻系統軟件架構和工程落地對音頻體驗有很大影響；三是座艙音頻需求越來越復雜，用戶對音頻體驗要求越來越高，這些給軟件架構設計帶來了一些挑戰，也需要我們去思考如何解決這些需求帶來的問題；最后，問題的解決不能單靠軟件結構設計一方，需要我們業界共同努力，把挑戰變為機遇。

審核編輯：黃飛