duffyduck 402bddc18a fix: Streaming TTS — Queue in XTTS-Bridge + groesserer Android-Buffer ... 1) Ueberlappende Streams Wenn zwei xtts_requests schnell hintereinander kamen, rannten sie parallel durch handleTTSRequest. Beide HTTP-Requests an XTTS liefen gleichzeitig, beide streamen PCM an App → Chunks aus BEIDEN Renders landeten interleaved in der AudioTrack-Queue → Chaos. Fix: ttsQueue als Promise-Chain — handleTTSRequest() haengt sich ans Ende der Kette an. Requests werden sequenziell abgearbeitet. 2) AudioTrack-Buffer zu klein fuer bursty Delivery XTTS /tts_to_audio/ ist NICHT echt streaming — der Server rendert intern den kompletten WAV und schickt ihn dann burst-weise. Der alte 8x-MinBuffer (ca 200-400ms) war zu klein um das abzufangen. Fix: Buffer auf 32x MinSize / mind. 128KB = ca. 2.7s bei 24kHz. Das toleriert typische XTTS-Render-Latenz. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-19 23:27:16 +02:00
..
.env.example	feat: XTTS v2 integration, auto-update system, TTS engine abstraction	2026-04-05 19:42:10 +02:00
Dockerfile	feat: XTTS v2 integration, auto-update system, TTS engine abstraction	2026-04-05 19:42:10 +02:00
bridge.js	fix: Streaming TTS — Queue in XTTS-Bridge + groesserer Android-Buffer	2026-04-19 23:27:16 +02:00
docker-compose.yml	fix: XTTS bridge shares /voices volume with XTTS server	2026-04-10 01:40:41 +02:00
package.json	feat: XTTS v2 integration, auto-update system, TTS engine abstraction	2026-04-05 19:42:10 +02:00