RealtimeVoiceChat – Echtzeit-AI-Sprachchat mit etwa 500 ms Latenz

• Ein System, mit dem sich über das Browser-Mikrofon in Echtzeit natürliche Sprachgespräche mit einer AI führen lassen
• Über den Ablauf STT → LLM → TTS wird die Sprache des Nutzers in Text umgewandelt, die AI-Antwort anschließend wieder in Sprache konvertiert und abgespielt
• Zu den Kernkomponenten gehören ein FastAPI-Server, WebSocket-Streaming, Pod-basierte Sprachverarbeitungsmodule sowie verschiedene LLM-Backends
• Es wird eine Docker-basierte Deployment-Umgebung bereitgestellt; mit GPU sind noch geringere Latenzen und bessere Leistung zu erwarten
• Eine stark anpassbare Umgebung mit fortgeschrittenen Konfigurationsmöglichkeiten wie Erkennung von Nutzerunterbrechungen, Modellwechsel und Stimmauswahl

---

Echtzeit-AI-Sprachchat

• Dieses Projekt ist als Client-Server-Architektur für bidirektionale Sprachgespräche in Echtzeit konzipiert
• Nutzer sprechen im Browser, und die AI gibt die Antwort als Sprache zurück
• Unterbrechungsverarbeitung, Anzeige teilweiser Textantworten und die Auswahl verschiedener TTS-Stimmen werden unterstützt

Wichtiger Ablauf

1. Spracheingabe: Erfassung der Sprache des Nutzers im Browser
2. Streaming-Übertragung: Versand von Audio-Chunks per WebSocket an das Python-Backend
3. Spracherkennung: RealtimeSTT wandelt Sprache in Text um
4. LLM-Verarbeitung: Übergabe des Textes an das LLM zur Antwortgenerierung
5. Sprachsynthese: RealtimeTTS wandelt den Antworttext in Sprache um
6. Wiedergabe der Antwort: Das erzeugte Audio wird zurück an den Browser gestreamt
7. Unterbrechungserkennung: Dazwischenreden des Nutzers wird automatisch erkannt und verarbeitet

Hauptfunktionen

• Sprachgespräche in Echtzeit und Vorschau auf Teiltranskripte/Teilantworten
• Audio-Chunk-basiertes Streaming für geringe Latenz
• Unterstützung für statische/dynamische Stille-Erkennung (turn detection)
• Verschiedene LLM-Backends: standardmäßig Ollama, optional OpenAI
• Unterstützung mehrerer TTS-Engines: Kokoro, Coqui, Orpheus
• Web-Interface: Vanilla-JS-UI auf Basis der Web Audio API
• Deployment auf Basis von Docker Compose

Technologie-Stack

• Backend: Python 3.x, FastAPI
• Frontend: HTML, CSS, JavaScript (Web Audio API)
• Kommunikation: WebSockets
• Containerisierung: Docker, Docker Compose
• AI/ML-Bibliotheken:
  • RealtimeSTT, RealtimeTTS, transformers, torch, torchaudio
  • ollama, openai
• Audioverarbeitung: numpy, scipy

Systemanforderungen und Empfehlungen

• Betriebssystem: Docker unter Linux empfohlen (vorteilhaft für GPU-Integration)
• Python 3.9+, NVIDIA-GPU mit CUDA 12.1 oder höher empfohlen
• Bei Verwendung von Docker ist das NVIDIA Container Toolkit erforderlich
• Ollama oder ein OpenAI API Key müssen bei Bedarf konfiguriert werden

Installation

Option A: Installation mit Docker (empfohlen)

1. Repository klonen und docker compose build ausführen
2. Mit docker compose up -d App und Ollama starten
3. Ollama-Modell separat herunterladen (z. B. docker compose exec ollama ollama pull ...)
4. Dienste beenden: docker compose down
5. Neustart: docker compose up -d

Option B: Manuelle Installation

1. Python-venv einrichten und Abhängigkeiten installieren
2. Passende PyTorch-Version für die CUDA-Version manuell installieren
3. server.py ausführen, um den FastAPI-Server zu starten

Ausführung

• Im Browser http://localhost:8000 aufrufen
• Mikrofonberechtigung erlauben und danach auf "Start" klicken
• Mit "Stop" beenden, mit "Reset" die Unterhaltung zurücksetzen

Hinweise zur Konfigurationsänderung

• TTS-Engine/Stimme ändern: in server.py und audio_module.py anpassen
• LLM-Modell/Backend ändern: in server.py und llm_module.py konfigurieren
• STT-Modell/Stille-Schwellenwert ändern: transcribe.py, turndetect.py
• SSL-Konfiguration möglich: In server.py HTTPS-Nutzung und Zertifikate festlegen

Lizenz

• Veröffentlicht unter der MIT-Lizenz
• Für externe Engines wie Coqui gelten separate Lizenzen

[nicewook]

Das Demo-Video des Originals ist beeindruckend.

1. Ich hatte den Wunsch nach einem natürlichen Gespräch, und auf diesem Niveau scheint das schon ziemlich gut erfüllt zu sein.
2. Ich wollte das Gespräch währenddessen auch in Echtzeit als Text sehen, und dieser Teil gefällt mir ebenfalls.
3. Es wäre gut, wenn die AI mir nicht ins Wort fällt, sondern erst ausreichend zuhört und dann spricht. Wenn sie sich zum Beispiel nicht sicher ist, könnte sie Fragen stellen wie „Hast du schon ausgeredet?“ oder „Kann ich jetzt sprechen?“ und dann erst ihrerseits das Gespräch beginnen.
4. Es wäre auch gut, wenn es etwas gäbe, das sowohl die AI als auch Menschen dazu anhält, einander nicht ins Wort zu fallen.

[GN⁺]

Hacker-News-Kommentare

• Der Grund für die Entwicklung von RealtimeVoiceChat war, dass die Latenz bei den meisten Sprach-KI-Interaktionen unbefriedigend war. Dieses System ist ein Open-Source-System für Echtzeit-Sprachdialoge lokal auf dem Gerät

  • Ziel ist es, sich einer natürlichen Gesprächsgeschwindigkeit anzunähern
  • Durch Streaming von Audio-Chunks über WebSockets, RealtimeSTT auf Whisper-Basis und RealtimeTTS mit Unterstützung für Engines wie Coqui XTTSv2/Kokoro wird eine Antwortlatenz von etwa 500 ms erreicht
  • Das ist auch möglich, wenn über Ollama größere lokale Modelle wie 24B Mistral ausgeführt werden
  • Hauptmerkmale: für lokale LLMs entwickelt (hauptsächlich Ollama, mit OpenAI-Konnektor), Unterbrechungen möglich, smarte Turn-Erkennung, um den Gedankenfluss des Nutzers nicht zu unterbrechen, Dockerized-Setup zur einfacheren Verwaltung von Abhängigkeiten
  • Aufgrund der STT-/TTS-Modelle wird für die Performance eine CUDA-fähige GPU benötigt
  • Ich würde gern Feedback zum Ansatz, zur Leistung, zu möglichen Optimierungen oder zu unverzichtbaren Funktionen für eine gute lokale Sprach-KI-Erfahrung hören
  • Code: https://github.com/KoljaB/RealtimeVoiceChat

• Als Nutzer solcher Tools: Es ist zwar schnell, erlaubt aber keine Pausen, wie sie beim natürlichen Sprechen vorkommen

  • In Gesprächen machen wir längere und kürzere Pausen, weil wir nachdenken oder aus anderen Gründen
  • Bei solchen Tools beginnt die KI sofort zu sprechen, sobald wir pausieren
  • Vor ein paar Wochen habe ich auf Twitter eine Demo gesehen, in der die KI wartete, bis die Person tatsächlich fertig gesprochen hatte. Die Länge der Pause spielte dabei keine Rolle
  • Ich weiß nicht, wie komplex dieses Problem ist. Vermutlich müsste eine weitere KI den Input analysieren und entscheiden, ob es nur eine Pause ist oder nicht

• Sehr cool! Die Unterbrechungsfunktion war ein "Wow"-Moment (nichts Neues, aber es so gut in Open Source umgesetzt zu sehen, ist beeindruckend)

  • Eine Frage zur Unterbrechungsfunktion: Wie werden Dinge wie "Mmk", "Yes", "Of course", "Husten" usw. behandelt?
  • Abgesehen vom Schmeicheln in OpenAIs Voice-Chat stört mich daran, dass Geräusche die Antwort der KI stoppen und es keinen guten Weg gibt, sie wieder fortzusetzen
  • Schnell zu stoppen und aus den richtigen Gründen zu stoppen, ist ein schwieriges Problem

• Ich habe vor etwa einem Jahr zu diesem Thema recherchiert. Dabei habe ich einige interessante Dinge gelernt

  • In Gesprächen zwischen Menschen beträgt die mittlere Latenz zwischen Sprecherwechseln 0 Millisekunden. Das heißt, ungefähr die Hälfte der Zeit unterbricht ein Sprecher den anderen, wodurch die Latenz negativ wird
  • Menschen stören sich nicht an Latenz, wenn sie mit einer als KI bekannten Instanz sprechen. Sie gehen davon aus, dass die KI Zeit zum Nachdenken braucht. Die meisten Nutzer halten 1000 ms Latenz für akzeptabel und 500 ms für außergewöhnlich
  • Alle Sprachassistenten haben eine minimale Latenz von etwa 300 ms. Das liegt daran, dass sie alle Stille-Erkennung verwenden, um zu entscheiden, wann eine Antwort beginnen soll, und dass etwa 300 ms Stille nötig sind, um sicher von einer normalen Pause des Sprechers unterschieden zu werden
  • Alexa hat eine Einstellung, die diese Wartezeit für langsame Sprecher verlängert
  • In diesem Demo-Video kann man sehen, dass die KI ihn nicht unterbricht. Dadurch fühlt es sich nicht wie eine Interaktion mit einem Menschen an (einschließlich der seltsamen Intonation der Stimme)
  • Menschen verarbeiten Sätze in Echtzeit und antworten, sobald sie sicher sind, genug gehört zu haben, um die Bedeutung des Satzes zu verstehen

• Großartig. Beim Blick in den Source-Code fand ich interessant, dass der Autor statt Silero VAD eine benutzerdefinierte Strategie zur Turn-Erkennung implementiert hat. Ich würde gern wissen, warum das so gemacht wurde und welche Vorteile beobachtet wurden

  • Für alle, die sich für den Stand des Voice-Agent-Bereichs interessieren: Daily (das WebRTC-Unternehmen) bietet ein großartiges Open-Source-Framework mit vielen Utilities und einem hilfreichen Guide
  • Hinweis: Ich arbeite bei Cartesia und betreue viele Use Cases für Voice Agents. Daily ist mit uns befreundet

• Ich habe zunehmend das Gefühl, dass LLMs auf kürzere Antworten abgestimmt werden sollten. Man gibt einen kurzen Satz ein und bekommt einen langen Absatz Text zurück

  • Manchmal ist das guter Text, aber nicht jeder Eingabesatz braucht eine Antwort in Form eines Mini-Essays
  • Sehr cooles Projekt. Wahrscheinlich könnte man den Prompt feinjustieren, um die Gesprächsneigung der KI zu verändern

• Ich bin überrascht, dass das noch niemand erwähnt hat. Es interagiert menschenähnlich und unterbricht mich in vielen Situationen, wenn genug Kontext vorhanden ist. Die Latenz ist sehr niedrig

  • Als ich es das erste Mal benutzt habe, war das ziemlich verblüffend

• Ziemlich gut. Es wäre deutlich besser, wenn es wie SOTA-Sprache klingen würde

• Beeindruckend! Ich denke, das ist die beste Sprachsynthesequalität unter den derzeit verfügbaren Open-Source-Lösungen

  • Das Endziel wäre wohl ein durchgehend laufendes Waveform-zu-Waveform-Modell ganz ohne Text-Token

• Ich habe an etwas Ähnlichem gearbeitet und das hier entdeckt. Tolle Arbeit. Die Demo gefällt mir