TinyML Speech Features: Match the Audio Preprocessor to the Classifier Input
A speech classifier accepts its input tensor and runs successfully, yet microphone audio produces implausible results. Matching the tensor length is insufficient: the values must represent the same frequency features, frame order and preprocessing used during training.
The pinned TFLM Micro Speech example makes this boundary concrete. It contains an audio-preprocessing model followed by a separate classifier. This is the current examined upstream example, not the older archived Arduino sketch with the same broad application name.
Follow the two-model input contract
The example documentation specifies mono, signed 16-bit PCM at 16 kHz. Each preprocessing input covers 30 milliseconds, with a 20-millisecond step between frames. Each output contains 40 features; the classifier consumes 49 such feature rows.
Those dimensions imply 480 audio samples per frame and a 320-sample advance. Adjacent windows therefore share 160 samples. Feeding disjoint 480-sample chunks changes the time axis even though every individual call receives the expected shape.
Neither a generic FFT magnitude array nor any arbitrary 40-bin spectrum is a substitute. The documented pipeline includes windowing, spectral processing, a filter bank, noise reduction, gain control and output scaling chosen to reproduce the training frontend.
Make the preprocessing configuration part of the model pair
The audio-preprocessor implementation defines an immutable FeatureParams object. Its defaults include the sample rate, window timing, filter-bank limits, smoothing and legacy output scaling.
Changing a filter-bank boundary or scaling rule can preserve the 40-element output shape while changing what each number means. Keep the preprocessing configuration with the classifier artifact. A smaller FFT or different frontend should be treated as a changed model input distribution requiring evaluation, rather than a transparent firmware optimization.
The supplied float-output and int8-output preprocessors also establish different boundaries. Inspect the classifier's actual input type and quantization parameters before connecting a replacement frontend. Do not quantize an already compatible int8 feature vector a second time.
Check frame count and layout before classification
The C++ example advances the audio pointer by the stride, stores each 40-value row and copies the flattened feature array into the classifier input. Preserve that time-major row order; a transposed frequency-major array has the same number of elements but different semantics.
For a one-second, 16000-sample clip, complete 480-sample windows with a 320-sample step produce 49 frames. Shorter input produces fewer complete frames. The example's feature-generation helper returns after the available frames and does not itself require that all 49 rows were filled.
A product wrapper should therefore track the completed row count explicitly. Reject an incomplete window, or use a padding policy that matches training. Do not let unused rows retain features from a previous recording. The supplied 30-millisecond feature tests intentionally exercise one row; they are not complete classifier-input demonstrations.
Compare the feature boundary before the final label
The preprocessor tests include fixed audio samples and expected feature vectors, plus comparisons across execution modes. Use that structure to test the deployed frontend: first establish that a known PCM frame reaches the expected feature representation, then test the assembled classifier input.
Match preprocessing history when making those comparisons, because the frontend maintains noise-related state. A disagreement at the feature boundary points toward sampling, framing or preprocessing; an agreement there moves the investigation to the classifier integration. Check the applicable upstream test tolerance for the chosen implementation rather than inventing one after seeing a failure.
The evaluation script makes the final handoff explicit by flattening the feature matrix and interpreting output with its own quantization parameters. Only after these boundaries are correct should live microphone behavior be used to assess the model. No audio capture or inference test was run for this article.
