Raspberry Pi 4 project: microphone input, local transcription tests, and keyboard-style output.
Original point of the project was to design a headset which can have more clarity on microphone input and restructure the output using a local speech recognition LLM called faster whisper.
The proof of concept combines embedded Linux, I²S audio hardware, local speech recognition, and Bluetooth HID keyboard output. Two MEMS microphones provide digital audio input and a way to compare microphone signals for cleaner offline transcription.
I would have chosen Optical MEMS over MEMS because its more precise using lasers over capacitate but only company which I looked into has it behind closed doors and not consumer available.
- Raspberry Pi 4B with 2 GB RAM
- Two SPH0645-style I²S MEMS microphone breakouts
- MAX98357A I²S amplifier and small speaker for prototype audio/output testing
- Breadboard and jumper-wire prototype
- KiCad schematic, PCB layout, and Raspberry Pi wiring
- Record or load microphone audio from a WAV file.
- Decode, combine the channels, and resample for a 16 kHz recognizer input.
- Use push-to-record to capture a complete phrase.
- Run local speech-to-text with faster-whisper on the Raspberry Pi.
- Clean up punctuation and casing in the recognized text.
- Send the final text to a phone or computer as Bluetooth keyboard input.
The hardware-facing audio path is written in Rust rather than Python. It keeps capture and signal handling in compiled code while still producing standard WAV files for the recognizer.
- Capture — reads a fixed amount of stereo audio from the default input device.
- Split audio — returns overlapping borrowed slices without copying each chunk.
- Decode and resample — reads WAV input, combines channels, and writes 16 kHz mono WAV output.
- Compare channels — applies a Hann window, calculates the Fourier transforms, compares the spectra, and estimates a bounded sample delay. The FFT theory maps the equations to the Rust functions.
cd backend
cargo test
cargo run -- prepare input.wav ready.wav
cargo run -- capture captured.wav 3000
The automated tests use generated WAV data. The default-device capture path is implemented, but Raspberry Pi ALSA operation and capture latency have not been measured in this repository.
The Model 1 KiCad carrier brings the two microphone breakouts, Raspberry Pi harness, channel-select jumpers, clock-damping positions, and signal test points into one editable design. Both microphones share the I²S clock and data lines while opposite SELECT states place them in separate left and right slots.
- KiCad 10 ERC: 0 errors / 0 warnings
- KiCad 10 DRC: 0 violations / 0 unconnected pads
 |
 |
| 3d view | Two-layer PCB routing |
 |
 |
| Raspberry Pi and microphone wiring | Prototype testing setup |
- The ASR model is only one part of the problem. Bad audio makes the rest of the pipeline look worse than it really is.
- A project like this needs measurable tests: microphone distance, background noise, latency, and transcription error rate.
- Voice Activity Detection can negatively affect transcription from microphone input; push-to-record improved accuracy during the proof of concept.
- Writing down the wiring and sample layout made the project easier to explain and debug.
- Model 1 KiCad project
- Rust audio backend
- FFT theory and original spectral model
- Project specifications workbook
- Original project overview
- Original audio pipeline
I built a Raspberry Pi automatic speech to text recognition proof-of-concept model with the intention of proving signal processing strategies using Fourier Transform. By using Rust for low latency response transcriptions from input, the MEMS microphones and a complimentary PCB design I incorporated several aspects of embedded, software and electrical engineering towards this project.