release: bump version to 0.0.4.4

Vorher: /tts_to_audio/ — XTTS rendert kompletten WAV BEVOR es
antwortet. Mein "streaming" war nur fake-chunking des fertigen WAV.
Time-to-first-audio = komplette Render-Zeit (2-4s), dann Burst,
dann Stille. Plus bei langen Antworten: Queue blockiert.

Jetzt: /tts_stream — daswer123's chunked-transfer endpoint.
Samples flutschen waehrend der Generierung durch die Response raus.

Parameter:
- stream_chunk_size=40 → XTTS rendert in ~40-char Haeppchen intern,
  time-to-first-audio ~300-500ms statt 2-4s
- WAV-Header kommt wie gewohnt am Anfang (44 Bytes), danach raw PCM
  → mein existierender Header-Parser + 8KB-Chunker passen weiter

Voraussetzung: daswer123/xtts-api-server hat diesen Endpoint (ab
Version ~0.8.x). Sollte bei der aktuellen Version drin sein.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

android/android/app/build.gradle

@@ -79,8 +79,8 @@ android {
         applicationId "com.ariacockpit"
         minSdkVersion rootProject.ext.minSdkVersion
         targetSdkVersion rootProject.ext.targetSdkVersion
-        versionCode 403
+        versionCode 404
-        versionName "0.0.4.3"
+        versionName "0.0.4.4"
         // Fallback fuer Libraries mit Product Flavors
         missingDimensionStrategy 'react-native-camera', 'general'
     }

android/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aria-cockpit",
-  "version": "0.0.4.3",
+  "version": "0.0.4.4",
   "private": true,
   "scripts": {
     "android": "react-native run-android",

xtts/bridge.js

@@ -195,16 +195,12 @@ async function _runTTSRequest(payload) {
 }
 
 /**
- * Ruft /tts_to_audio/ auf und streamt das resultierende WAV bereits waehrend
+ * Ruft /tts_stream auf — echter Streaming-Endpoint von daswer123.
- * des Empfangs in PCM-Frames an den Callback. Der WAV-Header wird einmal
+ * Chunked Transfer-Encoding: Samples kommen WAEHREND XTTS rendert,
- * geparst, danach werden nur noch raw PCM-Samples weitergeleitet.
+ * nicht erst am Ende. Time-to-first-audio ~300-500ms statt 2-3s.
  *
- * Warum nicht echtes /tts_stream/? daswer123 hat den Endpoint, aber die
+ * stream_chunk_size = Characters pro Render-Iteration.
- * Audio-Quality ist dort niedriger und er produziert beim ersten Chunk
+ * 40 = guter Kompromiss zwischen Schnellstart und GPU-Effizienz.
- * oft Artefakte. Pragmatischer Weg: /tts_to_audio/ + Response-Stream
- * chunkweise auslesen. Das ist zwar kein echtes Server-Streaming, aber
- * gibt uns deutlich kleinere Netzwerk-Haeppchen und die App kann via
- * AudioTrack MODE_STREAM sofort nahtlos abspielen.
  */
 function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
   return new Promise((resolve, reject) => {
@@ -212,9 +208,10 @@ function streamXTTSAsPCM(text, language, speakerWav, onPcmChunk) {
       text,
       language,
       speaker_wav: speakerWav || "",
+      stream_chunk_size: 40,
     });
 
-    const url = new URL(`${XTTS_API_URL}/tts_to_audio/`);
+    const url = new URL(`${XTTS_API_URL}/tts_stream`);
     const options = {
       hostname: url.hostname,
       port: url.port,