> ## Content Index
> Fetch the complete content index at: https://sreekars-journal.labvion.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why does the model look better on the screen than through the microphone?
- URL: https://sreekars-journal.labvion.com/tm07-the-live-microphone-isn-t-giving-the-same-result/
- Published: 2025-11-30T12:30:00.000Z
- Updated: 2026-10-29T08:26:53.000Z
- Description: The live microphone results were less encouraging than the validation screen. That made the route into the classifier more interesting to me. A model file does not receive the word ON as a meaning; it receives a representation of the captured sound. The laptop recordings and the INMP441 stream
- Author: Sreekar
- Tags: TinyML, #Import 2026-10-29 10:08

The live microphone results were less encouraging than the validation screen. That made the route into the classifier more interesting to me. A model file does not receive the word ON as a meaning; it receives a representation of the captured sound. The laptop recordings and the INMP441 stream could therefore present different inputs even when the spoken command is the same.

Microphone and acoustic differences are possible explanations, not a demonstrated single cause. The code gives me another concrete comparison: the microphone test narrows shifted samples to int16, while inference casts the shifted value directly to float. That difference is worth understanding before treating two working-looking programs as identical input paths. It does not prove the cause of the live errors, but it makes the question smaller than whether the entire model works.

It would be easy to begin by changing the model. It’s the part choosing the label, so it seems like the natural place to look. But the classifier only receives what the earlier stages give it. If that representation has changed, the model might be responding to a different kind of input from the one I thought I supplied.

I'm drawing two routes. One begins with the recordings used for training, then passes through feature extraction and learning. The other begins with the INMP441, passes through the live sample conversion and feature extraction, then reaches the exported classifier. The question is where the routes agree and where they might differ.

![Impulse-design screenshot showing one-second audio windows and three classes. Screen settings do not establish that the application implements continuous inference at a 20 ms stride.](https://sreekars-journal.labvion.com/content/images/2026/10/IMG11.jpg)

Impulse-design screenshot showing one-second audio windows and three classes. Screen settings do not establish that the application implements continuous inference at a 20 ms stride.

The microphone is one possible difference. A recording device can shape sound through its frequency response, placement and processing. The room adds its own effect. Speaking further away changes the balance between the voice and background sound. I don't need to decide that any one of those is the cause yet. I need to stop treating the written word ON as if it guarantees equivalent audio everywhere.

The software can introduce differences as well. Sample rate, scaling, signed conversion and the length of the captured window all affect what reaches processing. A value can be a perfectly legal number in a buffer and still be wrong for the interpretation that follows. No amount of confidence in the model file fixes a sample stream that has been read incorrectly.

An example helps me separate the ideas. Imagine a correctly labelled training clip with a whole word centred inside its one-second window. Now imagine a live window that begins halfway through the same word. Even with the same speaker and microphone, those are different pieces of sound. If the classifier struggles, I shouldn't immediately conclude that the microphone's quality is responsible. Timing has changed too.

Another case is a quieter live recording. Multiplying a waveform by a scale factor preserves some aspects and changes others. The feature processing may handle part of that difference, but I can't assume it removes every effect. If the signal is badly clipped, information has been lost before normalisation could help. These are reasons to inspect input, not diagnoses I can make from the final label alone.

This is making the phrase same command feel less precise. Do I mean the same spoken word, the same person saying it, the same captured recording or exactly the same samples? For an everyday conversation, those differences are unimportant. For debugging a pipeline, they decide which comparison actually tells me something.

The cleanest question I can ask about the classifier itself is what happens with the same prepared input. If the exact saved samples and configuration are used, fewer things are changing than when I speak again in a different room. That comparison would help separate a deployment or processing issue from variation in the sound. I haven't produced that result here; I'm explaining why it would be more informative than repeatedly saying ON and hoping to recognise a pattern.

For the live side, a recording from the actual microphone would be useful because it lets me investigate what the board heard. Listening and looking at the waveform could reveal an obvious problem before I touch training. The actual capture method still needs to fit the application, but the principle is simple: preserve the input that produced the error, rather than keep only the label at the end.

I also want the wrong predictions described clearly. Did the device call ON when there was noise? Did it fail to recognise a genuine command? Was the model uncertain across all labels, or strongly favouring the wrong one? Those are different behaviours. A single sentence saying it doesn't work makes them all look like the same problem.

The noise class from validation is relevant without automatically explaining the live result. The screen already showed noise being predicted as ON in half of that row's examples. That’s a clue about the model's existing confusions. It doesn't prove that every live mistake has the same cause. I need to connect particular recordings and errors before combining the stories.

Collecting more data is still a possible response, but I want a reason for each set of new examples. If the issue is a conversion mistake, more recordings won't repair the code. If the input is read correctly but the dataset doesn't represent the intended conditions, better matched data could be useful. Those routes lead to different work, which is why the diagnosis matters before the next training run.

My mentor can help me keep the comparison small enough to interpret. I want to bring the two input routes and a specific unresolved difference, not a long list of every possible audio problem. Examples in the documentation help when I need one stage unpacked again. They can't tell me what the microphone captured without the actual samples.

The live behaviour leaves an open causal question. A possible input mismatch is useful because it points towards a comparison; it is not a repair simply because it sounds plausible. I want the explanation to connect an input, its processing and its result, rather than turn the last prediction into proof of whichever cause I first considered.

What has changed is where I look. The prediction is the last visible event, so it naturally gets the blame. Following the route backwards gives me earlier questions that are smaller and more physical: what was recorded, what values were read, which processing was applied and whether it matched training.

The MFCC path has a fixed configuration too: 13 coefficients, 20 ms frames and stride, 32 filters, a 256-point FFT and 650 feature values. The input has to be meaningful for that route before a prediction can be meaningful at the end. The validation matrix already shows a noise-to-ON confusion, which is a useful separate clue. I should not combine every clue into one confident cause. A code representation difference, an acoustic difference and an existing model confusion ask different comparisons.

I still want the device to recognise the words. I also want to know why it recognises them when it does. That makes the disappointing result worth staying with. It’s showing me that building the pipeline and understanding the pipeline aren't quite the same milestone, and the second one needs the original sound much more than another screenshot of the score.