Studio UI (Next.js)
Script input, voice/engine selection, playback controls, and job state. TypeScript keeps engine contracts explicit so UI never assumes a single provider response shape.
Case study 04 · AI audio
Koe
Dual-engine text-to-speech studio: cloud neural quality and offline local inference in one product surface.
Role
Fullstack / AI engineer
Stack
Next.js · Azure · Docker
Domain
TTS / accessibility
graphic_eq
Why dual engines?
Single-vendor TTS forces a hard tradeoff. Cloud neural voices (Microsoft Azure) deliver high naturalness and broad language coverage — at recurring cost and with data leaving the machine. Offline engines (Piper via Docker) keep audio generation local for privacy and predictable unit economics — with different quality and hardware constraints. Koe exposes both behind one studio UX so the choice is operational, not architectural.
Problem framing
Content teams, accessibility products, and internal tools all need speech synthesis, but not under the same constraints. Some workloads can spend on Azure Neural quality; others must run air-gapped or minimize per-character spend.
Without a modular design, products either lock to one provider or fork two separate apps. Koe’s goal: one interface, swappable synthesis backends, and streaming playback that feels live rather than “download when finished.”
Solution shape
A Next.js studio UI orchestrates synthesis jobs. The cloud path calls Azure Neural TTS. The offline path runs Piper inside Docker so local inference is reproducible across machines.
Audio streams over WebSockets for progressive playback. Engine selection is modular — operators switch based on latency budget, cost ceiling, or privacy requirements without changing the rest of the product flow.
Architecture
Component responsibilities
Azure Neural path
Premium cloud synthesis for production voice quality. Best when network access is available and naturalness is the primary KPI.
Piper + Docker path
Offline inference containerized for consistent local runtime. Prefer when text is sensitive, connectivity is limited, or cloud spend must stay near zero.
Realtime audio streaming
WebSocket transport streams audio chunks as they become available, reducing perceived latency versus waiting for full file generation. This matters for long scripts and for validating voice choice quickly during creative iteration.
Next.js
Azure TTS
Piper TTS
WebSocket
Docker
Decision matrix operators can actually use
| Constraint | Prefer Azure Neural | Prefer Piper (local) |
|---|---|---|
| Privacy | Acceptable data egress | Sensitive / air-gapped text |
| Cost | Budget for cloud usage | Minimize recurring spend |
| Quality priority | Maximum naturalness | Good-enough offline fidelity |
| Connectivity | Stable network | Unreliable or offline |
Engineering takeaways
- · Treat TTS providers as interchangeable backends behind a shared interface.
- · Stream early — perceived latency drives whether the studio feels usable.
- · Dockerize offline models so “works on my laptop” becomes a deployable unit.
Vpipe
Security-aware AI CLI for build errors