(Courriels de diversion: <belligerante@emulee-montgolfieres.com> <deliberant@aviserai-emergeriez.com> <impartiaux@inacceptation-collera.com> <guerissable@recipiendaires-coopteras.com> <renouvellerai@sacraliser-denoncerez.com> <frequenterons@patrimoine-nordir.com> <joignes@ping-pong-debudgetiserons.com> <seigneuriale@pilotes-postoperatoires.com> <rafraîchirent@editerions-propages.com> <disconveniez@relationnels-sylvestres.com> )
On Sat, 7 Feb 2004 22:02:49 +0000 (UTC)
philsfree@free.fr (Phil's Free) wrote:
> - LLiaPhon puis FranFest
> afin de fournir un serveur vocal appelable par des clients légers et
> ne monopolisant pas inutilement la carte son.
J'ai un peu réfléchis sur ce point : un serveur/demon appelable soit par
client dédié soit par l'intermédiaire d'un device à nous. Voici un mail
que j'avais envoyé en privé a favdb et qui retrace assez bien mes idées
sur le sujet.
Voici ou j'en suis.
Existant
========
Festival semble pouvoir fonctionner en mode client-serveur (avec un
client dédié).
Il faudrait que je regarde comment font brltty.
Client-Serveur
==============
Sur cette idée, on peut envisager un lliaphon_serveur initialisant la
synthese (données et processus mbrola et play) puis attendant des
clients. Ces clients se connectent, et envoient les commandes
(changement de voix, de vitesse...) et le texte au serveur. Celui-ci
assure qu'une seule phrase (dans le cas de plusieurs clients simultanés)
est prononcée à la fois.
L'inconvénient : il faut développer des clients spécifiques. On peut
néanmoins envisager un client générique permettant de faire :
$ echo "Bonjour monde !" | lliaphon_client -v voix ...
L'avantage, c'est que cela ne devrait pas être trop dur. La partie la
plus délicate ce situe autour du serveur :
- il faut gérer plusieurs clients,
- éviter les conflits (un seul pronnonce une phrase à la fois),
- assurer la restauration des contextes de chaque client (chacun peut
avoir choisi des voix différentes).
Module noyau
============
Je me suis documenté rapidement. Il ne me semble pas trop difficile de
rajouter un module dans le noyau.
On peut envisager ceci : un fichier spécial /dev/lliaphon est créé. Il
peut être ouvert en écriture le plus simplement du monde (par exemple,
"echo 'Bonjour monde !' > /dev/lliaphon" et aussi "cat fichier.txt >
/dev/lliaphon" et aussi, depuis un prog C 'fopen("/dev/lliaphon",
O_W);'). Ainsi, n'importe quelle commande produisant un texte peut alors
être prononcée, sans adaptation du programme en question. En plus,
chaque 'client' se retrouve, apres ouverture, avec son propre device ce
qui nous permet de faire des 'sessions' pour éviter de tout mélanger et
de garder un contexte par client.
On peut aussi envisager un répertoire /dev/lliaphon/ dans lequel on
trouve plusieurs devices, par exemple :
- un par voix (/dev/lliaphon/fr1,.../fr7),
- en fonction de priorité,
- un par type de texte : /dev/lliaphon/theatre,
/dev/lliaphon/texte_seul, /dev/lliaphon/systeme, ...
Ici, la difficulté (et donc l'intérèt) c'est que je connais pas. En
particulier, je ne sais pas comment, depuis le noyau, on peut discuter
avec un programme externe (le vrai lliaphon, celui qui lit les fichiers
de conf mais aussi celui qui gère d'autres procs). Probablement, le plus
simple est de faire un /dev/lliaphon/output dans lequel le vrai lliaphon
va lire le flux de texte produit par le 'multiplexage' des textes des
différents clients.
On peut aussi prévoir un /proc/lliaphon pour diriger la synthèse
(déclaration du nombre de voix supportées ou utilisable ou simplement
activation/désactivation de la prononciation...).
Bref, plein de possibilités.
Avant d'aller plus loin, il faudrait peut-etre qu'on se mette d'accord
histoire d'éviter les évaporation d'énergies. Tout ceci était ton idée
au départ. Comme un mal-élevé je me suis incrusté dans tes réflexions.
Si tu veux travailler seul sur ce sujet, n'hésite surtout pas à me le
dire, je ne le prendrai pas mal. Si non, je pense qu'il y a au moins du
travail pour deux :
- spécification de haut niveau : quelles commandes offrir, par quelles
interfaces (directives dans le flux de données, ioctl, ...)...;
- analyze de très bas niveau : que nous permet linux, comment
architecturer le tout...
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 -=- JID: guyou@amessage.be-= mailto:guilhem.bonnefille@laposte.netmailto:guilhem.bonnefille@free.fr-= http://nathguil.free.fr/ http://home.tele2.fr/nathguil/