The full signal pipeline, from microphone to ear.

Stage 1 — Capture. Your device's microphone captures raw audio continuously in small frames (short slices of a few milliseconds each). Goeckoh explicitly disables the browser's automatic gain control on this input. That's a deliberate tradeoff: automatic gain control makes casual recordings sound more even, but it does so by compressing and warping the exact acoustic detail — the formant structure — that the correction engine needs to measure accurately. Raw, unprocessed input is a harder signal to listen to but a truthful one to analyze.

Stage 2 — Analysis. Each frame is analyzed to estimate its current formant positions — the resonant frequencies of the vocal tract that determine which vowel a listener will perceive (see the Formant Acoustics section of the Research page for the acoustic theory this rests on). This is done using linear-predictive techniques that model the vocal tract as a filter and solve for that filter's shape directly from the waveform, frame by frame.

Stage 3 — Correction. The measured formant positions are compared against a target vowel region for the sound being produced, and an adjustment is computed — how far, and in which direction, the formants need to shift to land closer to that target. This adjustment is scaled by the active correction profile (see below) so the correction is calibrated to the acoustic pattern it's designed for, rather than applying one generic correction to every speaker.

Stage 4 — Correction filtering. Rather than regenerating the waveform from scratch, the correction is applied as a direct filter — reshaping the frequencies the vocal tract already emphasized, sample by sample, as the audio passes through. Pitch, timing, amplitude envelope, and voice quality are carried through unchanged automatically, simply because the filter only reshapes formant structure and never touches anything else in the signal. This is the step that keeps the corrected voice sounding like the speaker's own voice rather than a replacement — see "What Formant Correction Actually Changes," below, for exactly where that line is drawn.

Stage 5 — Playback. The corrected frame is sent to an output gain stage and a soft-limiter (so that louder speech is gently compressed rather than clipped) and played back through the earbuds. This entire chain runs inside the browser's real-time audio processing thread — an AudioWorklet — specifically because that's the only part of a modern browser's audio stack guaranteed to run on a dedicated, high-priority thread instead of competing with the rest of the page's JavaScript for CPU time.

The research page covers why roughly 200 milliseconds is the outer edge of the window in which the brain still treats corrected auditory feedback as information about its own speech, with a 250ms hard cutoff beyond which the correction is too late to be useful. Two very different things eat into that budget, and it's worth being precise about which is which:

The audio itself is never held up: correction is applied directly to the signal, sample by sample, as it passes through — there's no buffering step waiting on analysis to finish. What does take real time is the analysis catching up to a new target after the vowel changes: formant estimation needs a short run of audio frames to lock onto the new position confidently, so the correction filter eases toward the target over roughly 50–150ms rather than snapping to it instantly. This is deliberate — reacting to every single noisy frame-to-frame estimate instead of a few consecutive ones would make the filter chase measurement noise instead of real speech. Device audio buffering, set by the operating system and the specific Bluetooth earbuds in use rather than by Goeckoh's own code, is the other place real time goes; heavy on-earbud audio processing can add tens of additional milliseconds entirely outside Goeckoh's control, which is why the demo and product both recommend low-latency Bluetooth hardware.

A voice is made of several acoustic properties layered on top of each other: pitch (fundamental frequency, or F0), loudness, timing and rhythm, voice quality (breathy, creaky, tense), and the resonant formant structure that determines vowel identity. Goeckoh's correction operates on exactly one of these — formant structure — and deliberately leaves the rest untouched.

Changed

The frequencies of the first and second formants (F1 and F2) are shifted toward the target region for the vowel being produced, when the engine detects that they've drifted enough to risk being perceived as a different or unclear vowel. The correction is proportional — a vowel that's only slightly off target receives a small nudge; one that's centralized or significantly displaced receives a larger correction, up to the limits defined by the active correction profile.

Never changed

Fundamental frequency (pitch) is carried through from the original recording unmodified — Goeckoh does not raise, lower, or flatten anyone's pitch. Speaking rate and rhythm are untouched — nothing is slowed down, sped up, or time-stretched. Amplitude envelope and voice quality (the breathiness, tension, or roughness that makes a voice recognizably an individual's own) pass through unaltered. No synthetic voice model, text-to-speech engine, or voice-cloning technology is used anywhere in the pipeline — there is no "target voice" being approximated other than a cleaner version of the same speaker's own vowel space.

Correction profiles

Because different conditions distort the vowel space in different, characteristic ways — the acoustic signature of dysarthria following a stroke is not the same as the signature associated with apraxia or with certain ASD-related speech patterns — the target vowel regions and the strength of correction are calibrated per condition rather than using one universal target. Selecting a correction profile tells the engine which calibration to use; it does not change any of the underlying pipeline stages described above.

The practical consequence: DAF can reduce stuttering-like disfluencies for some speakers through a disruption effect, but because it never analyzes or corrects anything, it has no mechanism to improve vowel clarity in dysarthria or ASD-associated speech patterns — there's no corrective signal in an unmodified, delayed copy of the same speech. Autotune-style pitch correction targets a completely different acoustic property than the one responsible for vowel intelligibility. And full voice synthesis solves a different problem entirely — it can produce clear speech, but it isn't the speaker's own real-time vocal tract output being trained, so it can't function as auditory feedback for the speaker's own motor system in the way corollary discharge-based learning requires.

The latency reason. Round-trip network latency to any server — even a fast, nearby one — is typically 20–100ms or more each way, before any processing even happens. Sending audio to a server for analysis and waiting for a corrected signal to come back would, on its own, very likely exceed the entire biological feedback window described in the latency-budget section above, before a single frame of correction has even been computed. A cloud-based architecture is not a viable way to hit this specific timing target, independent of any other consideration.

The privacy reason. Because the entire pipeline — capture, analysis, correction filtering, playback — runs inside the browser's local audio processing thread on the user's own device, there is no point in the signal chain where raw voice audio needs to be transmitted anywhere. This isn't a privacy policy layered on top of a system that could technically upload audio; it's a consequence of an architecture that was never built with a server-side audio path to begin with.