Coupure aléatoire des premiers mots en TTS

Bonjour,

Y aurai-t’il une astuce pour éviter que les premiers mots soit coupés lors de l’activation des phrases en tts.

Je m’explique, je me sers essentiellement de TTscat pour le plugin alarme.
Lorsque j’active mon alarme, ttscast envoie un son vers mon Google Nest Hub max en stipulant que l’alarme est en route. Idem lorsque je rentre en me disant qu’elle est désactivée etc…

Seulement, une fois sur deux, je n’entend que la fin de la phrase.

Y aurai-t’il une astuce pour mettre un vide avant la phrase histoire que le tts passe correctement?

Cordialement.

Bonjour @Neoseb38,

Et moi qui pensait que j’avais réussi à éradiquer ces coupures en début de diffusion :frowning:

Je vais regarder ce qu’il est possible de faire (il y a des choses possibles, mais pas implémentées à date), mais avant j’ai besoin d’infos complémentaires :

Lorsque tu as des coupures, est ce que la phrase TTS qui est à diffuser est très courte ? courte ? longue ? (un exemple aiderait à reproduire le phénomène)

Est ce que c’est systématique ? de temps en temps (et si c’est de temps en temps : est-ce qu’il y a qqch qui change par rapport aux autres fois ?)

Et enfin, quel moteur TTS utilises-tu dans le plugin ? (si tu peux mettre une capture d’écran de la page de config du plugin)

TiTidom.

Coucou,

Lorsque j’ai des coupures, c’est je dirai une fois sur 3 qu’il me manque le début de la phrase.

Voici quelques screen de ma config ttscast et de mon plugin alarme.
Je me suis servi des wait car sinon quand je laisse une fenetre ouverte accidentellement et que l’alarme passe en ko, la phrase ne passait pas.

A savoir que je viens juste de retirer tous les (ding": false) de chaque messages et je dirai que c’est bien mieux et plus réactif désormais.
Mais ca arrive qu’un mot au début ne passe pas. (mais bien mieux)

Exemple: de temps en temps, pour la mise en route de l’alarme ca me dit …tivation de l’alarme en cours…
et quand ko, …tention au lieu de attention …

Re,

Merci pour ces captures, c’est plus clair comme ca :+1:

La bonne nouvelle pour toi, c’est qu’avec ce moteur TTS (Google Cloud TTS) j’ai une solution en tête :wink:

Je vais insérer une option (le terme n’est pas figé, il faut que j’y réfléchisse) : "before": "3s" et cela va insérer automatiquement une pause de 3 secondes avant d’énoncer le texte (et bien sûr, la durée sera paramétrable :wink: )

Une autre option sera insérée par la même occasion (car le « before » va l’utiliser) : la langage SSML, via une option "ssml": true qui permet de complètement personnaliser du texte à énoncer en TTS, d’insérer des pauses au milieu, d’énoncer des dates, des heures, et des sigles facilement, etc…

Je regarde cela et reviendrai vers toi avec une nouvelle version du plugin :wink:

TiTidom.

3 « J'aime »

Super ca, merci pour ton travail remarquable et ta réactivité.

Le fait de pouvoir paramétrer le temps de pause sera vraiment une super option.

En effet, je viens de re tester et cette fois ci, c’est carément les deux premiers mots qu’il manque.
J’ai l’impression que lorsque l’on utilise pas le tts durant un certain temps, le nest hub max met du temps à se relancer.

Re,

La version v1.4.1 béta est disponible dès maintenant, avec l’ajout des la commande "before": "3s" et l’option "ssml": true.

Tu me diras si c’est mieux avec cette option ?

Bonne journée,
TiTidom.

Merci, je test ça dès que j’ai un moment et te tiens au courant.

Bonjour,
j’ai pas hub nest mais j’ai le même souci avec des enceintes bluetooth, qui je pense se mettent en standby aussi
Si je lance du son ou autre avant aucun souci
Ca sent le réveil de mise en veille

Exactement, j’ai un plugin sur les HomePods et ca peut aussi se présenter… je pense que personne n’en est exempt…

J’ai vu ton plugin pour les HomePod et tu parles de fonction stop (si mes souvenirs sont bon) dans la documentation.
J’ai pensé que cela servait à palier se genre de problème d’où ma question ici pour savoir si ça se faisait également.

Oui l’idée de stop est d’envoyer un son silence de 0,01 seconde pour réveiller l’équipement juste avant le tts. Mais au final le temps de traitement des deux sons côte à côte fait plus long

2 « J'aime »

Je viens de tester et je ne sais pas trop quoi te dire.

Sur le dashboard en test avec le widget, ca fonctionne.
Par contre, je viens de faire un test pour mon alarme et … pouarff ce que c’est long (j’ai pourtant mis un temps de 2 secondes)
Lorsque j’enclenche mon alarme, c’est sensé parlé et j’ai 1 minute pour sortir.
Si j’ai laissé une fenêtre ouverte, cela me dit la 1ère phrase de la mise en route de l’alarme puis la seconde me stipulant qu’une fenêtre est ouverte.
et lorsque je referme la fenêtre, une dernière phrase s’éxécute.

La j’ai fait un test avec comme rajout le « before »: « 2s ».

J’active l’alarme, le temps que le nest hub max sorte la première phrase, il y a bien 15 secondes.
Puis la seconde phrase comme quoi une fenêtre est ouverte, et bien encore 15 secondes ce qui ne va pas car nous serions déja parti :rofl:

Peut être le fait d’avoir trop de commande , exemple: « volume »: 80, « wait »: 2, « before »: « 2s »

J’ai peut être que j’ai mal fait quelque chose car avant avec googlecast (avant mon passage en 4.4.6) j’avais jamais eu ses lenteurs ou mots coupé (ou alors très rarement)
On va donc trouvé :smiley:

Edit:
En désactivant le before, ca m’a l’air bien plus réactif mais ca reste tout de même aléatoire.
La seconde phrase (en cas d’oublie de fermeture de fenêtre) ne s’active que une fois sur 3 et au bout d’un grand laps de temps) je ne sais pas si cela vient des wait mais si je les enlèves, ca ne fonctionne plus. Avec Googlecast, tout fonctionnait instantanément donc j’ai du mal faire quelquechose.


Bonsoir,

Cela ne devrait quasiment pas jouer sur la durée pour diffuser le son, donc je pense pas.

Cela prend forcément un peu plus de temps de générer un son via du SSML (la syntaxe utilisée par l’option « before »), après, si tu fais 2 fois le test, la 2ème fois, il n’y a plus la génération puisqu’il utilise le cache présent sur le disque de Jeedom.

Ton Jeedom est bien chargé ? il a de la ressource à dispo ou pas bcp ? Cela dépend aussi de ton réseau local (le wifi notamment), de ta liaison internet, bref ca fait bcp de variables (connues que de toi :stuck_out_tongue: )

Cela fait un moment que j’ai pas utilisé le plugin Alarme (moi j’utilise les scénarios pour cette fonction), mais je n’ai aucun soucis particulier, les annonces quelles qu’elles soient sont diffusées en quelques secondes, et je n’ai pas de coupure de mot, donc difficile pour moi de reproduire :open_mouth:

Concernnant le paramètre « before », tu l’as mis sur quel TTS (car il faut le mettre que sur le premier à priori, si c’est une histoire de « mise en veille du google »)

Edit : Comme indiqué dans la doc, le paramètre « before » peut prendre comme valeur des secondes, mais aussi des millisecondes, donc par exemple « before »: « 500ms ». Fais des tests peut être avec différentes valeurs ?

TiTidom.

Coucou et merci pour ta réponse.

Je tourne sur un mini PC dell avec 8giga de ram et ssd 32 giga avec Jeedom installé en direct sur debian 11 os64.
J’ai la fibre à la maison mais Nest Hub Max en wifi en effet.

Je sais que le fait d’avoir retirer les fonctions (ding": false) a grandement améliorer la vitesse d’exécution du tts.
Par contre peut être que mes wait sont mal configuré, mais si je ne les mets pas, la seconde puis 3ème phrase n’avait pas l’air de vouloir venir.
Pourrai-tu me dire si cela te semble ok au niveau options?

En premier, lorsque j’active l’alarme, le son « Activation de l’alarme en cours… »

Puis en cas d’oubli de fermeture d’une fenêtre « Attention trigger etc… »

Et enfin lorsque je referme la fenêtre, « Reprise de la surveillance »

Pour le before, je l’avais mis sur toutes les lignes options ou il y a du texte.

Salut,

Là comme ca il n’y a rien qui me choque dans ce que tu as décris.

Plusieurs pistes :

  • Tester les mêmes notifs TTS à partir d’un scénario pour valider l’ordre des notifs, et si ca passe bien.
  • Dans le plugin Alarme, lancer un scénario plutôt que de lancer les actions direct ?

Dis autrement, il faut d’abord valider quelle est la méthode pour toi la plus fiable pour diffuser plusieurs messages sur ton nest max.

Et enfin, perso, je ne fais pas comme cela (diffuser plusieurs annonces) : avec des variables, je construits une seule notification TTS à diffuser, et une fois qu’elle est construite, je l’envoi en une seule fois au moteur TTS, comme ca tu es SUR que la phrase s’enchainera bien comme souhaité puisqu’il n’y a qu’une seule phrase à diffuser :stuck_out_tongue:

Donc par exemple :

maVariableDebut = « j’active l’alarme »

Si fenêtre ouverte, alors set variable à la valeur : maVariableFenetre = « la fenêtre de la chambre est encore ouverte ! », sinon maVariableFenetre = « tout va bien du côté des fenêtres »

Si porte ouverte, alors set variable à la valeur : maVariablePorte = « la porte du garage est encore ouverte ! », sinon maVariableFenetre = « tout va bien du côté des portes »

Et enfin : variable monTTS = « Bonjour, variable(maVariableDebut), Mais attention, il semble qu’il reste des fenêtres et des portes ouvertes, notamment variable(maVariableFenetre), mais aussi variable(maVariablePorte). Soyez serein, Jeedom veille pendant votre absence »

Et envoyer au moteur TTS la variable « monTTS » :wink:

Autre Info : en général les équipements Google « mangent » une partie de la notification lorsque la phrase à dire est trop courte ! (« J’active l’alarme » par exemple, mais si tu dis, « Bonjour, je vais maintenant activer l’alarme de la maison. Bonne journée », ca passe mieux, car le Google Home a de la matière pour bufferiser le TTS à diffuser…)

TiTidom.

Encore un grand merci pour tout tes conseils.

Je vais regarder tout ca et te tiendrai au courant.

J’ai moins de temps cette semaine mais je test au plus vite.

Coucou,

Aujourd’hui, mon Nest hub Max est hyper réactif, c’est de l’instantané, à ne rien y comprendre :smiley:
J’ai tout de même mis un « before »: « 1s » juste au cas ou histoire de le réveiller avant.

Merci encore.

Sinon, j’aurai une question,

Les « wait » sont désormais obligatoire sinon les phrases suivantes ne démarrent pas. Heureusement que tu en parle dans la doc car avant dans GoogleCast il n’y en avait pas besoin et j’ai bien galéré à trouver la soluce.
Cela me crée certains soucis de temps en temps lorsque la seconde ou troisième phrase à plusieurs scénario.
Il n’y a aucun moyen de faire sans comme dans GoogleCast?

Bonjour @Neoseb38 ,

Bonne nouvelle :slight_smile:

Ce que tu décris comme un « inconvénient » est à la base une amélioration :open_mouth: :

Tout le plugin fonctionne en multi-thread, dis en langage humain, il est capable d’effectuer plusieurs tâches en même temps, donc par exemple si tu as plusieurs google home à la maison, tu peux en même temps lancer une commande TTS sur l’un et sur l’autre, sans avoir à attendre qu’il finisse sa première tâche.

L’effet kisscool de cela, c’est que si tu lances plusieurs commandes TTS à la suite, sans contrôle pour voir si la première est terminée, cela se télescope…

Pour gérer cela il y a plusieurs choses qui ont été implémentées dans le plugin, comme le « wait » qui permet d’ordonnancer les commandes sur un même google home en attendant que le wait d’avant soit terminé avant de démarrer le suivant, mais tu as aussi d’autres méchanismes comme la fonction wait de Jeedom, et tester l’état de ton google home : s’il est en cours de lecture, alors attendre qu’il soit « idle » par exemple. Pour cela tu peux utiliser les commandes IDLE et BUSY :wink:

Bref, il ne faut pas chercher à faire comme l’ancien plugin GoogleCast, car ce plugin n’est PAS un update de l’ancien plugin, mais un nouveau plugin (écrit de zéro) qui a certes la même finalité, mais pas forcément de la même manière :slight_smile:

TiTidom.

1 « J'aime »