无论最终产品是什么，无论他们使用什么语言编写代码，世界各地的软件开发人员都面临着同样的挑战——不断变化的客户需求、紧迫的交期、整合和客户支持，以上只是几个例子。
但是有一种类型的软件开发涉及了解和解决非常具体的问题。音频信号处理产品的设计和编码软件有其独特的挑战。那么，开发人员最常犯的错误是什么？如何避免这些错误呢？
了解信号处理对于在音频领域工作的软件工程师很有帮助，但这不是必需的。然而，有些领域对音频有一些了解确实有所帮助。
首先，是增益结构，了解音量控制可以为我们的系统增加增益。这适用于我们软件的内部结构，并将影响我们插入原型的所有小工具。结果可能是声音输出令人不满意。开发人员以为这是由于代码中的错误造成的，而实际上这是增益结构的问题。知道这一点可以在不必要的调试中节省大量时间。
其次，软件开发人员有时会忘记音频滤波会增加群延迟。如果我们忘记了这个基本事实，我们可能会过分承诺我们的算法的性能，我们会认为它会比实际行动得更快。
第三，一个虽然很小但很重要的点是实际数据和理论数据之间的差异。数学有零，但音频没有。在数学中，算法的设计使用理论数据。当使用实际数据测试我们的系统时，我们可能会发现一个信号似乎是无声的。在那种情况下，放大它总是值得的——它可能有点嘶嘶声，也可能全是零。
最后，我们不可能只采用一种算法并将其部署在所有设备上。我们需要在开发过程中尽早考虑我们的算法将要有的部署约束条件。一些DSP非常高效且功耗低，但它们的内存可能有限。其他的可能非常适合用于AI处理，但它们会引入更高的延迟。如果你能设计一个权衡空间和时间的算法，那就太好了。但实际上，大多数算法无法做到这一点，因此我们可能会发现自己无法获得功耗最低的嵌入式设备。
在任何开发中，在开发开始之前了解客户需求是必不可少的。但在处理音频时，这一点更为重要。为什么呢？因为对于音频，客户不仅需要一个运行良好的系统，他们还需要一个可以输出出色音频的系统。问题是每个人听到的声音都不一样(例如，年龄会影响听力敏锐度)，而且我们对听起来“好”的声音都有个人偏好。我们可能会发现我们花了很长时间开发的一种产品，最终客户根本不喜欢。
对于大多数音频开发人员来说，这是一个持续存在的问题。音频的评估比视觉算法的评估更难。这是为什么？因为视觉结果可以并排放置并同时将它们相互进行比较。但你不能同时比较音频：你不能同时听两件事。因此，音频结果的A/B测试只能是顺序的，不能同时进行。所以，测试音频需要更长的时间，我们可能需要听两个小时的测试录音仅仅是为了评估对算法的小调整。我们要确保项目的计划包含有比我们认为需要的更长的测试时间。
我们可以通过商定使用一种普遍被接受的音频测试指标(例如MOS分数)来避免这种主观性。这些输入的音频和预期所需的观众对结果的评价。确实有助于评估质量，但不会给我们提供改进的原因。许多常见的测试和指标是为有线电话等传统的现有应用开发的，并且偏向于这些应用。因此，使用指标会有所帮助，但这不是绝对的答案。在我们开始工作之前，要确保我们的客户把他们的愿景告诉我们，因为他们希望音频听起来像什么，这一点至关重要。
了解客户的愿景对于下一个要注意的问题整合也很重要。我们的音频是系统的一部分。所有部分都必须协同工作，但系统的其余部分受处理音频的消耗限制，而我们的音频也受系统其余部分消耗的限制。如果音频在实际的系统上断断续续，那么在空的系统上开发运行良好的东西是没有意义的，而且会浪费很多资源。所以，早点整合吧。但是，正如开发人员都知道的，整合的成本很高。为了防止将时间浪费在整合不合适的内容上，我们首先需要与客户交谈。并且，在开始开发之前，获取所选用例中的一些录音样本，同时预览它们或离线工作来估计我们将能够实现的目标并确保它符合客户的愿景。
开发人员会犯的一个常见错误是在开发过程中没有尽早获得软件流。这很重要，因为如果我们不尽早进行流式传输，我们可能会要处理导致结果过分承诺的文件。如果我们正在编写一种算法，它每访问一位音频就向数据结构添加一个成分，则数据结构的大小与我们正在处理的文件的大小成正比。然而，一旦文件被音频流替换，数据结构可能会在设备运行时无限增大。通过尽早流式传输，可以降低开发风险，并且可以进一步确保我们的算法已准备好进行大规模生产。
另外，从一开始就考虑测试过程。仅通过音频输出进行测试很困难，因为它是实数信号。要确保尽可能多地进行单元测试，而不是依赖于不同处理器和平台之间可能不同的音频输出。
查看编码过程本身，我们需要在定点和浮点之间做出决定。定点曾经是表示用于存储和计算的音频样本的“go to”方法。定点计算将使用与整数计算相同的ALU部件，一个简单的数学技巧是大致估计连续变化的数量，在精度和数量大小之间进行权衡。
浮点在ALU中实现起来更复杂，但在现代CPU中(例如在移动设备中)使用它几乎没有或完全没有损失。存在的损失被工程时间要求的减少和用于优化算法的时间量的增加所抵消。音频算法通常庞大而复杂，而浮点可以用更少的工程资源实现它们，因为它简化了运算。使用浮点数的开发人员无需担心整数上溢或下溢。
关于手机，值得记住的是，手机中通常使用的CPU不仅会处理浮点运算，还会将其矢量化。因此，如果这是我们的用例，请确保我们设计的代码能够进行矢量化。
另一个技巧是在试验系统行为时将音频大量写入文件。根据我们写入的介质，我们可能需要一个工作线程，例如一张SD卡。这个工作线程就像一个软件管家，我们可以将音频数据提供给它；它耐心等待，然后将其交给设备。这意味着我们的核心算法不必等待和阻止运行时的行为。如果要写入多个文件，请检查它们是否都从同一位置开始。例如，如果我们停止其中一个文件的开头40ms，我们会发现系统中会出现无法解释的40ms延迟。
在音频信号处理方面，粗心的人会遇到很多陷阱。但是，通过正确的准备，我们可以通往成功的产品开发。
(原文刊登于EDN姊妹网站Embedded，参考链接：Common mistakes in audio signal processing – and how to avoid them，由Ricardo Xie编译。)
最前沿的电子设计资讯
