如何保證語音引擎設計的質(zhì)量和性能

目前無繩電話或IP電話使用的通用SoC集成了接入器件和統(tǒng)一的無線通信器件，并且在系統(tǒng)軟件中集成軟件語音引擎，可以完全支持VoIP要求的軟件數(shù)字信號處理。語音引擎采用了軟DSP(soft-DSP)實現(xiàn)技術，能夠滿足嵌入式處理器的系統(tǒng)性能要求。為了確保VoIP具有電話質(zhì)量的語音性能，系統(tǒng)軟件必須滿足語音引擎的實時要求。

下一代軟DSP產(chǎn)品采用了實時處理和寬帶(高清晰度)語音通信技術，可以比當前技術取得更大的最終用戶滿意度和市場潛力。這些產(chǎn)品為語音通信建立了新的高清晰度標準。根據(jù)本文建議開發(fā)的產(chǎn)品可以取得超過電話質(zhì)量通信的效果。相反，不滿足這些實時要求將造成許多語音質(zhì)量劣化的癥狀，包括掉話、顯著的時延、爆破音或卡嗒聲、傳真/調(diào)制解調(diào)器呼叫失敗或傳真頁錯亂，以及由于丟包或超額延時造成的語音不清等等。不滿足實時要求還將導致錯過時限，這將是嚴重的系統(tǒng)故障，需要整個系統(tǒng)復位才能解決，除非系統(tǒng)支持硬件和軟件的恢復。

電話呼叫中的語音通信是雙向的：音頻的發(fā)送和接收同時進行。因此盡量減小語音系統(tǒng)中的延時以確保音頻質(zhì)量很關鍵；然而，減小時延的優(yōu)化工作與滿足語音處理要求相沖突。在傳統(tǒng)的回放音頻系統(tǒng)中，如音頻(MP3)回放或多媒體流，緩存可以做得很大以補償系統(tǒng)處理能力的低下，此時延時與質(zhì)量無關。語音引擎卻不能這樣做，因為音頻緩存必須能在固定時間得到全部處理。這種架構通常采用中斷優(yōu)先級劃分和軟件調(diào)度，利用甚至在某些時候增強操作系統(tǒng)的實時性能來保證語音處理的完成。

在語音引擎系統(tǒng)中，軟件中斷服務程序將與語音硬件編解碼器交換語音采樣。語音硬件編解碼器以8kHz的采樣速率完成模擬信號與音頻采樣之間的來回轉換。在電話應用中，硬件編解碼器被連接到作為電話物理接口的用戶線接口電路(SLIC)或無繩電話的DECT射頻電路。而在IP電話或移動手機場合，硬件編解碼器被連接到放大器，放大器再與麥克風和揚聲器相連。

SoC硬件接口在保證語音引擎的實時性能和準確調(diào)度方面扮演著關鍵的角色。如果SoC帶TDM或AC97外設，電話語音編解碼器可以直接連到處理器。如果嵌入式處理器不帶這些外設，最低成本的解決方案是經(jīng)過一個CPLD再與處理器相連。CPLD可以從硬件編解碼器逐個收發(fā)采樣，這種方案對時間最敏感，并且代表了最壞情況下的時序要求。

不管是通過TDM、AC97還是CPLD，語音硬件服務必須優(yōu)先處理以確保中斷得到響應；其他系統(tǒng)軟件必須不影響這個中斷的關鍵時序。在8kHz的采樣速率下，中斷將每125μs發(fā)生一次。對于運行在200MHz的SoC來說，針對速度優(yōu)化過的CPLD中斷服務程序處理時間在25μs以內(nèi)。這就允許最大中斷延時的計算值為90μs(125μs–(25μs+中斷服務建立時間10μs))。系統(tǒng)要想滿足實時時限，操作系統(tǒng)必須在收到編解碼器中斷后的90μs內(nèi)調(diào)用中斷服務程序，并且操作系統(tǒng)必須允許服務運行并立即完成。

操作系統(tǒng)還必須保證中斷服務程序可以調(diào)度語音引擎，以便立即對在音頻緩存進行處理。中斷服務程序使用緩存準備好信號激活這種調(diào)度，如圖所示。在該圖中可以看到，DMA外設用來將音頻采樣采集到緩存中供語音引擎的處理，這種方法的效率要比CPLD實現(xiàn)高。

對語音引擎的要求是要在下一個語音緩存準備好之前完成語音采樣的處理。語音引擎中處理語音所需的時間取決于多個因素，包括處理器、緩存大小、RAM速度、物理語音接口數(shù)量(音頻通道)、緩存要求的軟件DSP處理以及所用的語音編碼器類型。

要想全面地分析語音引擎時序要求，請參考附表。t_idle參數(shù)代表的是所有其他系統(tǒng)進程或系統(tǒng)應用程序留給可用處理的剩余時間。從語音引擎設計角度看，就是指空閑時間。所有較低優(yōu)先級系統(tǒng)的處理都是發(fā)生在語音引擎完成實時語音處理后的空閑時間內(nèi)。在最壞情況下，t_idle可能為0ms，此時語音引擎處理會有多次反復。

D2科技公司的vPort軟件包含了針對所支持配置的性能基準。例如，vPort版本可能規(guī)定三方G.729AB語音會議呼叫的語音處理，作為最壞情況和緩存連續(xù)清空的條件下，要求語音引擎提供每10ms最大100MHz的處理能力。如果運行在400MHz RISC處理器上，t_voice在最壞情況處理時要求100MHz(CPU處理能力的25%)，對應每隔10ms處理間隔中的2.5ms處理時間。如果t_switch超過7.5ms(t_switch=t_buffer–(t_voice+t_idle))，實時時限就無法滿足，這個時間還不包括在語音引擎處理期間由于其他外設中斷、下半部處理或“tasklet”軟中斷引起的額外開銷。

以下是設計師在集成用于軟DSP處理的語音引擎時需要考慮的最重要的一些設計準則：

1. 為了使質(zhì)量最優(yōu)，語音通信要求最小化系統(tǒng)時延；

2. 語音通信是連續(xù)的，丟失采樣或失去實時性將是最嚴重的錯誤；

3. 語音硬件有嚴格的時序要求，在丟失時序時需要一種差錯恢復機制；

4. 語音引擎實時處理必須在10ms的軟件時限內(nèi)完成對語音緩存的處理。語音引擎中斷服務程序在CPU外設硬件基礎上有嚴格的時序限制。

圖1：語音引擎時序圖。

表1：D2的語音引擎時序要求。