TTS gateway concept (spike)
Spike: SCRUM-480. This page is the concept write-up (DoD: guidelines for implementation, enough to plan stories). It is not a new service.
Recommendation
Do not add a TTS gateway microservice.
- Normalize in the provider — Azure TTS already normalizes inline (SSML / plain text) before synthesize. Other TTS adapters should share a small helper rather than a network hop.
- Reuse the existing TTS media cache —
TTS_MEDIA_CACHE_BASE_URLand the TelPhi audio pipeline already persist synthesized audio. That covers “save while playing” and WebRTC / SiteCockpit replay of standard prompts. - Keep LLM out of canned prompts — Flow Designer farewell / comfort prompts and cached TTS keys are the path to “standard texts with reduced LLM involvement.”
Guidelines for later stories
| Story | Why |
|---|---|
Shared normalizeTtsText helper used by Azure, OpenAI, Inworld | One place for SSML strip, whitespace, locale punctuation |
| Cache-key includes normalized text + voice + locale | Avoid duplicate audio for equivalent prompts |
| Optional Flow Designer “play cached prompt” node | SiteCockpit / WebRTC cost reduction without an extra service |
Out of scope
A standalone HTTP TTS gateway, a new queue, or a second cache in front of Azure. Those add latency and ops surface without changing the product.
Please review this write-up with the team. Agreed gaps become follow-up stories — this page closes the spike.