La version la plus récente de ce document se trouve à E.S.D.F.F.M. 0.96. Vous pouvez également trouver ce document au format .info, au format postscript compressé, au format PDF ainsi qu’une archive contenant les fichiers au format HTML.
Il ne s’agit en aucun cas de quelque bricolage permettant tant bien que mal d’utiliser de temps en temps, épisodiquement et en appoint le système Linux. Il s’agit de disposer d’un outil de niveau professionnel. Il s’agirait, même si, ne rêvons pas, cela n’est pas possible en totalité, d’accéder à toutes les applications disponibles sous Linux :
Dans le principe donc, un système vocale doit pouvoir collecter les informations disponibles dans le système (Linux) et les communiquer à l’utilisateur sous forme de messages vocaux. Il semblera dès lors évident à tout un chacun qu’il faut répondre à un certain nombre de questions telles que “quelles informations collecter ?” “Parmi celles-ci lesquelles communiquer à l’utilisateur ?” “Enfin ce dernier choix étant opéré, comment les lui communiquer de la manière la plus intelligible pour lui ?” Au vu de ces questions, une constatation tout aussi immédiate s’impose c’est que chaque concepteur de système vocal aura fait des choix en fonction de ce qu’il estime le plus efficace pour répondre aux dites questions. Un corrolaire encore plus immédiat est que l’utilisateur peut adhérer ou ne pas adhérer aux choix du concepteur ainsi qu’il en va d’ailleurs de tout système informatique voire de tout outil. La conclusion qui ne consiste pas pour moi à me dédouaner de tout parti prix mais au contraire à les assumer simpose d’elle-même : il n’y a pas de “bon système vocal” mais une “bonne adéquation entre un système vocal et un utilisateur”. Emprressons-nous cependant de nous contredire pour affirmer sans plus de complexe qu’il y a quand même des critère objectif pour affirmer qu’un outil est efficace ou non. Personne ne songerait à affirmer qu’une cuillère percée remplira son rôle si ce n’est qu’au moins on ne risque pas de la trop emplir ...
Il n’en reste pas moins que la ou les solutions que je présenterai ici sont celles que j’ai personnellement utilisées et jugées adaptées à mes besoins.
Il ne s’agit en aucun cas ici d’entrer dans les détails techniques mais de donner une idée qui pourra aussi servir de guide pour s’y retrouver dans les différentes pièces du puzzle. En effet, la solution que je propose ne se présente pas (pas encore) sous la forme d’un seul bloc qu’il suffirait d’installer pour que d’un coup la machine se mette à parler. À cela au moins trois raisons : D’abord un tel système nécessite de nombreuses opérations dont certaines sont quand-même d’une certaine complexité ce qui explique qu’elles aient été implémentées dans des outils séparés ; le même développeur n’ayant pas forcément le temps et ou les capacités de s’intéresser à la totalité du mécanisme. Ensuite certaines étapes du processus peuvent présenter un intérêt en soi et être utilisées dans d’autres applications ce qui expliquerait encore qu’elles aient été développées séparément. Enfin n’oublions pas les raisons historiques.
Un système vocal tel que je le présente est donc une sorte de mille-feuilles dont chaque couche réalise une ou plusieurs des opérations qui vont de la collecte des données dans le système à leur transmission à l’utilisateur. À noter qu’aucune raison supérieure n’impose de séparer et/ou regroupper les opérations d’une manière ou d’une autre. Ceci a d’ailleurs évolué au cours du temps et en fonction des capacités des machines. Par exemple les boîtiers ou cartes de synthèse vocale qui intégraient plusieurs fonctions aujourd’hui réparties entre d’autres couches ont disparu ou presque quand certaines des opérations qu’ils effectuaient ont pu être prises en charges par des processeurs de plus en plus puissants. À noter qu’il s’agit d’un point de vue grossier ou plutôt d’un point de vue purement utilitaire car sait-on bien comment étaient réparties les diverses tâches dans ces outils “hard” et surtout a-t-on vraiment envie de le savoir ...
Un ordre en valant bien un autre commençons la revue par la couche directement en contact avec l’utilisateur :
Désormais le le son final est produit par le système de la machine : carte son etc. Mais ces systèmes, n’intègrent pas, à ma connaissance du moins, la possibilité de convertir des informations codées, même sous forme de texte, en son intelligible. Il ne peuvent convertir que des informations dans des formats bien particuliers (wav, mp” etc) en son et même moyennant une couche logiciel. Ces informations accessibles à la carte son doivent donc être produites en amont à partir d’autres fournies par les couches supérieures. Cette dernière conversion est évidemment fortement dépendante de la langue toutes les langues n’utilisant pas les mêmes sons. Dans le système que je présente ici, elle est effectuée pour l’anglais par une partie de Festival 1.96-beta (voir I.5 ;) pour le français, l’allemand ou l’italien par Mbrola 3.01h (voir I.4.)
Les outils décrit ci-dessus, pour parler rapidement, n’acceptent en entrée que des phonèmes alors que le couches supérieures fournissent essentiellement du texte. La conversion est effectuée ici encore par Festival 1.96-beta (voir I.5,) pour l’anglais et son module Franfest 1.96-beta-rc01 (voir I.3.) On peut aussi utiliser un outil du type Cicero.
Le rôle de Speech Dispatcher 0.6.1 (voir I.8,) est comme son nom l’indique de répartir convenablement les flux sonores pour éviter les collisions de messages etc.
À ce point certains choisirons de travailler sous un environnement graphique intégré type Gnome ou kde sonorisé par un outil de type Orca qui sont des choses auxquelles je ne connais rigoureusement rien et à propos desquelles je n’ai rigoureusement rien envie d’apprendre puisque je les considère à peu près comme des contre sens et des anomalies qui n’ont d’autre que but que de rassurer les ex utilisateurs de Windows et de son célèbre Jaws auquel, Dieu m’en garde, je n’ai jamais touché et ne toucherai jamais ni de près ni de loin. “On ne dîne pas avec le Diable, même avec une longue cuillère !”
La solution qui a été retenue par la plupart de ceux qui se refusaient à la concession graphique, a été d’utiliser Emacs 21.4a (voir I.9) comme intégrateur de tâches. Il va sans dire que ce qui semblerait le plus naturel au premier abord, ce serait de rendre le shell (type bash ou autre) capable de transmettre ses informations aux couches décrites ci-avant. Je ne crois pas trop m’avancer en affirmant que cette idée a sans doute effleuré T.V.Raman le concepteur initial d’Emacspeak 24. Mais il me semble qu’il suffit de considérer l’aspect technique des choses, sur lequel je ne m’étendrai pas, pour réaliser que, la tâche à peu près irréalisable en shell devenait sinon aisée du moins praticable sous Emacs 21.4a eu égard à la nature de l’interpréteur de langage. Ceci ne devait occasionner aucune restriction pour l’utilisateur dans la mesure où Emacs est essentiellement tout aussi capable d’intégrer diverses tâches que le shell.
À Emacspeak qui fut le précurseur en la matière et reste un outil d’une grande puissance, on préfère Speechd-el 2.1 (voir I.10,) qui reprend la même philosophie mais dans une implémentation nettement plus moderne et permet surtout, ce qui n’est pas négligeable pour des francophones, une utilisation multilingue ce qui s’avère extrêmement compliqué avec Emacspeak qui n’est pas du tout conçu pour ça.
Speechd-el est une application écrite dans le langage interne d’Emacs (emacs-lisp) qui permet à Emacs de communiquer avec Speech Dispatcher (une application client/serveur quoi.)
J’ai regroupé le système vocal que je vous propose d’installer sous l’acronyme E.S.D.F.F.M. pour
Les instructions d’installation se trouvent donc en I.11. La procédure d’installation est essentiellement du type LFS Book et je serais ravi d’avoir des retour d’expérience relatifs à des installations sous les distributions usuelles dont je ne pratique aucune trouvant extrêmement déplaisante la manière dont les concepteurs desdites distributions se plaisent à réempaqueter les packages si bien que lorsqu’on connaît le contenu des packages d’origine on n’y retrouve jamais ses petits.