Projekt JARVIS, Der erste Linux Satellit: JARVIS bekommt Ohren und eine Stimme

Chris // 28 Aug, 2026

Bisher lief ein großer Teil von JARVIS dort, wo die Entwicklung angefangen hat.

Auf dem Server und im Terminal.

Das ist zum Testen praktisch. Für einen persönlichen Assistenten ist es allerdings nicht besonders hilfreich, wenn ich mich erst per SSH auf einem Server anmelden muss, um mit ihm zu sprechen.

Irgendwann musste JARVIS also den Server verlassen.

Nicht vollständig natürlich.

Der eigentliche Core soll weiterhin zentral laufen.

Aber Mikrofon, Lautsprecher und die Interaktion mit dem Benutzer sollen auf kleinen Geräten verteilt werden können.

Genau dafür gibt es jetzt den ersten Linux Satelliten.

Was ist ein Satellit?

Die Idee ist relativ einfach.

Der JARVIS Core läuft zentral auf einem Server.

In verschiedenen Räumen können kleine Geräte stehen, die sich mit diesem Core verbinden.

Ein solcher Satellit braucht im Grunde nur einige wenige Dinge:

1. Ein Mikrofon
2. Einen Lautsprecher
3. Eine Netzwerkverbindung
4. Eine Verbindung zum JARVIS Voice Service

Der Satellit selbst muss dabei nicht die komplette Intelligenz enthalten.

Er nimmt Sprache entgegen, schickt sie an den Server und gibt die Antwort anschließend wieder aus.

Die eigentliche Verarbeitung bleibt zentral.

Damit kann ein zukünftiges Setup beispielsweise so aussehen:

Wohnzimmer Satellit
        |
        v
JARVIS Voice
        |
        v
JARVIS Core
        |
        v
Tools und LLM

Und parallel dazu könnte ein zweiter Satellit in einem anderen Raum mit demselben Core verbunden sein.

Warum Linux?

Für den ersten Satelliten wollte ich bewusst keine komplett eigene Hardware entwickeln.

Ein Linux System bietet für die Entwicklung einige Vorteile.

Audio lässt sich relativ einfach testen.

Python kann direkt verwendet werden.

Fehler lassen sich per SSH untersuchen.

Updates können wie bei einem normalen Server verteilt werden.

Außerdem ist die Hardware nicht fest vorgegeben.

Der Linux Satellit soll langfristig nicht nur auf einem bestimmten Gerät funktionieren.

Ein Raspberry Pi mit USB Mikrofon und Lautsprecher könnte genauso ein Satellit sein wie ein anderes kleines ARM System.

Das erste Testgerät ist allerdings etwas spezieller.

Der ReSpeaker Core v2

Für die ersten Versuche verwende ich einen älteren ReSpeaker Core v2.

Das Gerät besitzt mehrere Mikrofone, Audioausgänge, LEDs und einen eigenen Linux Rechner.

Eigentlich ziemlich passend für einen Sprachassistenten.

Allerdings stammt die Hardware nicht gerade aus dem Jahr 2026.

Auf meinem Gerät läuft:

Debian 9
Kernel 4.4.138
ARMv7

Damit wurde die Installation direkt etwas interessanter als geplant.

Die normalen Debian Paketquellen für Debian Stretch existieren inzwischen nicht mehr an den ursprünglichen Adressen.

Die ersten Updates endeten deshalb erwartungsgemäß mit HTTP 404 Fehlern.

Also mussten zunächst die alten Debian Archive eingebunden werden.

Danach ließ sich das System wieder aktualisieren.

Der erste Erfolg des Satellitenprojekts war damit nicht Spracherkennung.

Es war:

apt update funktioniert wieder.

Auch das gehört offenbar zum Bau eines KI Assistenten.

Ein eigener Satellite Client

Der Linux Satellit läuft als eigenes Projekt.

Er bekommt eine kleine Konfiguration mit den wichtigsten Informationen:

Satellite ID
Core Adresse
Voice Port
API Token
Audio Gerät
Sample Rate
Kanäle

Anschließend verbindet er sich mit dem Voice Service des JARVIS Core.

Die Kommunikation läuft über WebSockets.

Beim Start sieht das beispielsweise so aus:

Satellite ID: satellite-respeaker-v2

Core verbunden

Voice Protocol:
jarvis.voice.v1

Audio:
hw:0,0

Sample Rate:
16000 Hz

Damit weiß der Satellit zunächst nur:

Der Core ist erreichbar.

Die Authentifizierung funktioniert.

Und die beiden Seiten sprechen dasselbe Protokoll.

Das klingt noch nicht besonders beeindruckend.

Es ist aber die Grundlage für alles Weitere.

Der erste Audiotest

Im ersten Test wollte ich bewusst noch kein Wake Word einbauen.

Es gibt zunächst eine sehr einfache Steuerung.

ENTER drücken.

Der Satellit nimmt einige Sekunden Audio auf.

Danach werden die Daten an den Voice Service geschickt.

Der Ablauf sieht ungefähr so aus:

ENTER drücken

Aufnahme läuft

Audiodaten werden gesendet

STT verarbeitet Sprache

JARVIS verarbeitet die Anfrage

Antwort wird erzeugt

TTS erzeugt Audio

Satellit spielt Antwort ab

Damit lässt sich jede einzelne Stufe relativ gut testen.

Gerade während der Entwicklung ist das deutlich angenehmer als eine Wake Word Erkennung, die ständig zusätzlich Fehler verursachen könnte.

Und dann hat es tatsächlich funktioniert

Der erste komplette Test war ziemlich unspektakulär.

Ich habe gefragt:

Wie wird das Wetter?

Der Satellit hat die Sprache aufgenommen.

Die Audiodaten wurden an den Server geschickt.

Die Spracherkennung hat daraus Text erzeugt.

JARVIS hat die Wetterfunktion aufgerufen.

Und anschließend kam die Antwort zurück.

Sinngemäß:

In Geisenheim ist es heute bewölkt.

Die Temperaturen liegen ungefähr zwischen
14 und 25 Grad.

Nennenswerter Niederschlag wird nicht erwartet.

Damit funktionierte zum ersten Mal die komplette Kette:

Mikrofon

Sprache

STT

JARVIS Core

Tool

LLM

Antwort

TTS

Lautsprecher

Das war wahrscheinlich einer der größeren Meilensteine des Projekts.

Nicht weil die Wetterabfrage neu wäre.

Die konnte JARVIS schon vorher.

Sondern weil ich sie zum ersten Mal einfach in den Raum sprechen konnte.

STT und TTS bleiben auf dem Server

Bei der Entwicklung stellte sich relativ schnell eine wichtige Architekturfrage.

Wo sollen Speech to Text und Text to Speech eigentlich laufen?

Direkt auf jedem Satelliten?

Oder zentral auf dem Server?

Für den Moment habe ich mich für die zentrale Variante entschieden.

Der Satellit kümmert sich hauptsächlich um:

Audioaufnahme

Audiowiedergabe

Verbindung zum Core

Hardwaresteuerung

Statusanzeige

Die rechenintensiveren Aufgaben laufen auf dem Voice Server.

Das hat mehrere Vorteile.

Ein Satellit braucht deutlich weniger Rechenleistung.

Die Sprachmodelle müssen nicht auf jedem Gerät installiert werden.

Updates müssen nur zentral durchgeführt werden.

Und auch ältere Hardware kann weiterhin als Ein und Ausgabegerät verwendet werden.

Der ReSpeaker Core v2 ist dafür ein ziemlich gutes Beispiel.

Als moderner KI Rechner ist er nicht besonders interessant.

Als Mikrofon und Lautsprecher mit Netzwerkanschluss dagegen schon.

Linux Satellit bedeutet nicht ReSpeaker Satellit

Ein Punkt ist mir dabei wichtig.

Der aktuelle Client ist kein reines ReSpeaker Projekt.

Der ReSpeaker Core v2 ist lediglich die erste getestete Hardware.

Die allgemeine Architektur des Satelliten soll unabhängig davon funktionieren.

Der Kern des Clients braucht lediglich ein Linux System und funktionierende Audiogeräte.

Hardwareabhängige Funktionen werden separat behandelt.

Beim ReSpeaker sind das beispielsweise die LEDs und der Taster.

Ein normaler Raspberry Pi besitzt diese Funktionen möglicherweise gar nicht.

Der eigentliche Voice Client funktioniert trotzdem.

Langfristig könnten also verschiedene Geräte denselben Linux Satellite Client verwenden.

Die LEDs des ReSpeaker

Wenn die Hardware schon einen LED Ring besitzt, möchte man ihn natürlich auch benutzen.

Die LEDs sollen später den aktuellen Zustand des Satelliten anzeigen.

Zum Beispiel:

Bereit

Hört zu

Verarbeitet

Antwortet

Stumm

Fehler

Aus

Das klingt zunächst nach einer einfachen Spielerei.

In der Praxis ist eine visuelle Rückmeldung bei einem Sprachassistenten allerdings sehr hilfreich.

Wenn ich eine Frage stelle, möchte ich wissen:

Hat das Gerät mich gehört?

Nimmt es gerade auf?

Verarbeitet der Server noch?

Oder ist etwas schiefgegangen?

Bei den ReSpeaker LEDs gab es erwartungsgemäß ebenfalls einige Besonderheiten.

Vor allem verschiedene LED Varianten der Hardware wollten unterschiedlich behandelt werden.

Damit bekam der Client schließlich eine eigene Hardwareerkennung.

Der Taster bekommt ebenfalls Funktionen

Der ReSpeaker besitzt außerdem einen physischen Taster.

Auch dieser wird inzwischen verwendet.

Kurzes Drücken schaltet zwischen stumm und aktiv um.

Ein längeres Drücken kann den Satelliten ein oder ausschalten.

Ein noch längeres Drücken startet das Gerät neu.

Vor den entsprechenden Aktionen zeigen die LEDs den Statuswechsel an.

Damit kann der Satellit komplett ohne Tastatur bedient werden.

Das ist wichtig, wenn das Gerät später einfach irgendwo im Raum steht.

Konfiguration automatisch erzeugen

Beim Installieren und Aktualisieren möchte ich möglichst wenig manuell konfigurieren müssen.

Der Installer beziehungsweise Updater erkennt deshalb die unterstützte Hardware.

Wird beispielsweise ein ReSpeaker erkannt und die passende Hardwarekonfiguration fehlt, kann die Datei automatisch angelegt werden.

Der Linux Client bleibt trotzdem allgemein.

Hardwaredetails landen in einer eigenen Konfiguration.

Damit lässt sich später weitere Hardware ergänzen, ohne den eigentlichen Voice Client komplett umzubauen.

Sicherheit gehört auch hier dazu

Natürlich soll sich nicht einfach irgendein Gerät mit dem Voice Service verbinden dürfen.

Deshalb verwendet auch der Satellit einen API Token.

Dieser wird lokal in einer Umgebungsdatei gespeichert.

Beim Aufbau der Verbindung sendet der Client den Token als Bearer Token an den Core.

Damit kann der Server prüfen, ob der Satellit überhaupt berechtigt ist.

Langfristig möchte ich die Verwaltung noch erweitern.

Beispielsweise könnte jeder Satellit einen eigenen Token bekommen.

Damit ließen sich einzelne Geräte gezielt sperren oder austauschen.

Warum ein eigenes Protokoll?

Für die Kommunikation zwischen Core und Satellit gibt es inzwischen eine definierte Protokollversion:

jarvis.voice.v1

Das klingt zunächst etwas übertrieben.

Für die weitere Entwicklung ist es allerdings wichtig.

Denn neben dem Linux Client gibt es inzwischen auch erste Experimente mit ESP32 Hardware.

Später könnten weitere Satelliten folgen.

Alle müssen verstehen, welche Nachrichten der Server sendet.

Zum Beispiel:

reset
audio_start
audio_end
text
response
error

Mit einer klaren Protokollversion kann der Core später erkennen, ob ein Client überhaupt kompatibel ist.

Das dürfte spätestens dann wichtig werden, wenn unterschiedliche Versionen der Satelliten gleichzeitig im Netzwerk laufen.

Der Satellit ist eigentlich ziemlich dumm

Und das ist durchaus Absicht.

Ein Satellit soll möglichst wenig über JARVIS wissen müssen.

Er muss nicht wissen, wie Wetterdaten abgerufen werden.

Er muss keine Kalender verstehen.

Er muss nicht wissen, welches Sprachmodell verwendet wird.

Im Idealfall weiß er nur:

Ich höre Audio.

Ich sende Audio.

Ich empfange eine Antwort.

Ich spiele Audio ab.

Die Intelligenz sitzt zentral.

Dadurch kann ich später das LLM wechseln, neue Tools hinzufügen oder die komplette interne Architektur verändern.

Die Satelliten müssen davon möglichst wenig mitbekommen.

Wie geht es weiter?

Der aktuelle Linux Satellit ist vor allem die erste funktionierende Referenz.

Als Nächstes möchte ich die Hardwareunterstützung weiter abstrahieren.

Ein Raspberry Pi 5 liegt beispielsweise bereits für weitere Tests bereit.

Zusätzlich experimentiere ich mit einem ESP32 S3 als deutlich kleinerem Satelliten.

Langfristig könnte es damit mehrere Geräteklassen geben.

Ein einfacher Satellit für Sprache.

Ein Satellit mit Display.

Ein leistungsfähigerer Satellit mit guten Lautsprechern für Musik.

Und eventuell spezielle Geräte für einzelne Räume.

Alle sprechen jedoch mit demselben Core.

Der aktuelle Stand

Der Linux Satellit kann inzwischen:

1. Sich per WebSocket mit dem Voice Server verbinden
2. Sich mit einem Bearer Token authentifizieren
3. Das Protokoll jarvis.voice.v1 verwenden
4. Audio über ALSA aufnehmen
5. Audiodaten an den Server übertragen
6. STT auf dem zentralen Voice Server verwenden
7. Anfragen an den JARVIS Core weitergeben
8. Antworten empfangen
9. TTS Audio wiedergeben
10. Hardwareadapter für spezielle Geräte verwenden
11. Beim ReSpeaker LEDs ansteuern
12. Beim ReSpeaker den Hardwaretaster verwenden
13. Eigene Hardwarekonfigurationen automatisch anlegen

Damit hat sich JARVIS erneut ein Stück weiter vom ursprünglichen Terminalprojekt entfernt.

Am Anfang habe ich eine Frage eingetippt und eine Textantwort bekommen.

Jetzt kann in einem Raum ein kleines Linux Gerät stehen, das mit dem zentralen Assistenten spricht.

Und genau das war ursprünglich einer der Punkte, die mich an den ganzen JARVIS Videos überhaupt fasziniert haben.

Einfach eine Frage in den Raum stellen.

Und eine Antwort bekommen.

Der Unterschied ist nur:

Diesmal weiß ich ziemlich genau, was zwischen diesen beiden Momenten alles schiefgehen kann.