feat: pluggable TTS engine interface

[alichherawalla]

Summary

• Introduces a pluggable TTS engine interface (TTSEngine) that decouples the app from any specific TTS implementation
• Wraps Kokoro (ExecuTorch) and OuteTTS (llama.rn) as engine adapters behind a unified API
• Rewrites the TTS store as a thin proxy that delegates to the active engine — no engine-specific branching
• Adds engine picker UI to TTS Settings screen
• Lays the foundation for a multimodal on-device engine SDK (OnDeviceEngine base generalizes to STT, Vision, LLM)

What changed

New files (engine layer):

• src/engine/types.ts — OnDeviceEngine base + TTSEngine interface + all event/voice/asset types
• src/engine/OnDeviceEngineEmitter.ts — zero-dep typed event emitter
• src/engine/EngineRegistry.ts — generic registry (works for any modality)
• src/engine/tts/engines/kokoro/ — KokoroEngine, KokoroTTSBridge, voices
• src/engine/tts/engines/outetts/ — OuteTTSEngine, models
• src/engine/tts/engines/qwen3/ — Qwen3TTSEngine stub (asset management ready, inference TODO)
• src/components/EngineBridge.tsx — renders bridge for hook-based engines
• docs/TTS_ENGINE_INTERFACE.md — full documentation

Refactored:

• src/stores/ttsStore.ts — engine-agnostic, delegates to ttsRegistry.getActiveEngine()
• App.tsx — <KokoroTTSManager /> replaced with <EngineBridge />
• All UI consumers (TTSButton, TTSSection, TTSSettingsScreen, Popovers, ChatInput, etc.) now read engine-agnostic state from the store

Removed:

• src/components/KokoroTTSManager.tsx — absorbed into KokoroEngine + KokoroTTSBridge

How engine swapping works

// In TTS Settings, user taps an engine:
await useTTSStore.getState().setEngine('outetts');
// That's it. Store syncs voices, assets, phase. UI updates automatically.

Test plan

• Cold launch — app boots, EngineBridge renders, Kokoro initializes
• TTSButton appears on messages when engine is ready
• Tap TTSButton — speaks, pulsing animation, tap again stops
• TTS Settings — engine picker shows Kokoro + OuteTTS, tap to switch
• Voice picker updates per engine (8 Kokoro voices vs 1 OuteTTS voice)
• Model assets section updates per engine
• Speed/auto-play settings persist across engine switches
• Background app while speaking — pauses/stops correctly
• Kill and relaunch — settings (engine, voice, speed, mode) preserved
• Audio Mode — generate and save works with OuteTTS engine
• npm run lint && npx tsc --noEmit && npm test — all passing (157 suites, 5176 tests)

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[sonarqubecloud]

Quality Gate failed

Failed conditions
6 Security Hotspots
5.4% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[gemini-code-assist]

Code Review

This pull request introduces a pluggable text-to-speech (TTS) architecture supporting multiple on-device engines, specifically Kokoro for fast streaming and OuteTTS for high-quality audio generation. It includes new UI components for waveform audio bubbles, a dedicated TTS settings screen, and updates to the chat interface for an "Audio Mode" experience. Feedback highlights a bug in OuteTTSEngine where raw PCM data is incorrectly passed to decodeAudioData without a header, and suggests a more efficient Buffer-based implementation for base64 conversion of audio samples.

[gemini-code-assist]

The decodeAudioData method is typically used for encoded audio formats (like WAV or MP3). Since the engine writes raw Float32 PCM data to disk, decodeAudioData will likely fail to decode the .pcm file as it lacks a header. You should read the file as an ArrayBuffer and manually load it into an AudioBuffer using createBuffer and copyToChannel.

[gemini-code-assist]

The _float32ToBase64 implementation is inefficient and uses non-standard globals. Use Buffer for faster, safer base64 conversion.

  private _float32ToBase64(samples: Float32Array): string {
    return Buffer.from(samples.buffer, samples.byteOffset, samples.byteLength).toString('base64');
  }