[JPI-APK android] Tel Android dedié domotique

j’appelle le tts avec cette ligne"

"$IP_JPI/?action=play&media=$PathMedia/$nom_File_TTS&volume=-1&queue=1&wait=1";

Effectivement la reco vocale est en continue

dans le détail :
au bout de quelques envois on entend l’attaque du son au volume normal puis ça passe en sourdine (presque à 0), pour les tts suivants, certains passe avec un volume normal, d’autres en sourdine et d’autre encore avec l’attaque du son OK puis passage en sourdine
si je fait de la reconnaissance vocale après, le son est nickel

OK donc c’est pas du tts mais du play, j’ai testé qu’avec le tts, effectivement le play a une priorité moindre, je vais regarder…

edit: ok le pb semble se situer avec le queue

edit2: j’arrive pas à reproduire…

je viens de refaire le test avec :

"$IP_JPI/?action=tts&message=$message&volume=-1&queue=1&wait=1";

et j’ai la même chose,

en pratique j’utilise l’un ou l’autre si je veux utiliser une vois voxygen ou celle de VoiceRSS (qui est meilleure mais il y a de la latence pour les gros message.

As tu vérifier que le volume media n’est pas à 0 dans l’interface web quand tu ne lis aucun fichier ?

oui il est toujours à 60%

Et si tu enlève le paramètre volume ?

« $IP_JPI/?action=tts&message=$message&wait=0 »;

edit: je viens de regarder VoiceRSS, j’ai fait un test en ligne et je trouve que ça sonne super mal… Encore pire que la voix google par défaut

edit2: chez moi impossible de reproduire les pb de volumes.
Surtout qu’il y a un timing justement pour éviter les collisions ou les mouvement intempestifs de volumes dans le cas où les play et / ou les tts s’enchaînent…

edit3: ok j’arrive à reproduire, il y a un pile un mauvais interval de 0.3s dans lequel le pb peut survenir.
Si les requêtes s’enchainent vite pas de problème, c’est seulement si il y a entre 0.3s et 0.5s de delay entre les requêtes que ça déconne

edit4: vu que tu utilises le paramètre queue pour mettre en file d’attente, tu n’as pas besoin de mettre le paramètre wait à 1
Si tu mets le wait à 0 ça devrait régler ton problème

Tu peux tester mon edit4 ci-dessus je pense que ça devrait résoudre ton problème.
En attendant je vais regarder pourquoi ça fait ça…

sans volume idem :frowning:

j’ai envoyé cette phrase 5 fois de suite,
la consommation de la lampe du bureau du salon é actuellement de 99

avec des pause de 0 ou 1sec ou 2 sec entre chaque, les 2/3 des messages ont ce problème de volume, en fait après l’attaque sur la con … le son baisse et j’ai l’impression que ‹ de la lampe › est carrément sauté avant de reprendre la fin de la phrase en sourdine

j’ai aussi essayé de toutes les combinaison des flags wait, queue et reloadEngine

Essayes avec wait=0 queue=1 et aucune pause entre les requêtes ça devrait régler ton soucis

test fait avec 25 messages :slight_smile: et

"$IP_JPI/?action=tts&message=$message&queue=1&wait=0";

ca passe nickel !!!! bravo !!!

Pour voiceRSS c est curieux, j ai un message le matin qui dure 10mn !!! (météo plus les titres du monde plus plus, et c est de loin la meilleures voix (chez moi) Fabienne ta copine est sympa mais voicerss est plus naturelle dans sa vocalisation

j utilse ce code, tu y verras mes paramètrages :

function VoiceRSS($nom_File_TTS, $message, $pathMedia) {
		// Nettoyage du message
		$message = htmlspecialchars ($message);
		include_once getRootPath() . ('/mg/ressources/voicerss_tts.php');
		$tts = new VoiceRSS;
		$params = [
			'key' => self::getParams('Global', 'API_VoiceRSS'),
			'hl' => 'fr-fr',
			'src' => $message,
			'r' => '0',
			'c' => 'mp3',
			'f' => '44khz_16bit_stereo',
			'ssml' => 'false',
			'b64' => 'false'
			];
		$voice = $tts->speech($params);
		$fileTTS = getRootPath() . "$pathMedia/$nom_File_TTS";
		sleep(1);
		file_put_contents($fileTTS, $voice['response']);
}

Merci Djul des précisions. Tu as quelques photos de tes montages de chargeur en lieu et place des batteries ?
Idem comment gères tu le dongle microsub ethernet sur Android. On branche et pas de WiFi sur le tel il prend sa connexion ?

Non j’ai pas de photo, mais j’ai juste déssoudé la batterie et relié une alim 5v 1A qui est sur onduleur à la place.
Pour le dongle ethernet attention de vérifier avant que ça marche car c’est pas le cas sur toutes les ROMs.
Une fois reconnu pas besoin de Wifi, il y a un menu ethernet dans les menus android pour réglé l’ip, si DHCP ou manuel…

1 « J'aime »

J’ai réglé le problème (et accessoirement amélioré la réactivité du tts dans les scénarios de commandes vocales)
C’est assez complexe à cause des temporisations de mute pour virer tous les bips de la reconnaissance vocale google.
Le pb venait de là, quand la 2ème action play ou tts était envoyée pile au redémarrage de la reconnaissance pendant le mute d’un de ces bips, et pile après la tempo d’attente d’une éventuelle nouvelle action… Le cas de figure était tout de même rare.
Tu as peut être un petit délais dans les requêtes sur ton réseau, ou à cause de la puissance de ta tablette qui fait que tu te trouvais pile dans cet intervalle que j’ai eu du mal à isoler chez moi.
Bref c’est corrigé, ce sera dans la prochaine maj :wink:

Toujours aussi efficace :slight_smile:

Je reviendrais vers toi demain pour avoir quelques éclaircissement sur les différent paramétrage :pensive: :sleeping: de timing de la reco vocale, j’avoue que je ne capte pas le pourquoi et le comment de ces quelques timer ce qui doit expliquer les problèmes d’enchaînement que j’ai entre les différentes commandes … J’ai cherché sur les forums mais je n’ai rien trouvé comme éclaircissement

Mais demain est un autre jour et je te souhaite la bonne nuit !

Merci, bonne nuit également.

Concernant les timings Il n’y a rien à toucher, le mieux est de garder les valeurs par défaut qui sont parfaites.
Les réglages étaient plus là au début quand je développais la reconnaissance vocale continue, pour pouvoir tester, mais ces réglages sont maintenant plutôt obsolètes.

edit: je parles surtout de ceux-là :

image

bonjour,

cas de figure

reco vocale en cours et opérationnelle
lancement de JPI-url sur une web radio
on ne l’entend pas (priorité à la reco probablement, ok)
on fait une reco vocale, elle fonctionne MAIS on à la radio en surimpression sur la réponse, en fin de réponse la radio se recoupe (ok)

Accessoirement si on ouvre la fenêtre de volume on entend la radio :slight_smile:

PS : en corolaire, quelle commande envoyer à JPI pour arrèter / lancer la commande vocale ?

PS2 : je viens de recevoir ta petite boite ronde :), effectivement la qualité de reco est remarquablement meilleure !!! Merci du tuyaux

edit1 : je posais le problème hier des timing parceque la reco vocale s’arrète souvent au milieux d’une phrase et met souvent 2-3 sec à redémarrer

JPI ne peux pas détecter qu’une lecture est faite ailleurs.
Il faut mettre la reco continue en pause avec l’action VRstatus :wink:

Malheureusement je ne peux rien faire contre ça, ta tablette manque peut être d’un peu de puissance, j’ai des symptômes un peu similaire sur des vieux appareils, la reco bug et se réinitialise plusieurs fois en cas de manque de CPU je pense.
Regarde sur l’écran quand ça arrive, si le micro passe rouge plusieurs fois de suite c’est que c’est ce symptôme.
En utilisation normale et sans parler, le micro doit passer rouge furtivement toutes les 5 secondes.
En parlant ou après avoir parlé le micro ne doit jamais passer en rouge sinon c’est que la reco plante et se réinitialise.

ok, je vais implémenter ça (le VR status) :slight_smile: tu as réponse à tout !

Pour le problème des timing peut être faudrait il un tout petit bip pour signaler que la VR est de nouveaux dispo …
Pour l’instant j’utilise une galaxy tab 4 de plus de 5ans … avant de passer à la galaxy tab 4 ou autres tablette moderne il faut que je m’assure qu’elle soit rootable.
Tu utilises quelle tablette en exploit (ta vidéo est impressionnante sur ce problème de latence/reprise, on ne sent rien ! )

Dans la vidéo c’est un pas une tablette mais un tel Z5 compact qui me sert de DEV et de reco vocale continue.
La reco n’a jamais buguée une seule fois à ce jour.
Faut juste savoir que toutes les 5s de silence on a entre 200 et 300ms de perdu (le temps que la reco se réinitialise).
Pour palier à ce problème il suffit de toujours commencer sa phrase avec un mot inutile.
Après je ne le fais même pas dans la vidéo car c’est vraiment pas de chance de parler pile poil à ce moment là.

PS: Si tu es en BT maintenant pour la reco il y a également un autre problème de timing lié spécifiquement au BT si les requêtes tts ou play sont espacées de moins de 1s après la fin de la lecture.
C’est corrigé dans la version qui arrive