声音（目标声音和噪音）一起被智能硬件的麦克风（阵列）采集到，在智能硬件的芯片上通过预处理之后，然后再送往云端进行ASR（语音转文字）。
而很多智能硬件识别效果不好的主要原因是因为预处理，也就是声学处理没有做好，才导致识别效果不好。 就像人耳朵一样，没听清楚讲话内容，可不得乱猜一通！
现在，云端的语音识别（ASR）可以通过SDK/API进行调用，大厂提供的识别接口背后所使用的算法和效果基本都差不多。毕竟，开源算法和大数据训练一起结合，在安静场景下，或者说送给云端一段干净的音频，准确率保持在98%以上都没有任何问题。
如果声学处理没有做好，送给云端的就是一段带噪声的音频，如果是人与人通话还好，毕竟人的判别能力很强。但如果给语音识别算法来处理噪声没有处理好的音频，输出的结果就会差强人意，而且，即便如何优化云端识别算法，像热词、大模型下打小模型这些做法，依然不能有效优化识别的准确率。
首先，我们要了解，麦克风（阵列）采集到的声音里面都有那些音源。从组成类型来看，包括：
- 目标人声音：希望提出出来转成文字的语音，越干净越好，专业术语是信噪比（SNR）越高越好，至少5dB及以上；
- 混响声音：主要是在室内，目标人讲话的声音通过墙壁、地板、天花板等反弹之后的声音，类似山谷里面的回声；
- 背景音：目标人所在环境的一些噪音，如室外的鸣笛声、风噪、行人交谈声音；室内常见的是电视播放的声音、风扇空调工作声音等等；
- 设备自发声：如音箱播放的音乐声，机器人的语音播报声等等。
然后，根据不同的类型音源，就需要采用不同的算法来进行处理。
设备自发声，可以通过回声消除算法来进行解决，通过设计硬回采电路，把喇叭的声音连回麦克风，叠加相反的波形实现设备自发声的消除。不过，要想回声消除效果好，在做结构设计的时候，建议喇叭和麦克风离得越远越好。部分芯片支持软回采，也就是硬件方案上不用单独设计回采电路，不过，从效果上来看，硬回采优于软回采。
混响声音，可以通过去混响算法进行解决。一般来说，基本的去混响算法就可以达到不错的效果，不过，对于一些复杂的环境，去混响的算法尽可能在实际场景中进行实验和调试，以保证最佳效果。还要注意的是，去混响之后，对本身音频也会产生副作用，如失真或声音质量降低，这些不利的影响也要纳入整体效果的考虑中来。
背景音，就需要用到预处理中的最重要的降噪算法了。降噪一般分为通话降噪和环境降噪，最简单的区分是通话降噪后的音频是给人听的，环境降噪后的音频是喂给语音识别模型的。人的判断力远远强于语音识别模型，因此，环境降噪的要求比通话降噪高得多。
但是，越难的地方也越容易被应付，很多智能硬件的项目，要么觉得降噪不重要，要么觉得做降噪的时间成本和金钱成本都太高而应付了事，最终，却因为产品效果之后售后投诉太多反而得不偿失。
那么，要怎么样才能做好降噪呢？
从工程和产品来说，要做好以下三件事：
第一件事，确定场景和要求。 比方说，主要使用的场景是哪里，室内和室外所要面临的降噪要求就完全不同。同时，还要确定要求有多高，是近场交互还是远场交互，需要多少颗麦克风的阵列，理论上讲，麦克风的数量越多，对芯片的算力要求越高，产品的成本也就越高，成本太高是否要向利润妥协，产品的目标用户能支持多高的价格区间等等，这些都是需要在项目立项的时候有基本的数据指标。
第二件事，找算法原厂沟通。 一定要找算法原厂沟通，用芯片自带或者降噪模组，最后的理想的结果就是产品能用但不那么好用，甚至很多产品量产后根本就没办法用。硬件项目的周期一般小则半年，长则二三年，因为降噪的原因而失败就得不偿失了。最最关键的是，降噪效果还不能后期通过软件OTA来进行升级，因为之前做ID设计和硬件设计的时候，降噪效果的天花板就已经确定了，算法如何调优都是徒劳。
找算法原厂沟通，了解清楚麦间距、性能指标、芯片算力占用情况、功耗、适配周期、麦克风喇叭选型指标、硬件结构设计细节规范等等，才能真正保证后期产品的使用效果。
第三件事，实验室系统测试。 没有测试就投产绝对是在搞破坏，声学这一块，同样需要进行系统科学的测试，评估满足量产标准后再进行量产，否则就应该按照测试结果进行整改。实在无法整改的部分，与算法原厂沟通性能恶化情况，可接受范围内可继续量产，不可接受范围内，一定要及时叫停进行整改。否则，一旦量产后，就再无回头路可言。
而声学方面，实验室系统测试的数据，包括以下部分：
麦克风：频率响应、底噪、灵敏度、信噪比、总谐波失真、密封性、阵列频响一致性等
喇叭测试：频率响应、总谐波失真、R&B、灵敏度等。
当然，有些指标不需要到实验室测试，自测也能发现问题。