智能座艙主流音頻架構(gòu)設(shè)計方案

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

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

文/高林

整理/LiveVideoStack

大家好，我是高林，蔚來汽車座艙音頻系統(tǒng)軟件負(fù)責(zé)人，擁有十余年音頻系統(tǒng)開發(fā)經(jīng)驗。

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

下面來介紹座艙音頻現(xiàn)狀。

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

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

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

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

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

01

智能座艙主流音頻架構(gòu)設(shè)計

在座艙系統(tǒng)領(lǐng)域，目前不同車企采用的架構(gòu)各有不同。

這點與手機不同，目前手機行業(yè)基本分為兩大系統(tǒng)，即Android系統(tǒng)和Apple系統(tǒng)。這兩個系統(tǒng)在市場上占有率很高，因此消費者很難買到較為個性化的手機，每種手機的體驗都較為相似。

而目前各大車企在座艙中采用的架構(gòu)各不相同，市面上正在銷售的汽車的座艙系統(tǒng)，很難找到完全相同的座艙設(shè)計，這給消費者帶來了個性化、多樣化的選擇，但同時也給架構(gòu)設(shè)計帶來了挑戰(zhàn)。

目前，主流的兩種硬件方案可以分為單SOC和雙SOC。在單SOC中有一個Hypervisor的虛擬機架構(gòu)。Hypervisor虛擬機上可以跑其他的操作系統(tǒng)，有些支持QNX/Android架構(gòu)，有些支持QNX/Linux架構(gòu)的。單SOC和單系統(tǒng)架構(gòu)，有支持單Android架構(gòu)的，也有支持單Linux架構(gòu)的。雙SOC一般支持雙系統(tǒng)架構(gòu)，它有QNX/Android架構(gòu)，也支持Linux/Android架構(gòu)，以及Android/Android架構(gòu)。根據(jù)不同廠商的設(shè)計和需求，可以選擇不同的架構(gòu)。

可以看幾個案例：

第一類是單SOC、Hypervisor音頻架構(gòu)。如上圖，左邊為QNX系統(tǒng)，右邊是Android系統(tǒng)。

Android系統(tǒng)分為幾個簡單的層次，包括APP層、Framework層（中間層）、還有Hal（硬件適配層），以及Kernel層。圖上列了一些目前座艙基本都支持使用的典型APP，包括音樂類應(yīng)用、視頻類應(yīng)用、語音類應(yīng)用、TTS導(dǎo)航應(yīng)用、游戲應(yīng)用、廣播應(yīng)用。

QNX是傳統(tǒng)車廠使用的系統(tǒng)，包括儀表盤、一些簡單的廣播應(yīng)用，使用的就是QNX系統(tǒng)。報警音、AVAS（車外低速行駛音）、UPA、DVR（行車記錄儀）等與車機安全相關(guān)的、與車身本身的功能聯(lián)系較為緊密的功能，一般在QNX系統(tǒng)中做。其中，WTI與AVAS是法規(guī)規(guī)定要有的，也是傳統(tǒng)車機里面所必需的，所以集中在QNX這個輕量化的系統(tǒng)里面做，可以滿足法規(guī)的延時性需求。

單SOC的兩個系統(tǒng)之間通過Hypervisor這一虛擬的通信機制進(jìn)行通信。底層有專門給Audio（音頻）提供算法運行的單獨的處理單元，即ADSP，這也是大多數(shù)SOC廠商提供的架構(gòu)。

第二類是單SOC和單Android的音頻架構(gòu)。有些車廠會采用這種架構(gòu)，因為可以節(jié)省一些CPU資源。其中，Android架構(gòu)基本沒有變化，QNX中的一些功能會提升在Android的底層，比如Native層。這類輕量化的功能放在底層運行，延遲更低，處理起來更輕便，也能滿足法規(guī)要求。

第三類是雙SOC音頻架構(gòu)。雙SOC架構(gòu)擁有兩個SOC芯片，它的底層有兩路ADSP，同時擁有兩個CPU，因此算力較為富余。雙SOC架構(gòu)為了兼容Android的生態(tài)，能夠快速地將Android的APP移植進(jìn)來，一般需要有一個Android系統(tǒng)。另外一個系統(tǒng)可以根據(jù)各個廠商的要求，選擇QNX、Linux或Android系統(tǒng)。與法規(guī)相關(guān)的輕量化的功能，會單獨在一個系統(tǒng)里運行。

02

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

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

接著以單SOC與Hypervisor的架構(gòu)為例，介紹目前座艙音頻算法的集成方法。

從系統(tǒng)的層面來講，常用的集成方法是集成在Android Framework中。音效類的可以集成在Framework、APP、 HAL、Kernel、ADSP中，功放里面也可以集成一個音效算法。在QNX系統(tǒng)中，也可以有專門的Audio-Service來處理，它也可以集成一些音效算法。

常用的算法會集成在Framework、HAL、DSP、功放、QNX中，APP和Kernel則不是系統(tǒng)算法常用的集成方法。如果集成在單個APP中，可能只有單個的APP才能使用，不符合廠商車機的需求。如果集成在kernel中，由于Kernel是一個比較完整的系統(tǒng)，可能不符合架構(gòu)上的需求，對Kernel影響比較大，所以不常用。

下面介紹一些目前各個廠商的車機都會用到的、已經(jīng)落地的算法，包括算法的集成以及對體驗的影響。

電話ECNR算法是一種很常見的算法，從工程化的角度上來說，它的集成難點在于MIC錄音和參考信號相位對齊挑戰(zhàn)較大。

電話ENCR算法的一種方案是集成在APP中，多應(yīng)用于Voip通話方面。這種方案的底層錄音和參考信號的獲取通道，從底層延伸到最上層，還有一些與進(jìn)程調(diào)度相關(guān)的問題。因此，這種方案會帶來MIC錄音和參考信號相位抖動、難以對齊的問題，回聲消除效果難以保證。現(xiàn)在很多APP集成的ENCR算法，包括WebRTC，有些可能不是從底層直接獲取到參考信號，而是截流的從VIP應(yīng)用上播放的聲音的參考信號，所以處理效果更難以保證。

另一個方案是集成在Hal層，這種方案更為常見，一般車體里的藍(lán)牙電話就會用到這種方法。這個方法經(jīng)過的層級比較少，Kernel運行的性能較為穩(wěn)定，所以這個方案相位對齊較好，回聲消除效果也較好。這個方案的劣勢是，在CPU算力消耗比較高的情況下，Hal層的進(jìn)程也會受到影響，這時它的相位抖動和回聲消除效果也難以保證。

可以在底層獲取到錄音信號和參考信號時，將其拼接成一體，再從底層傳到上層。通過這種方式，錄音信號與參考信號在底層就能夠?qū)R，減少抖動。

第三種方案是集成在音頻專用的DSP中，例如ADSP中。這是最靠近錄音前端的一個方案，也是最優(yōu)的方案，適用于藍(lán)牙通話。

這種方案的相位抖動較少，信號對齊問題也不大，最關(guān)鍵的是，它采用一個單獨的處理單元，不會影響到CPU的算力。如果集成了較多功能，CPU受到影響，藍(lán)牙通話的回聲降噪效果也不會受到影響，這是其很大的優(yōu)勢之一。

目前各個新能源廠商基本都支持Karaoke功能。從集成的角度來看，這一功能最大的難點在于延時，例如通過話筒錄音再播放，這個過程的延時要短。如果延時太長，用戶就可能聽到自己唱歌的聲音，體驗不佳。

方案一是集成在Hal中。如圖所示，Karaoke的APP中帶有評分算法，用戶能夠播放伴奏，用話筒錄音，通過防嘯叫和修音算法，然后分出一路傳到APP上評分，另一路傳到ADSP，從AMP功放播出。這是集成在Hal的方案，當(dāng)然也可以選擇集成在APP中，但是因為延時太長，目前各個廠商都放棄了這種方案。

Hal的方案，延時可以達(dá)到50毫秒左右。除了延遲較小，這個方案還有一大優(yōu)勢是不依賴于SOC的供應(yīng)商，可以自主完成，工作量有保障。這個方案的劣勢是會受到CPU系統(tǒng)性能的影響，如果算力沒有富余，話筒錄音可能會有丟幀和雜音的風(fēng)險，延時難以保證。

方案二是集成在Kernel中，可以進(jìn)一步縮短Loopback延時，相較于集成在Hal層，可以減少7~8毫秒。

這個方案也會受到系統(tǒng)性能的影響，如果CPU消耗太高，可能也會有丟幀、雜音的風(fēng)險。它的劣勢之一是需要SOC供應(yīng)商提供技術(shù)支持，因為它對靠近底層的SOC硬件、DMV配合的依賴度較高，需要供應(yīng)商提供技術(shù)支持，所有很多廠商放棄了這種集成方案。

最后一種是理論上最好的一個方案，即集成在ADSP中。錄音通過Kernel傳到ADSP里面，最后直接播出。這個方案延時最短，并且單獨使用ADSP的功能，不會受到系統(tǒng)算力的影響。但這種方案的劣勢在于，它依賴供應(yīng)商支持。錄音要傳到CPU，再從CPU轉(zhuǎn)到ADSP，而話筒多數(shù)是用USB接口傳輸語音，基本現(xiàn)在的SOC廠商都不支持從USB接口傳到ADSP的功能，所以此方案雖然在理論上能給用戶最好體驗，但是推動起來技術(shù)難度非常高。目前，市面上基本沒有車廠采用這個方案。

再舉一個氛圍燈的案例。氛圍燈功能與車身的ECU聯(lián)系比較緊密，也是多數(shù)廠商都已經(jīng)落地的一個功能。它的技術(shù)難點之一是需要和音樂的節(jié)奏同步。

目前的車身ECU通過CAN信號傳輸而非互聯(lián)網(wǎng)。互聯(lián)網(wǎng)傳輸速度能達(dá)到千兆，而CAN的傳輸速度根據(jù)各個ECU的性能，有些ECU目前僅有幾十兆的傳輸帶寬，有些ECU能達(dá)到百兆的上傳帶寬，所以它的傳輸速度比較慢。

方案一是集成在APP里。在獲取到音樂的節(jié)奏、響度等信號后，通過Android系統(tǒng)的Framework傳到QNX系統(tǒng)的CANService，然后把CAN信號傳輸?shù)椒諊鸁舻腅CU中，也就是其他供應(yīng)商提供的氛圍燈的ECU中。

CAN信號的傳輸路徑在系統(tǒng)內(nèi)部比較長，再通過CAN總線傳到ECU上，信號的延時就更長。這種方案因為集成在APP中，所以只有單個APP才能使用氛圍燈的節(jié)奏同步。整個的CAN信號傳輸鏈路，目前可以達(dá)到200毫秒，雖然它目前也有很多約束性條件，例如它的同步算法需要在APP里進(jìn)行，同時如果CPU系統(tǒng)算力消耗過多，音樂和氛圍燈的節(jié)奏就會出現(xiàn)不同步現(xiàn)象。

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

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

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

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

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

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

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

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

03

音頻體驗與整車融合的挑戰(zhàn)

第一個挑戰(zhàn)是復(fù)雜的座艙內(nèi)音頻環(huán)境。與座艙相比，手機的音頻硬件環(huán)境更為簡單。主要表現(xiàn)為手機對MIC和喇叭的數(shù)量有一定限制，通常為兩到三個。然而，車艙的MIC數(shù)和揚聲器數(shù)則越來越多，對音頻算法的要求也越來越高。同時，座艙內(nèi)的聲學(xué)環(huán)境也比較復(fù)雜，尤其是車輛在中高速公路行駛的過程中會產(chǎn)生大量噪音，手機的算法挪用到車艙時對噪音的處理無法達(dá)到用戶的需求。許多廠商在嘗試各種方式來降低噪音或提升音效體驗，但目前音效算法的噪音處理效果大多無法滿足需求。

第二個挑戰(zhàn)是復(fù)雜的座艙音頻需求。一方面，隨著座艙內(nèi)部的MIC和揚聲器數(shù)越來越多，手機的音頻算法挪用到車機時無法滿足處理需求，所以需要對算法進(jìn)行重新開發(fā)和適配。同時，許多Android APP希望能在座艙內(nèi)適配和落地。因此，對音頻需求的落地速度和落地質(zhì)量要求也越來越高。

另一方面，多個大屏的音頻需求和分區(qū)播放音頻已成為未來的座艙發(fā)展趨勢。比如四座或六座車，每個座位前排都有一個單獨的大屏可以分區(qū)播放不同的音頻，使用不同的娛樂APP。目前谷歌專門給Android系統(tǒng)開發(fā)了車機版以適應(yīng)這些需求，未來其開發(fā)方向也沿著分區(qū)播放趨勢發(fā)展。

第三個挑戰(zhàn)是Android音頻架構(gòu)的大量定制化。Android系統(tǒng)是針對手機開發(fā)的操作系統(tǒng)，它的很多功能與手機融合得較好。由于車機的MIC和揚聲器數(shù)量較手機都增加較多，所以手機版Android對許多座艙音頻功能都不支持，蔚來對Android架構(gòu)修改較多。雖然谷歌也專門給Android系統(tǒng)開發(fā)了car版，但也無法滿足音頻處理的需求，也不支持Dolby的7.1.4和5.1聲道的播放。同時，目前的Android也不支持多個大屏的音頻需求定制和分區(qū)播放音頻定制，都需要進(jìn)行大量修改。

因此，盡管有些車機上有Android系統(tǒng)，許多APP仍然不能隨意安裝，需要各個廠商適配。每個廠家的Android系統(tǒng)都定制較多，第三方APP安裝到車機上需要考慮是否能和Android系統(tǒng)融合，是否會影響車機的安全性能。

從多聲道算法的集成角度來看，各廠商都在將手機的算法進(jìn)行重新開發(fā)和適配以適應(yīng)車機的多聲道等算法要求，搭建多聲道算法的集成架構(gòu)。

第四個挑戰(zhàn)是車身ECU的開發(fā)滯后。比如氛圍燈功能的移植，車身ECU的技術(shù)趕不上手機的技術(shù)前沿的體驗。

車身ECU開發(fā)滯后比較突出的體現(xiàn)是CAN信號的延時較大，因為車身ECU本身采用的是一些傳輸速度較慢的處理單元。這一方面目前各廠商也在進(jìn)行變革以解決該問題，比如嘗試將以太網(wǎng)應(yīng)用到車機ECU中。后續(xù)如果各個ECU能夠傳輸千兆帶寬，這一問題可能會得到緩解。目前有少量車機支持千兆以太網(wǎng)，但成本較高。

第五個挑戰(zhàn)是座艙系統(tǒng)算力瓶頸。目前，座艙SOC芯片基本是從手機SOC芯片衍生而來的，需要經(jīng)過一系列的車規(guī)認(rèn)證。例如高通開發(fā)的8155和8295車機芯片，相較于同類型的手機芯片，在算力等性能上有所提升。這類SOC芯片基本滿足在手機上應(yīng)用的算力需求，但應(yīng)用在座艙上時基本滿負(fù)荷運行。

此外，多MIC多揚聲器由于需要多通道處理、聲源定位等對座艙的算力消耗也較多。例如，座艙有4MIC、6MIC和四座、六座、七座之分，分區(qū)越多、座位越多消耗的算力也越高。座艙的多Camera應(yīng)用，包括UPA、DVR、360°全景守護功能對算力消耗也較大。還有多屏娛樂需求，比如每個屏幕播放不同音頻、視頻、游戲等。這些都是手機所不具備的功能。

雖然座艙領(lǐng)域這兩年剛受到關(guān)注，但隨著功能集成越來越多，算力的消耗已無法滿足用戶的需求，這是目前各個SOC廠商正在考慮的問題。

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

總體來說，今天介紹的內(nèi)容可以總結(jié)為四點：一是音頻對座艙體驗正變得越來越重要；二是座艙音頻系統(tǒng)軟件架構(gòu)和工程落地對音頻體驗有很大影響；三是座艙音頻需求越來越復(fù)雜，用戶對音頻體驗要求越來越高，這些給軟件架構(gòu)設(shè)計帶來了一些挑戰(zhàn)，也需要我們?nèi)ニ伎既绾谓鉀Q這些需求帶來的問題；最后，問題的解決不能單靠軟件結(jié)構(gòu)設(shè)計一方，需要我們業(yè)界共同努力，把挑戰(zhàn)變?yōu)闄C遇。

審核編輯：黃飛