| Field | Value |
|---|---|
| Date | 2026-09-13 |
| Harness version | spark-local-voice-16 → microphone-selection-17 |
| Models | None called for this intervention |
| Evidence grade | C: deterministic harness and synthetic native audio; no model-quality claim |
| Pre-registered | yes |
Observation
User: “the voice isn't getting picked up well, we need to be able to select microphones and test”. Native speech uses SetInputToDefaultAudioDevice; Realtime requests audio without a device ID. Neither provides a picker or a test. Previous suite: 757 tests.
Hypotheses
H1: One browser microphone selector can feed the exact chosen device to either Realtime or local Windows recognition, without silently falling back when it disappears. H2: A bounded local test can display input levels and local dictation without model calls, saved transcripts or canvas edits, and release capture on close/change/timeout.
Intervention
Implemented shared explicit microphone capture, remembered device ID, live meter, native PCM bridge, isolated local test and lifecycle regressions. Model prompts, recognition-confidence threshold and build authorization are unchanged. Chromium handles device selection and audio processing for both paths; local recognition accepts bounded 100 ms PCM frames instead of opening a hidden Windows default device. Test sessions have their own token and cannot invoke Spark or save conversation words.
Method
Add targeted regression, observe baseline failure, implement, run unit/type/build and real Electron fixtures. Native in-memory PCM recognition will verify the bridge without recording the user. No live inference or unattended microphone capture.
Results
765/765 tests, typecheck and build pass. Six microphone Electron checks, seven Spark integration checks and nine existing Realtime checks pass. Native 16 kHz stream selftest recovered all three phrases; two passes through the production native helper recovered the whole sentence, including mute/interruption/restart between passes. No live microphone or model was used. Initial test expected three separate phrases from the production helper, but its longer silence setting correctly joined them; the instrument was corrected to compare normalized whole words, and original failure evidence was retained.
Threats to validity
Correct device routing does not prove recognition accuracy. Real accents, noise and input gain remain user-test conditions. Meter levels are observations, not calibrated loudness.
Conclusion
H1/H2 are supported in synthetic integration scope. Device choice is real Chromium capture, selection is explicit and persistent, diagnostics are local and bounded. Recognition quality with the user's microphone remains unmeasured. The stream implementation initially failed SAPI length inspection, then ended at a short read; both issues were fixed and actual native PCM recognition rerun, not merely mocked.
Follow-ups
Use the visible test with the user's preferred microphone; assess recognizer quality separately if clear audio is still mistranscribed.
Reproduce
npm test; npm run typecheck; npm run build; npm run check:microphone; npm run check:voice:spark; npm run check:voice; node scripts/check-local-pcm.mjs. These checks do not spend model allowance. See evidence record.