13 lines
1.7 KiB
Markdown
13 lines
1.7 KiB
Markdown
---
|
||
title: Accusé de réception parlé à la place du bip du wake word
|
||
area: visitapp
|
||
horizon: v1
|
||
tags: visitapp, vocal
|
||
flag: warn | Après les tests
|
||
src: voice-latency-plan.md §2
|
||
---
|
||
<p>Remplacer <code>wake_detected.mp3</code> par une phrase dans la langue et la voix du visiteur — « Oui, je vous écoute » — avec 2-3 variantes, un visiteur entendant l'ack des dizaines de fois sur une visite.</p>
|
||
<p><strong>Retenu, mais explicitement après les tests</strong> : ça demande de générer et valider <em>à l'oreille</em> ~40 fichiers (2 voix × 4 langues × 5 phrases), et une partie du besoin que l'ack compense disparaît si le découpage par phrase fait baisser la latence. Décider avant d'avoir entendu le flux, ce serait décider à l'aveugle.</p>
|
||
<p>⚠️ <strong>Trois pièges déjà identifiés.</strong> <code>pubspec.yaml:133</code> déclare <code>assets/sounds/</code> mais <strong>les déclarations de dossier ne sont pas récursives en Flutter</strong>. Générer avec exactement le même <code>voicePrompt</code> que le runtime, sinon le timbre décroche entre l'ack et la réponse — et Gemini TTS n'est pas déterministe, prévoir plusieurs prises. ⛔ Et une <strong>règle de cohérence non négociable</strong> : sans <code>GEMINI_API_KEY</code> le moteur retombe sur la voix système Android — des acks en Sulafat suivis d'une réponse en voix système seraient <em>pires</em> que le bip. Acks actifs seulement si le moteur runtime est Gemini et que la voix correspond à <code>guideVoiceId</code>.</p>
|
||
<p>Ordonnancement à calibrer sur place : ouvrir le micro à <code>player.duration - 150ms</code> plutôt que de faire de l'AEC — sur Ray-Ban, micro et haut-parleur partagent la monture.</p>
|