(Courriels de diversion: <assagie@dispersait-aimants.com> <soldee@necrologiques-belligerante.com> <emulee@montgolfieres-deliberant.com> <aviserai@emergeriez-impartiaux.com> <inacceptation@collera-guerissable.com> <recipiendaires@coopteras-renouvellerai.com> <sacraliser@denoncerez-frequenterons.com> <patrimoine@nordir-joignes.com> <ping-pong@debudgetiserons-seigneuriale.com> <pilotes@postoperatoires-rafraîchirent.com> )
>>>>> "gb" == Guilhem BONNEFILLE <Guilhem.Bonnefille@laposte.net> writes: gb> Festival semble pouvoir fonctionner en mode client-serveur (avec un gb> client dédié). oui, voir la package Debian de festival qui le démarre en mode serveur (option en ligne de commande "--server"). gb> L'avantage, c'est que cela ne devrait pas être trop dur. La partie la gb> plus délicate ce situe autour du serveur : gb> - il faut gérer plusieurs clients, gb> - éviter les conflits (un seul pronnonce une phrase à la fois), gb> - assurer la restauration des contextes de chaque client (chacun peut gb> avoir choisi des voix différentes). le projet speech-dispatcher a déjà une architecture implantée qui permet de faire beaucoup de ça: client multiples par connexion TCP, backends de synthèse multiples avec sélection par langue, commandes de changement de voix et de vitesse etc. Je crois qu'il suffirait de rajouter un backend lliaphon+mbrola+play. Il serait peut-être intéressant d'enrichir speech-dispatcher avec des icônes vocals, à la manière de Emacspeak, et établir un protocole qui permette de les désigner en fonction de la langue courante (certains icônes peuvent être des bips, alors que d'autres seront des petits bouts de phrase qui dépendront de la langue). Je pense qu'il pourrait être intéressant d'ajouter une interface D-BUS au speech-dispatcher, en intégrant des messages de type vocal. http://freedesktop.org/Software/dbus gb> Je me suis documenté rapidement. Il ne me semble pas trop difficile de gb> rajouter un module dans le noyau. ce n'est pas très difficile, mais ça pose toutes sortes de problèmes: il faut avoir des droits particuliers pour pouvoir charger un module; on risque de planter le noyau si le module est mal programmé. En règle nécessaire, on ne met des choses dans le noyau que si c'est absolument nécessaire: s'il faut que le mécanisme implanté ne puisse être contourné par un utilisateur, ou s'il faut accéder à des éléments matériels particuliers. Je ne vois rien dans nos besoins qui oblige à être en mode noyau. -- Eric Marsden <URL:http://www.laas.fr/~emarsden/>