Funktionsweise
Wie die lokale Engine läuft, wie sich die Wayland- und X11-Erfassung tatsächlich unterscheidet, was die Oberfläche hinzufügt und was „Null Latenz“ genau bedeutet, mit gemessenen Werten.
Ein lokaler Orchestrator, kein Cloud-Dienst
PiperRead ist ein schlankes Bash-Skript zwischen Ihrem Desktop und der neuronalen Text-to-Speech-Engine Piper — es synthetisiert selbst keine Sprache. Piper wird einmal installiert, in einer eigenen virtuellen Python-Umgebung, sodass es die bereits auf Ihrem System vorhandenen Python-Pakete nicht berührt.
Das Netzwerk ist genau zweimal beteiligt, jeweils nur einmal: pip lädt die Piper-Engine herunter (etwa 75 MB, 200 bis 250 MB nach dem Entpacken), und ein Stimmmodell (eine .onnx-Datei, einige Dutzend Megabyte) wird heruntergeladen, wenn Sie erstmals eines auswählen. Danach besteht das Vorlesen einer Auswahl aus drei lokalen Schritten — Text erfassen, ihn durch die bereits auf dem Datenträger vorhandene Engine verarbeiten, die resultierende Audiodatei mit aplay abspielen — und keiner der drei Schritte öffnet eine Netzwerkverbindung. Kein von Ihnen ausgewählter oder kopierter Text verlässt zum Vorlesen die Maschine.
Lesen der Auswahl: Wayland und X11
PiperRead tippt oder fügt niemals in ein anderes Fenster ein — es liest nur nach außen, vom jeweils Ausgewählten oder Kopierten in die Engine. Diese unidirektionale Erfassung ist die einzige Stelle, an der Wayland und X11 unterschiedliche Wege nehmen, und der Unterschied ist eine Wahl des Werkzeugs, kein Unterschied im Verhalten:
| Gelesene Quelle | Wayland | X11 |
|---|---|---|
| Mausauswahl (primary) | wl-paste --primary | xsel --primary |
| Zwischenablage | wl-paste | xsel --clipboard |
Es erfolgt keine Prüfung von XDG_SESSION_TYPE oder eines anderen Sitzungs-Flags. read.sh versucht zuerst den Wayland-Befehl; wenn er fehlt oder nur Leerzeichen zurückgibt, fällt es auf den X11-Befehl zurück. Unter Wayland gelingt wl-paste und der X11-Pfad wird nie erreicht; unter X11 fehlt wl-paste entweder oder gibt nur Leerzeichen zurück, sodass stattdessen xsel übernimmt. Standardmäßig versucht PiperRead zuerst die Mausauswahl und liest die Zwischenablage nur, wenn nichts ausgewählt ist; wenn Sie explizit den Nur-Auswahl- oder Nur-Zwischenablage-Modus anfordern, wird dieser Fallback übersprungen und nur die von Ihnen genannte Quelle gelesen.
Die Oberfläche
PiperRead gibt es auch mit einer Oberfläche, in einem separaten Paket, das die Download-Seite zusammen mit dem Launcher installiert: ein Tray-Symbol, das beim Sitzungsstart öffnet und die Stimme geladen hält. Es ersetzt nicht den Launcher, und keines steuert das andere. Es führt die Piper-Engine als separates Programm aus, das über HTTP antwortet, nur auf 127.0.0.1 und nie auf einer Netzwerkschnittstelle, und es erfasst den Text wie der Launcher (Mausauswahl, dann Zwischenablage) unter Linux oder aus der Zwischenablage unter Windows. Es synthetisiert den nächsten Satz, während der aktuelle abgespielt wird, was der zweite Wert unten misst.

Auch keine Nutzungsereignisse
Die Inferenz-Bibliothek, die Piper einbindet, onnxruntime, sendet standardmäßig Nutzungsereignisse an Microsoft. PiperRead schaltet sie vor dem Start der Engine ab: strace zeigt während des Vorlesens keine Verbindung nach außen, weder mit dem Launcher noch mit der Oberfläche. Unter Windows meldet die Bibliothek ihre Ereignisse an das System, statt sie selbst zu senden, daher verwendet PiperRead den eigenen Schalter der Bibliothek; eine Messung fand dennoch 4 Initialisierungsereignisse, gegenüber 15 ohne den Schalter. Die Einstellung telemetry=on schaltet sie wieder ein.
Was „Null Latenz“ bedeutet und was gemessen wurde
„Null Latenz“ bezeichnet zunächst eine architektonische Tatsache: Da Piper als lokaler Prozess läuft, gibt es keinen Netzwerk-Roundtrip zwischen dem Auswählen eines Satzes und dem ersten Ton — nichts, worauf Sie auf einem entfernten Server warten müssten. Es ist kein Versprechen einer Dauer. Zwei Dauern wurden gemessen, und sie werden hier mit ihren Bedingungen veröffentlicht.
| Pfad | Gemessen |
|---|---|
| Launcher: Die Stimme wird bei jedem Klick geladen | 1,31 bis 1,34 s vom Start bis zum ersten Audiobyte |
| Oberfläche: Die Stimme bleibt geladen, der nächste Satz wird vorbereitet, während einer abgespielt wird | 168 ms vom Klick bis zur Öffnung des Audiostreams |
Gemessen am 23. September 2026, unter Linux, auf der Maschine des Betreuers (32 Kerne), mit der Stimme fr_FR-siwis-medium. Auf einer anderen Maschine oder mit einer anderen Stimme ändern sich die Werte: Sie geben eine Größenordnung an, keine Garantie. Der Launcher zahlt etwa 1,3 Sekunden, weil er bei jedem Vorlesen die Engine startet und die Stimme lädt. Die Oberfläche zahlt das einmal, beim Start, und hält die Stimme im Speicher: etwa 150 MB, bis zu 370 MB nach Gebrauch, und keine Prozessorzeit im Ruhezustand.