revert: XTTS-Endpoint zurueck auf /tts_to_audio/

/tts_stream war bei der aktiven daswer123-Version nicht erreichbar —
Requests hingen stille, App bekam kein Audio.

Zurueck auf /tts_to_audio/ + Queue + 32x AudioTrack-Buffer. Das ist
zwar nicht echt-streaming aber stabil. Ueberlappung sollte durch die
Queue weg sein, Buffer toleriert den bursty Delivery.

Echt-Streaming-Migration spaeter mit verifizierter Server-Version
oder anderem Endpoint.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
duffyduck 2026-04-20 16:48:27 +02:00
parent a28b46a809
commit 5ac1a0a522
1 changed files with 7 additions and 7 deletions

View File

@ -195,12 +195,13 @@ async function _runTTSRequest(payload) {
}
/**
* Ruft /tts_stream auf echter Streaming-Endpoint von daswer123.
* Chunked Transfer-Encoding: Samples kommen WAEHREND XTTS rendert,
* nicht erst am Ende. Time-to-first-audio ~300-500ms statt 2-3s.
* Ruft /tts_to_audio/ auf und streamt das Response-Body chunkweise an
* den Callback. Kein echtes Server-Streaming (XTTS rendert komplett
* bevor es antwortet), aber stabil und mit der Queue + grosszuegigem
* AudioTrack-Buffer klingt's akzeptabel.
*
* stream_chunk_size = Characters pro Render-Iteration.
* 40 = guter Kompromiss zwischen Schnellstart und GPU-Effizienz.
* /tts_stream ist elegant, funktioniert aber nicht in allen Versionen
* von daswer123/xtts-api-server.
*/
function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
return new Promise((resolve, reject) => {
@ -208,10 +209,9 @@ function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
text,
language,
speaker_wav: speakerWav || "",
stream_chunk_size: 40,
});
const url = new URL(`${XTTS_API_URL}/tts_stream`);
const url = new URL(`${XTTS_API_URL}/tts_to_audio/`);
const options = {
hostname: url.hostname,
port: url.port,