Summary

• Pre-generates TTS audio for inboundGreeting at gateway startup
• Plays cached audio instantly on inbound call connect (zero synthesis delay)
• Falls back to original TTS synthesis path for outbound calls or when no cache

Context

When an inbound call connects, the greeting has a noticeable 500ms+ delay because TTS synthesis happens on-demand after the media stream is established. For voice UX, sub-second greeting is table stakes — callers expect immediate acknowledgment.

This pre-generates the greeting audio once at startup and sends it directly via the media stream when an inbound call connects, bypassing the synthesis step entirely.

Changes

• providers/twilio.ts: Added cachedGreetingAudio buffer storage with set/get methods
• runtime.ts: After TTS provider initialization, pre-synthesizes the inboundGreeting asynchronously
• webhook.ts: On onConnect for inbound calls, streams cached audio chunks directly instead of waiting for TTS synthesis. Reduces fallback delay from 500ms to 100ms for non-cached cases.

Test plan

• Configure inboundGreeting: "Hello!" → verify "Cached greeting audio: N bytes" in startup logs
• Call inbound → verify instant greeting with no delay
• Outbound call → verify normal TTS synthesis path (not affected)
• No inboundGreeting configured → verify no errors, normal behavior
• TTS provider unavailable at startup → verify warning logged, fallback works

🤖 Generated with Claude Code

Greptile Summary

Pre-caches TTS audio for inboundGreeting at startup and plays it instantly when inbound calls connect, eliminating the 500ms synthesis delay.

Key changes:

• Added cachedGreetingAudio buffer storage to TwilioProvider with getter/setter methods
• Pre-synthesizes greeting asynchronously in runtime.ts after TTS provider initialization
• Modified webhook.ts onConnect handler to check for cached audio and stream it directly for inbound calls, bypassing TTS synthesis
• Reduced fallback timeout from 500ms to 100ms for non-cached scenarios

Issues found:

• State mutation (delete call.metadata.initialMessage) isn't persisted to disk, unlike the existing speakInitialMessage path which calls persistCallRecord after deletion (manager/outbound.ts:205-207). Could cause greeting to replay after gateway restart.

Confidence Score: 3/5

• Safe to merge with minor risk - the implementation works correctly for the happy path but has a state persistence edge case
• The core caching mechanism is sound and the performance optimization is well-implemented. However, there's a state persistence bug where call.metadata.initialMessage deletion isn't persisted to disk, which could cause greeting replay after restart. The issue is not critical for production but violates the existing pattern used elsewhere in the codebase.
• Pay close attention to webhook.ts lines 150-152 where state mutation isn't persisted

_{Last reviewed commit: 91b667b}