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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1：語(yǔ)音引擎時(shí)序圖。

表1：D2的語(yǔ)音引擎時(shí)序要求。