Speech preprocessing: a 12-point checklist before you start

01

How many microphones are there, and is the layout final?

Two or more microphones give you directional information. The return on adding more falls off logarithmically: assuming spatially white noise, the theoretical ceiling is 3.0 dB for two, 6.0 dB for four, and 9.0 dB for eight. There is a point past which layout and algorithm matter more than count.

And layout keeps moving until the end of product development because of mechanical design, speaker position, and cost. Checking early whether the algorithm has to be re-tuned every time the layout changes takes risk out of the schedule.

• Count
• Array shape — circular · linear · other · undecided
• Microphone spacing (mm)
• Layout status — final · may change · undecided

Spacing has a physical ceiling. To avoid directional ambiguity it must not exceed half a wavelength — 42.9 mm at 4 kHz and 21.4 mm at 8 kHz (at 343 m/s).

02

How far is the user from the microphone?

As distance grows the target speech gets quieter while the surrounding noise does not. Processing built for close-talk does not hold up when it is used at a distance unchanged.

• Typical distance (cm to m)
• Worst-case distance (m)
• User position — fixed · moving · from several directions

03

What are the sampling rate and the input channel count?

The sampling rate sets the highest frequency you can work with. At 16 kHz the Nyquist limit is 8 kHz, and there is simply nothing above it. The channel count decides the hardware interface and the compute load together.

• Sampling — 16 kHz · 48 kHz · other
• Bit depth — 16-bit · other
• Input channels (ch)
• Echo reference channel — yes (ch) · no · undecided

04

What is the main source of interference?

Each kind of interference needs different processing. No single algorithm covers all of them. If you do not know which problem dominates, you cannot write the test conditions either.

• Other people talking nearby → directional separation
• Sound from a TV or speaker → echo cancellation
• Road and machine noise → noise suppression
• Reflections off walls and ceilings → reverberant conditions
• Noise the product itself makes → see 5 and 6
• Several people speaking at once → source separation
• The single biggest problem

Wanting to tick every box is itself the signal. Without a priority there is no basis on which to decide, at the test stage, that it passed.

05

Does the product have a speaker, and must it listen while talking?

When a user interrupts while the product is speaking (barge-in), the speaker output comes back into the microphone alongside the user's voice. What that needs is acoustic echo cancellation, not noise suppression, and the two are different processes.

• Speaker — yes · no
• Speaker channels — mono · stereo · other
• Listening while talking — required (barge-in) · not required · undecided
• Speaker-to-microphone distance (cm)

Stereo speakers need separate review. When the two channel signals resemble each other, ordinary echo cancellation has a classical problem narrowing down to a single solution.

06

Does the product make noise of its own?

In a product with motors, joints, or fans — a robot, say — the noise source sits on the same structure as the microphone. It arrives by two paths. Airborne noise drops off as you move the microphone away; structure-borne noise travels through the frame straight into the microphone body, so distance does not help. That is a question of isolation mounts and how things are fastened.

Structure-borne noise is not solved by signal processing alone. It has to be handled together with the mechanical design.

• Moving parts — motors and actuators · fans and cooling · none
• Listening while moving — required · not required
• Vibration isolation reviewed — yes · not yet

07

What is the compute platform, and what resources are available?

Whether something can run on-device is not decided by the presence of an NPU. The model, the memory, and the real-time requirement have to be read together.

One figure you can measure against — for preprocessing alone there is a measured record of it running at a 64 MHz clock in 0.571 MB of SRAM (TTA test report, Ministry of SMEs and Startups Didimdol programme, with mpAB as the article under test). That is the preprocessing execution footprint, not the requirement for a full recognition stack.

• Platform — MCU · DSP · AP · FPGA · undecided
• Chipset / core
• Clock frequency (MHz)
• Available SRAM (MB)
• Available flash (MB)
• NPU — yes · no

08

Is the voice data allowed to leave the device?

Depending on situation and context, voice can constitute personal data. If the architecture provides, accesses, outsources processing of, or stores it outside the country, the cross-border transfer requirements of Korea's Personal Information Protection Act may need separate review, and for the EU market the GDPR special-category requirements.

On-device processing does not automatically exempt you from that review. It is, however, a design option that reduces how much raw audio leaves the device at all.

• Voice may leave the device — yes · no · conditionally
• Target market — Korea · EU · US · other
• Sensitive setting such as home, medical, or vehicle interior — yes · no

09

How much latency is acceptable?

In natural conversation between people, the modal gap at a turn transition is 0 to 200 ms and the overall mean offset is 208 ms (analysis of natural conversation across ten languages, PNAS 2009). This is not an absolute target for a voice system; it is a baseline for the fact that even short gaps change how a conversation feels.

• Acceptable response latency (ms)
• Measured against — typical conditions · worst case
• Network use — always connected · unreliable · none

Real-time factor and perceived latency are not the same thing. RTF is processing time against audio length; perceived latency includes capture, buffering, transport, recognition, and response.

10

Which recognition engine do you use now, and can it be changed?

Preprocessing is an input-quality layer separate from the recognition engine. Keeping the engine and changing only what sits in front of it is a workable arrangement. The reverse is not: once the input is degraded, changing engines does not bring the original signal back.

• Current engine
• Where it runs — on-device · cloud · hybrid · undecided
• Engine can be replaced — yes · no (must keep the existing one) · under review

11

What will you use to decide it passed?

If this one is blank you can start a PoC but you cannot finish it. Performance is not one number. How much noise was removed (SNR, noise reduction), how much of the original was preserved (SI-SDR), and whether it keeps up in time (RTF) measure different things.

And figures come with conditions attached. Change the input SNR, the speech level, the noise level, the number of talkers, or the reverberation, and the same algorithm produces a different value. A figure without its conditions cannot be compared.

• Metric — recognition rate · SNR · SI-SDR · noise reduction · RTF · user rating · other
• Pass threshold
• Measurement conditions
• Evaluation data — your own recordings · public corpus · undecided

Having recordings made on your own product changes the quality of the verification entirely. If you do not have them, plan how to get them first.

12

What is the production schedule and the expected volume?

Development, porting, and verification costs land up front; network and server costs accumulate after shipping. Which way that balance falls is decided by volume and usage. And the schedule decides how much verification fits.

• Development stage — planning · prototype · verification · production readiness
• Production target (year / quarter)
• First-year volume (units)
• Certification requirements