下一代软DSP产品采用了实时处理和宽带(高清晰度)语音通信技术，可以比当前技术取得更大的最终用户满意度和市场潜力。这些产品为语音通信建立了新的高清晰度标准。根据本文建议开发的产品可以取得超过电话质量通信的效果。相反，不满足这些实时要求将造成许多语音质量劣化的症状，包括掉话、显著的时延、爆破音或卡嗒声、传真/调制解调器呼叫失败或传真页错乱，以及由于丢包或超额延时造成的语音不清等等。不满足实时要求还将导致错过时限，这将是严重的系统故障，需要整个系统复位才能解决，除非系统支持硬件和软件的恢复。

电话呼叫中的语音通信是双向的：音频的发送和接收同时进行。因此尽量减小语音系统中的延时以确保音频质量很关键；然而，减小时延的优化工作与满足语音处理要求相冲突。在传统的回放音频系统中，如音频(MP3)回放或多媒体流，缓存可以做得很大以补偿系统处理能力的低下，此时延时与质量无关。语音引擎却不能这样做，因为音频缓存必须能在固定时间得到全部处理。这种架构通常采用中断优先级划分和软件调度，利用甚至在某些时候增强操作系统的实时性能来保证语音处理的完成。

在语音引擎系统中，软件中断服务程序将与语音硬件编解码器交换语音采样。语音硬件编解码器以8kHz的采样速率完成模拟信号与音频采样之间的来回转换。在电话应用中，硬件编解码器被连接到作为电话物理接口的用户线接口电路(SLIC)或无绳电话的DECT射频电路。而在IP电话或移动手机场合，硬件编解码器被连接到放大器，放大器再与麦克风和扬声器相连。

SoC硬件接口在保证语音引擎的实时性能和准确调度方面扮演着关键的角色。如果SoC带TDM或AC97外设，电话语音编解码器可以直接连到处理器。如果嵌入式处理器不带这些外设，最低成本的解决方案是经过一个CPLD再与处理器相连。CPLD可以从硬件编解码器逐个收发采样，这种方案对时间最敏感，并且代表了最坏情况下的时序要求。

不管是通过TDM、AC97还是CPLD，语音硬件服务必须优先处理以确保中断得到响应；其他系统软件必须不影响这个中断的关键时序。在8kHz的采样速率下，中断将每125μs发生一次。对于运行在200MHz的SoC来说，针对速度优化过的CPLD中断服务程序处理时间在25μs以内。这就允许最大中断延时的计算值为90μs(125μs–(25μs+中断服务建立时间10μs))。系统要想满足实时时限，操作系统必须在收到编解码器中断后的90μs内调用中断服务程序，并且操作系统必须允许服务运行并立即完成。

操作系统还必须保证中断服务程序可以调度语音引擎，以便立即对在音频缓存进行处理。中断服务程序使用缓存准备好信号激活这种调度，如图所示。在该图中可以看到，DMA外设用来将音频采样采集到缓存中供语音引擎的处理，这种方法的效率要比CPLD实现高。

对语音引擎的要求是要在下一个语音缓存准备好之前完成语音采样的处理。语音引擎中处理语音所需的时间取决于多个因素，包括处理器、缓存大小、RAM速度、物理语音接口数量(音频通道)、缓存要求的软件DSP处理以及所用的语音编码器类型。

要想全面地分析语音引擎时序要求，请参考附表。t_idle参数代表的是所有其他系统进程或系统应用程序留给可用处理的剩余时间。从语音引擎设计角度看，就是指空闲时间。所有较低优先级系统的处理都是发生在语音引擎完成实时语音处理后的空闲时间内。在最坏情况下，t_idle可能为0ms，此时语音引擎处理会有多次反复。

D2科技公司的vPort软件包含了针对所支持配置的性能基准。例如，vPort版本可能规定三方G.729AB语音会议呼叫的语音处理，作为最坏情况和缓存连续清空的条件下，要求语音引擎提供每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. 为了使质量最优，语音通信要求最小化系统时延；

2. 语音通信是连续的，丢失采样或失去实时性将是最严重的错误；

3. 语音硬件有严格的时序要求，在丢失时序时需要一种差错恢复机制；

4. 语音引擎实时处理必须在10ms的软件时限内完成对语音缓存的处理。语音引擎中断服务程序在CPU外设硬件基础上有严格的时序限制。

图1：语音引擎时序图。

表1：D2的语音引擎时序要求。