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

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

文/高林

整理/LiveVideoStack

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

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

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

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

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

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

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

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

01

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

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

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

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

目前，主流的兩種硬件方案可以分為單SOC和雙SOC。在單SOC中有一個(gè)Hypervisor的虛擬機(jī)架構(gòu)。Hypervisor虛擬機(jī)上可以跑其他的操作系統(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è)計(jì)和需求，可以選擇不同的架構(gòu)。

可以看幾個(gè)案例：

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

Android系統(tǒng)分為幾個(gè)簡單的層次，包括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)。報(bào)警音、AVAS（車外低速行駛音）、UPA、DVR（行車記錄儀）等與車機(jī)安全相關(guān)的、與車身本身的功能聯(lián)系較為緊密的功能，一般在QNX系統(tǒng)中做。其中，WTI與AVAS是法規(guī)規(guī)定要有的，也是傳統(tǒng)車機(jī)里面所必需的，所以集中在QNX這個(gè)輕量化的系統(tǒng)里面做，可以滿足法規(guī)的延時(shí)性需求。

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

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

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

02

智能座艙音頻算法集成方案及體驗(yàn)影響

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這個(gè)方案也會(huì)受到系統(tǒng)性能的影響，如果CPU消耗太高，可能也會(huì)有丟幀、雜音的風(fēng)險(xiǎn)。它的劣勢之一是需要SOC供應(yīng)商提供技術(shù)支持，因?yàn)樗鼘拷讓拥腟OC硬件、DMV配合的依賴度較高，需要供應(yīng)商提供技術(shù)支持，所有很多廠商放棄了這種集成方案。

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

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

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

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

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

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

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

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

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

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

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

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

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

03

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

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

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：黃飛