sylnix
← Blog
Engineering Deep Dive

Building a Voice
Pipeline That
Doesn't Suck

Six layers, dozens of gotchas, zero tolerance for lag. This is what actually matters when you're shipping a voice AI to real users, not a demo audience.

February 20, 2026 · Engineering
The Reality Check

Most voice pipeline tutorials show you how to stitch together Whisper, GPT-4, and ElevenLabs in 50 lines of Python. That's a proof of concept. It is not a product.

Real users don't sit in silence while your pipeline processes. They have background noise, bad mic quality, and accents that STT models have never heard. They interrupt. They trail off mid-sentence. They expect a response in under a second.

Every layer of the stack adds latency. Every layer has its own failure modes. And the failure modes compound in ways that are genuinely hard to debug unless you've seen them before.

This post is what we wish we'd had when we started building Sylnix Listen. It's the stuff that cost us weeks of debugging, not the stuff that takes five minutes to implement.

Total Latency Budget
01Audio Input< 20ms
02Voice Activity Detection< 30ms
03Speech-to-Text< 300ms
04LLM Core< 600ms to first token
05Text-to-Speech< 100ms to first audio chunk
06Orchestration< 10ms overhead
Target totalUnder 1s
300msThreshold where voice starts feeling broken
40%Of voice failures originate at VAD layer
1 in 3Sentences contain an error at 95% STT accuracy
700msDead air before users think the call dropped
The Stack

Six Layers, Six Opportunities to Break

Raw audio comes in from the mic, gets chunked, normalized, and noise-filtered before any AI touches it. This layer seems trivial. It is not.

What bites you
  • 1Chunk size matters more than you think. Too big and latency balloons. Too small and STT models get confused at word boundaries.
  • 2Background noise doesn't just affect accuracy, it makes VAD fire incorrectly and blows your turn-detection logic.
  • 3Sample rate mismatches are silent killers. 8kHz phone audio fed to a 16kHz model gives you garbage and no error.
  • 4Echo cancellation needs to be on. Always. Otherwise your TTS output feeds back into the mic and the bot starts talking to itself.
WebRTCPortAudioWebAudio APIOpus codec

Before You Ship to Users

Run this. Seriously.

Tested with real phone audio, not headset recordings
VAD end-of-turn thresholds tuned per use case
Streaming active at every layer (STT, LLM, TTS)
Barge-in support working and tested
Dead air handling with filler/thinking sounds
Full conversation trace logging with timestamps
Graceful fallback for each provider outage
Tested at turn 10+ of a single conversation
Echo cancellation confirmed on target devices
p99 latency measured, not just p50