在选择SoC和专用音频DSP时，这些问题你应该考虑到！

低延时、实时声学处理是许多嵌入式处理应用的关键因素，其中包括语音预处理、语音识别和主动降噪(ANC)。随着这些应用领域对实时性能的要求稳步提高，开发人员需要以战略思维来妥善应对这些要求。由于许多大型系统都由芯片提供可观的性能，因此我们往往会将出现的任何额外任务都加载到这些设备上，但我们需要知道，延时和其确定性是非常关键的因素，如果未仔细考虑，很容易引发重大的实时系统问题。本文将探讨设计人员在选择SoC和专用音频DSP时应考虑的问题，以避免实时声学系统出现令人不快的意外。

低延时声学系统的应用非常广泛。例如，单单是在汽车领域，低延时对于个人音频区域、路噪降噪和车内通讯系统等都至关重要。

随着汽车电气化趋势涌现，路噪降噪变得更加重要，因为没有内燃机产生明显噪音。所以，与汽车道路接触相关的噪音会变得更明显、更扰人。减少这种噪音不仅能带来更舒适的驾驶体验，还能减少驾驶员疲劳感。与在专用音频DSP上部署低延时声学系统相比，在SoC上部署会面临诸多挑战。这些问题包括延时、可扩展性、可升级性、算法考量、硬件加速和客户支持。我们来逐一进行介绍。

在实时声学处理系统中，延时问题非常重要。如果处理器跟不上系统的实时数据搬运和计算需求，会导致不可接受的音频断续。

一般来说，SoC会配备小型片内SRAM，因此，大部分本地存储器访问必须依赖缓存。这导致代码和数据的使用具有不确定性，还会增大处理延时。对于ANC这样的实时应用来说，单是这一点就无法接受。但是，事实上，SoC也会运行管理繁重的多任务非实时操作系统。这会放大系统的不确定性操作特性，使其很难在多任务环境中支持相对复杂的声学处理。

图1显示了一个运行实时音频处理负载的SoC的具体示例，在处理更高优先级的SoC任务时，CPU负载出现峰值。例如，在执行以SoC为中心的任务时，包括在系统上进行媒体渲染、浏览或执行应用，可能会出现这些峰值。当峰值超过100% CPU负载时，SoC将不再实时运行，这会导致音频丢失。

图1. 除了运行其他任务外，运行高音频负载处理的典型SoC的瞬时CPU负载。

另一方面，音频DSP的架构是为了在整个信号处理路径（从采样音频输入到处理（例如，音效+噪声抑制）到扬声器输出）中实现低延时。L1指令和数据SRAM是最接近处理器内核的单周期存储器，足以支持多个处理算法，无需将中间数据转存到片外存储器。此外，片内L2存储器（离内核较远，但访问速度仍然比片外DRAM快得多）可以在L1 SRAM的存储容量不够时，提供中间数据操作缓存。最后，音频DSP通常运行实时操作系统(RTOS)，确保可以在新输入数据到达之前完成输入数据处理并将其搬移到目标位置，从而确保数据缓冲区在实时操作期间不会上溢。

系统启动时的实际延时（通常通过启动发声来表征）也是重要指标，尤其是对于汽车系统，它要求在启动后的某个窗口内播报提示音。在SoC领域，通常采用很长的启动时序，其中包括启动整个设备的操作系统，所以很难或无法满足这个启动要求。另一方面，可以对运行自己的RTOS、不受其他无关的系统优先级影响的独立式音频DSP实施优化，以加快其启动速度，从而满足启动发声要求。

虽然在诸如噪声控制等应用中，对于SoC来说，延时是个问题，但对于想要执行声学处理的SoC来说，可扩展性是另一个缺点。换句话说，控制具有许多不同子系统的大型系统（例如汽车多媒体主机和仪表盘）的SoC无法轻易从低端扩展到满足高端音频需求，这是因为每个子系统组件的可扩展性需求之间始终存在冲突，需要在整体SoC利用率方面进行权衡。例如，如果前端SoC连接到远端收音模组，并且适配多种车型，那么该收音模组需要从几个通道扩展到多个通道，而每个通道都会加剧之前提到的实时问题。这是因为SoC控制下的每个附加特性都会改变SoC的实时行为，以及多个功能所使用的关键架构组件的资源可用性。这些资源包括存储器带宽、处理器内核周期和系统总线结构仲裁槽等方面。

除了有关连接到多任务SoC的其他子系统的问题外，声学系统本身也存在扩展性问题。其中涉及低端到高端的扩展（例如，增加ANC应用中麦克风和扬声器通道的数量），也涉及音频体验扩展，从基本的音频解码和立体声播放一直到3D虚拟化和其他高级功能。虽然这些要求不具有ANC系统的实时限制，但它们与系统音频处理器的选择直接相关。

使用一个单独的音频DSP作为SoC的协处理器是解决音频可扩展性问题的极佳解决方案，可以实现模块化的系统设计和成本优化的解决方案。SoC可以减少对大型系统实时声学处理需求的关注，将这种处理需求转移到低延时音频DSP上进行。此外，音频DSP提供代码兼容和引脚兼容选项，涵盖几种不同的价格/性能/存储容量等级，让系统设计人员能够最大限度地灵活选择适合给定产品层级的音频性能产品。

图2. ADSP-2156x DSP，高度可扩展的音频处理器。

随着如今的汽车越来越普遍地采用OTA，通过发布关键补丁或提供新功能进行升级变得越来越重要。由于其各个子系统之间的依赖性增加，这可能会导致SoC的关键问题。首先，多个处理和数据移动线程会在SoC上争夺资源。在添加新功能时，尤其是在处于活动高峰期间时，这会加剧处理器MIPS和存储空间的竞争。从音频的角度来看，其他SoC控制域中的新增特性可能会对实时声学性能产生无法预测的影响。这种情况带来的一个负面影响是：新功能必须在所有操作平面上进行交叉测试，导致彼此竞争的子系统的各种操作模式之间出现无数排列组合。所以，每个升级包的软件验证次数都会成倍增加。

从另一个角度来看，可以说除了受SoC控制的其他子系统的功能图谱外，SoC音频性能的改善还取决于可用的SoC MIPS。

显然，在开发实时声学算法时，音频DSP旨在达成任务目标。与SoC的显著区别在于，独立音频DSP可以提供图形化开发环境，让缺乏DSP编码经验的工程师能够在其设计中集成高质量的声学处理。这种类型的工具可以在不牺牲质量和性能的情况下通过缩短开发时间来降低开发成本。

例如，ADI的SigmaStudio®图形音频开发环境提供多种集成至直观的图形用户界面(GUI)的信号处理算法，从而能够创建复杂的音频信号流。它还支持采用图形A2B配置进行音频传输，非常有助于加快实时声学系统开发。

除了专为高效并行浮点计算和数据访问而设计的处理器内核架构外，音频DSP通常还采用专用的多通道加速器来运行通用算法，例如快速傅立叶变换(FFT)、有限和无限脉冲响应（FIR和IIR）滤波，以及异步采样速率转换(ASRC)。这样允许在内核CPU之外进行实时音频滤波、采样和频域转换，从而提高内核的有效性能。此外，由于它们采用优化的架构，提供数据流管理功能，所以有助于构建灵活且方便用户使用的编程模型。

由于音频通道数量、滤波器流、采样速率等增加，我们需要使用配置程度最高的引脚接口，以支持在线采样速率转换、精密时钟和同步高速串行端口来高效的路由数据，避免导致延时或外部接口逻辑增加。ADI的SHARC®系列处理器的数字音频互连口(DAI)就展现了这种能力，如图4所示。

图3. ADI公司的SigmaStudio图形开发环境。

图4. 数字音频互连(DAI)框图。

在使用嵌入式处理器进行开发时，我们常常会忽略一点，即客户对设备的支持。

尽管SoC供应商提倡在他们的内置DSP产品上运行声学算法，但在实际使用时这会带来一些负担。一方面，供应商的支持通常更复杂，因为SoC应用开发领域一般不涉及声学专业知识。因此，往往很难为想要基于SoC的片内DSP技术开发自己的声学算法的客户提供支持。而是由供应商提供标准算法，并收取可观的NRE费用，然后将声学算法移植到SoC的一个或多个内核中。即使如此，也无法保证一定能成功，在供应商无法提供成熟、低延时的框架软件时更是如此。最后，适合基于SoC的声学处理的第三方生态系统往往相当脆弱，因为这个领域不是SoC关注的重点。

显然，专用音频DSP可为开发复杂的声学系统提供更强大的生态系统，从优化的算法库和设备驱动程序到实时操作系统和易于使用的开发工具。此外，有助于加快产品上市的以音频为主的参考平台（例如ADI的SHARC音频模块平台，如图5所示）对于SoC来说比较少见，但在独立音频DSP领域却很常见。

图5. SHARC音频模块(SAM)开发平台。

总之，很明显，设计实时声学系统需要细致、战略性的规划系统资源，不能单单通过在多任务SoC上分配处理裕量来进行管理。相反，针对低延时处理而优化独立的音频DSP有望提高其耐用性，缩短开发时间，实现出色的可扩展性，以适应未来的系统需求和性能等级。