Comment ça marche
Comment fonctionnent le moteur local, la capture réelle Wayland/X11, ce qu'apporte l'interface, et ce que signifie précisément « latence zéro », avec des chiffres mesurés.
Un orchestrateur local, pas un service cloud
PiperRead est un script Bash léger qui se situe entre votre bureau et le moteur neuronal de synthèse vocale Piper — il ne synthétise pas la parole lui-même. Piper s’installe une seule fois, dans son propre environnement virtuel Python, de sorte qu’il ne touche jamais aux paquets Python déjà présents sur votre système.
Le réseau intervient exactement deux fois, à chaque fois une seule fois : pip télécharge le moteur Piper (environ 75 MB, 200 à 250 MB une fois décompressé), et un modèle de voix (un fichier .onnx, quelques dizaines de mégaoctets) est téléchargé la première fois que vous en choisissez un. Ensuite, lire une sélection se fait en trois étapes locales — capturer le texte, le passer dans le moteur déjà présent sur le disque, lire l’audio obtenu avec aplay — et aucune des trois n’ouvre de connexion réseau. Aucun texte que vous sélectionnez ou copiez ne quitte la machine pour être lu à voix haute.
Lecture de la sélection : Wayland et X11
PiperRead ne tape ni ne colle jamais dans une autre fenêtre — il lit seulement vers l’extérieur, depuis ce qui est sélectionné ou copié, vers le moteur. Cette capture unidirectionnelle est le seul endroit où Wayland et X11 suivent des chemins différents, et la différence est un choix d’outil, non une différence de comportement :
| Source lue | Wayland | X11 |
|---|---|---|
| Sélection de la souris (primaire) | wl-paste --primary | xsel --primary |
| Presse-papiers | wl-paste | xsel --clipboard |
Il n’y a aucune vérification de XDG_SESSION_TYPE ni d’aucun autre indicateur de session. read.sh essaie d’abord la commande Wayland ; si elle est absente, ou ne renvoie que des caractères blancs, il se rabat sur la commande X11. Sous Wayland, wl-paste réussit et le chemin X11 n’est jamais atteint ; sous X11, wl-paste est soit absent soit ne renvoie que des caractères blancs, donc xsel prend le relais à la place. Par défaut, PiperRead essaie d’abord la sélection de la souris et ne lit le presse-papiers que si rien n’est sélectionné ; demander explicitement le mode sélection uniquement ou presse-papiers uniquement ignore ce repli et ne lit que celui que vous avez nommé.
L’interface
PiperRead est également fourni avec une interface, dans un paquet séparé que la page de téléchargement installe avec le lanceur : une icône de la zone de notification qui se lance à l’ouverture de session et garde la voix chargée. Elle ne remplace pas le lanceur, et aucun des deux ne pilote l’autre. Elle exécute le moteur Piper comme un programme séparé qui répond via HTTP, uniquement sur 127.0.0.1 et jamais sur une interface réseau, et elle capture le texte comme le fait le lanceur (sélection de la souris, puis presse-papiers) sous Linux, ou depuis le presse-papiers sous Windows. Elle synthétise la phrase suivante pendant que la phrase en cours est lue, ce que montre la seconde mesure ci-dessous.
Aucun événement d’utilisation non plus
La bibliothèque d’inférence que Piper utilise, onnxruntime, envoie par défaut des événements d’utilisation à Microsoft. PiperRead les désactive avant de démarrer le moteur : strace ne montre aucune connexion vers l’extérieur pendant la lecture, avec le lanceur comme avec l’interface. Sous Windows, la bibliothèque signale ses événements au système au lieu de les envoyer elle-même, donc PiperRead utilise le commutateur propre de la bibliothèque ; une mesure a tout de même relevé 4 événements d’initialisation, contre 15 sans le commutateur. Le réglage telemetry=on les réactive.
Ce que « zéro latence » signifie, et ce qui a été mesuré
« Zéro latence » énonce d’abord un fait architectural : parce que Piper s’exécute en tant que processus local, il n’y a aucun aller-retour réseau entre la sélection d’une phrase et le premier son — rien à attendre d’un serveur distant. Ce n’est pas une promesse de durée. Deux durées ont été mesurées, et elles sont publiées ici avec leurs conditions.
| Parcours | Mesuré |
|---|---|
| Lanceur : la voix est chargée à chaque clic | 1,31 à 1,34 s du lancement jusqu’au premier octet audio |
| Interface : la voix reste chargée, la phrase suivante est préparée pendant la lecture en cours | 168 ms du clic à l’ouverture du flux audio |
Mesuré le 23 septembre 2026, sous Linux, sur la machine du mainteneur (32 cœurs), avec la voix fr_FR-siwis-medium. Sur une autre machine ou avec une autre voix, les chiffres changent : ils donnent un ordre de grandeur, pas une garantie. Le lanceur coûte environ 1,3 seconde parce qu’il démarre le moteur et charge la voix à chaque lecture. L’interface ne paie ce coût qu’une fois, au démarrage, et garde la voix en mémoire : environ 150 Mo, jusqu’à 370 Mo après utilisation, et aucun temps processeur au repos.