Interactions audio sur le site web du LIA Projet 13 IUP Avignon Master 1 TAIM

2007 Interactions audio sur le site web du LIA Projet 13 IUP Avignon Master 1 TAIM A l'attention de monsieur Pascal NOCERA 28/05/2007

2 Projet 13 : Interactions audio sur le site web du LIA Sommaire Introduction... 3 Solutions... 3 Client... 3 Voie "Flash"... 3 Rappel du fonctionnement de la solution Flash... 3 Point bloquant... 5 Voie "Java Media Framework"... 6 Voie "Java et HTTP"... 6 Contenant... 7 Contenu... 7 Validation... 7 Fonctionnement... 7 Diagramme de classes synthétique... 8 Détection du silence... 8 Applet... 8 Interactions Applet HTML... 8 Interactions entre la page HTML et l'applet Java... 9 Interactions entre l'applet Java et la page HTML... 9 Interface... 10 Sécurité des applets... 12 Application Java Web Start... 14 Client et serveur... 15 Organisation... 15 Bilan... 17 Conclusions et perspectives... 18 Remerciements... 18

3 Projet 13 : Interactions audio sur le site web du LIA Introduction L'objectif du projet est de permettre de proposer un ou des démonstrateurs publics des avancées du Laboratoire d'informatique d'avignon dans le domaine du Traitement Automatique du Langage Naturel Oral. Il s'agirait d'une sorte de vitrine technologique. Le projet doit respecter le cahier des charges synthétique suivant : le démonstrateur doit être accessible à l'aide d'un navigateur internet sur le site web du LIA: c'est le client le module d'extension (plug-in) doit s'intégrer dans une page HTML la partie interface utilisateur est en HTML + Javascript et fait appel aux méthodes du module l'axe retenu pour le projet est un démonstrateur de reconnaissance de la parole qui se base sur SPEERAL : c'est le serveur Une attention particulière doit être faite pour séparer la logique métier du code de présentation. En outre, le paradigme MVC (modèle-vue-contrôleur) devra être respecté le projet doit être pérenne, c'est pourquoi les solutions retenues doivent être "rustiques" et qu'une documentation précise doit être réalisée Solutions Client Etant donné que le projet n'avait pas abouti les deux années précédentes, une nouvelle approche s'appuyant sur la technologie "Flash" nous a été proposée. Voie "Flash" Cette solution (proposée par notre tuteur) consiste à utiliser le plug-in flash du côté du navigateur (client) et un serveur flash communication en open source nommé RED5. Le premier semestre a été consacré à l'appropriation des techniques particulières à cet ensemble (ActionScript côté client et serveur RED5). Cela nous a permis de tester la validité des échanges audio entre les clients et le serveur. Nous étions en mesure d'enregistrer des fichiers vocaux sur le serveur puis de les relire à partir du client. Le deuxième semestre devait être lui consacré à l'exploitation de ces fichiers audio côté serveur pour permettre d'en renvoyer la transcription au client. Cette partie ne semblait pas présenter de difficultés majeures puisque l'on pouvait s'appuyer sur un existant à savoir speeral_iiop. Rappel du fonctionnement de la solution Flash Le fonctionnement est assez simple, la technologie Flash s'avérant particulièrement adaptée à ce genre de problématique.

4 Projet 13 : Interactions audio sur le site web du LIA Côté client : module en Flash permettant l'acquisition d'un flux audio via le microphone de l'utilisateur et son envoi de manière continue vers un serveur. L'interface est une simple page HTML avec du Javascript pour appeler les méthodes du module en Flash Côté serveur Serveur RED5 qui réceptionne le flux audio et le redirige vers un serveur SPEERAL grâce à la technologie CORBA Serveur SPEERAL qui transcrit le flux audio en texte qui est renvoyé par CORBA au serveur RED5 qui lui même le renvoie au client Figure 1 Diagramme général de la solution Flash Voici un extrait du code Action Script réalisé qui met en évidence la facilité de mise en place d'une solution Flash : var Connexion:NetConnection; // Connexion var ConnexionFlux:NetStream; // Flux var Micro:Microphone = Microphone.get(); // Micro ConnexionFlux = new NetStream(Connexion); function debut() { // Debut Enregistement ConnexionFlux.attachAudio(Micro); ConnexionFlux.publish("Test_FC", "record");} function fin() { // Fin Enregistement ConnexionFlux.publish(false);}

5 Projet 13 : Interactions audio sur le site web du LIA Point bloquant Hélas, lors d'une validation en mode manuel des différentes phases de traitement des fichiers vocaux au niveau serveur, une difficulté s'est présentée. En effet pour pouvoir être traité par SPEERAL le fichier doit être dans un format bien précis (PCM, 16 bits signés, bigendian) tandis que les fichiers générés par RED5 sont des fichiers FLV. Le format FLV (pour FLash Video) est un format conteneur composé d'une partie audio et d'une partie video. Il existe des convertisseurs (mplayer) qui s'acquittent en principe sans difficultés de cette tâche mais : [flv @ 00A0F544]Unsupported audio codec (5) Input #0, flv, from 'Test_FC1.flv' Une première recherche sur le sujet ne présageait rien de bon : http://en.wikipedia.org/wiki/nellymoser However, FLV files recorded from the user's microphone use the proprietary Nellymoser codec. Nellymoser Asao codec is a closed format owned by a Nellymoser and until recently there was no way to convert recorded voice to other format without having a transcoding license. Autrement dit, les fichiers créés par l'intermédiaire d'un microphone sont encodés dans un format propriétaire. Après de multiples recherches sur Internet il s'est avéré : que d'autres avaient déjà rencontrés le même problème qu'il n'existait pas de solution open source que le prix de la licence se comptait en milliers de dollars La seule note d'espoir provenait d'une copie du courriel de Steve Wolkoff - chef de produit FMS2 chez Adobe (Adobe a racheté Macromedia) " We are putting some free FMS tools on Adobe Labs in the next few weeks. One of these tools is an FLV > MP3 converter." (fin mai ce FLV > MP3 était toujours introuvable sur http://labs.adobe.com) Ne pouvant appuyer le projet sur un convertisseur en version alpha non disponible, il fût décidé vers la fin février que la voie était sans issue.

6 Projet 13 : Interactions audio sur le site web du LIA Voie "Java Media Framework" Cet ensemble d'api semblait permettre de répondre à nos besoins : The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology. http://java.sun.com/products/javamedia/jmf/index.jsp et nous avons déjà effectué quelques tests positifs de captures vocales sur un réseau local. Cette solution fût donc proposée mais : c'est justement suite à des échecs avec les JMF qu'on avait décidé de tenter autre chose :( mais ne perdez pas espoir. trop compliqué / instable, nécessite des installations supplémentaires pour l'utilisateur... Nous venions de travailler sur une solution abandonnée les années précédentes et étions revenus au point de départ. Voie "Java et HTTP" A la fin-février le projet était donc au point zéro, une phase de réflexion était donc nécessaire pour tenter de trouver une nouvelle approche. Cette réflexion s'est basée sur les éléments suivants : l'environnement standard d'exécution java inclut en standard des API pour le traitement du son : The Java Sound API specification provides low-level support for audio operations such as audio playback and capture (recording), mixing, MIDI sequencing, and MIDI synthesis in an extensible, flexible framework. Included in Java 2 Platform, Standard Edition (J2SE) The Java Sound API is part of J2SE version 1.3.x and higher. http://java.sun.com/products/javamedia/sound/ des "modules Java" peuvent s'intégrer dans des pages HTML : ce sont des applets les communications client-serveur à base de requêtes HTTP sont fiables et ne nécessitent pas de configuration particulière au niveau réseau (pare-feu) l'environnement standard d'exécution java inclut en standard des API pour gérer les requêtes HTTP Les éléments du puzzle était là, la difficulté était donc de construire une solution cliente en assemblant sons et HTTP sans pouvoir s'appuyer sur un framework préexistant dans un temps maintenant considérablement réduit.

7 Projet 13 : Interactions audio sur le site web du LIA Les éléments du puzzle était là, la difficulté était donc de construire une solution cliente en assemblant sons et HTTP sans pouvoir s'appuyer sur un framework préexistant dans un temps maintenant considérablement réduit. Contenant L'idée de base consistait à enregistrer la séquence audio en local puis à l'envoyer par une requête POST. Après une phase de vérification il s'est avéré qu'il était possible : Contenu d'injecter la séquence en temps réel dans une méthode POST Multipart préalablement ouverte de récupérer cette séquence dans un fichier côté serveur à la fermeture de cette méthode Suite au blocage de la solution Flash sur un problème de codec audio, nous avons porté une extrême attention à cet élément avant de poursuivre. Le choix du codec a un impact direct sur la bande passante utilisée et la taille des fichiers finaux obtenus. Dans le cas de connexion ADSL cette bande passante remontante est limitée c'est pourquoi un codec GSM fut envisagé. Un article (Amélioration de la reconnaissance de la parole issue de téléphones GSM sans données réelles Jérôme Baude, Nancy Bertin, Claire Waast-Richard) attira notre attention sur l'impact négatif du codec GSM en terme de reconnaissance sur des données d'apprentissage classique. La solution la plus performante en terme de reconnaissance de la parole consistait donc à utilisé le même format son que celui attendu nativement par SPEERAL (PCM 16 bits signés bigendian 16Khz) sous réserve qu'une bande passante grand public soit compatible. Des tests en situation à l'aide d'un prototype en mode ligne de commande et d'une connexion remontante à 256Kb/s (débit limite d'après nos calculs) vers un serveur web mutualisé d'un hébergeur donnèrent des résultats probants. Validation Nous avions enfin une solution permettant de transmettre du flux audio vers un serveur depuis un client et ce de manière exploitable par SPEERAL. Fonctionnement Le principe est de permettre une session de transcription à un utilisateur. Le système découpe le flux audio en séquence à l'aide d'une reconnaissance statique du silence ce qui demande une première phase de calibration. Puis termine la session sur détection d'un silence d'une durée plus importante. Les transcriptions disponibles sont récupérées sur le serveur par une méthode GET envoyée régulièrement.

8 Projet 13 : Interactions audio sur le site web du LIA Diagramme de classes synthétique Détection du silence Figure 2 Diagramme de classes C'est une détection statique basée sur l'énergie des blocs audio. Un seuil fixe est déterminé à la fin de la phase de calibration : seuil = moyenne + (1.2 * écart type). La méthode et le code nous ont été fournis par Benoît Favre. Nous avons légèrement amélioré le calcul de l'énergie en convertissant le niveau des échantillons et calculant l'énergie en une seule opération. Cette phase de calibration est extrêmement importante, nous avons obtenu les meilleurs résultats en soufflant légèrement et de manière continue dans le microphone (on peut moduler la force du souffle en fonction du bruit ambiant). Applet Interactions Applet HTML Lorsque la solution en Flash nous a été proposée, il était convenu que l'interface graphique utilisateur ne serait pas en Flash pour deux raisons : le module d'acquisition du son via le microphone doit être totalement indépendant de l'interface graphique pour permettre une réutilisabilité aisée il n'existait aucune solution gratuite permettant de créer des interfaces graphiques en Flash Dans un souci de séparation de la logique métier et du code de présentation, nous avons décidé de continuer sur cette voie : l'applet Java ne contiendrait aucune information graphique et aurait donc une taille de 0x0 (donc invisible pour l'utilisateur). Pour que ce projet soit le plus accessible possible au grand public, il nous a paru judicieux de créer une interface graphique en HTML, pour ne pas dérouter l'utilisateur novice qui est habitué aux éléments de formulaire HTML. Une question a donc été soulevée : comment interagir entre des composants HTML et l'applet Java?

9 Projet 13 : Interactions audio sur le site web du LIA Interactions entre la page HTML et l'applet Java Il est possible qu'un évènement sur la page HTML (clic sur un bouton par exemple) déclenche une méthode d'une classe de l'applet Java grâce au langage Javascript. Ceci est même assez simple : 1. on indique que l'on veut capturer un évènement pour un composant HTML donné 2. on capture cet évènement lorsqu'il est déclenché 3. on appelle la méthode désirée d'une classe de l'applet Prenons un exemple simple : On veut qu'un clic sur un bouton déclenche la méthode demarre() d'une classe d'une applet nommée exemple. <html>... <applet code="classecontenantlemain.class" name="exemple"></applet>... <input type="button" onclick="exemple.demarre();" />... </html> Interactions entre l'applet Java et la page HTML La communication entre l'applet Java et la page HTML est également possible mais nécessite la présence d'un package créé par Netscape : netscape.javascript. Ce package nous donne accès à la classe JSObject nous permettant de manipuler des objets Javascript : 1. appel d'une méthode statique getwindow() de la classe JSObject au chargement de l'applet nous permettant d'obtenir une référence sur l'objet Javascript window qui contient l'applet 2. applet d'une méthode eval(string js) permettant d'exécuter le code Javascript contenu dans la variable js import netscape.javascript.jsobject;... public class JversJS extends Applet {... public void start() {... JSObject jso = JSObject.getWindow(this);... jso.eval("alert('bonjour!');");... } }

10 Projet 13 : Interactions audio sur le site web du LIA Figure 3 - Interactions entre la page HTML et l'applet Java Interface L'interface utilisateur est très simple : il s'agit d'une simple page HTML contenant un bouton sous forme de lien hypertexte qui permet de démarrer la transcription. La transcription s'affiche dans une div prévue à cet effet. Des informations de debugage s'affichent dans une autre div et une dernière div nous permet de contrôler l'activité du microphone. La page est entièrement gérée par Javascript (Dynamic HTML), ce qui signifie qu'une fois chargée, elle n'est plus rafraichie.

11 Projet 13 : Interactions audio sur le site web du LIA Figure 4 - Interface graphique en HTML : affichage du résultat de la transcription Figure 5 - Interface graphique en HTML : affichage des informations de debugage

12 Projet 13 : Interactions audio sur le site web du LIA Sécurité des applets Dans le but d'éviter les abus et le piratage, les applets Java doivent être signées. Ainsi, le navigateur client s'assure que celles-ci proviennent bien de leur auteur et qu'elles n'ont pas été modifiées. Le mécanisme de la signature numérique permet d'authentifier et de garantir l'intégrité de l'auteur de l'applet. Pour signer une applet, il faut en premier lieu générer une clé publique. Toutes les clés sont stockées dans la keystore. La keystore est une base de clés. Elle est automatiquement créée si elle n existe pas déjà. La commande pour générer une clé est la suivante : keytool -genkey -alias cle_imyapp Lexique: -genkey: active la génération des clés publique et privée. -alias: permet de donner un nom à la clé. Signer le fichier archive : Cette commande permet de signer l archive : jarsigner -verbose i_myapp_admin.jar myapp Pour vérifier que la signature a bien été mise sur le fichier, il existe la commande suivante : jarsigner -verify -verbose -certs i_myapp_admin.jar Certificat Nous avons également besoin d'un certificat d'authentification. Un certificat permet de vérifier l'identité d'ordinateurs sur Internet, de façon à permettre des échanges sécurisés. Sans certificat, on ne peut s'assurer que l'ordinateur avec lequel on dialogue est celui désiré, et on court le risque de s'adresser à une autre machine, sans le savoir. les échanges numériques peuvent ainsi être interceptés, et leurs contenus espionnés. La commande suivante permet de générer le certificat :

13 Projet 13 : Interactions audio sur le site web du LIA keytool -export -alias cle_imyapp -file ImyApp.cer Options: -export: permet de lire le clé associée à cle_imyapp. -file: nom du fichier de sortie contenant le certificat (extension.cer). Depuis Java 2, une applet signée ne permet plus de tout faire. La configuration se fait dans le fichier $Java_home/jre/lib/security/.java.policy. Notre application utilisant le microphone du client, il faut accroitre la sécurisation de l'applet. Un accès permissif est défini avec une gestion du niveau de sécurité. grant codebase "file:${java.home}/lib/ext/*" { permission java.security.allpermission; }; Figure 6 Alerte sécurité Un certificat est l'équivalent d'une carte d'identité. Contrairement à cette dernière, un certificat est normalement délivré par une entreprise privée, qu'on appelle autorité de certification (CA, pour Certification Authority). Nous avons rencontré cependant un problème. Pour être officiels, les certificats d'authentification font l'objet d'une règlementation, et pour en obtenir un, il faut débourser une somme d'environ 300 auprès d'un organisme privé. L'IUP n'en possède pas et

14 Projet 13 : Interactions audio sur le site web du LIA ne compte pas en acquérir un, ce qui nous a contraints à nous tourner vers une solution Java Web Start. Application Java Web Start Nous trouvant dans l'impossibilité de faire certifier notre certificat par un organisme reconnu, nous avons dû trouver une alternative. La technologie Java Web Start nous a paru comme étant une évidence : cette technologie basée sur Java permet d'exécuter des applications à partir du Web la sécurité n'est plus un problème, puisque nous avons affaire ici à une véritable application (les manipulations potentiellement dangereuses (écriture dans un fichier, utilisation du micro, envoi de données vers un serveur...) sont toutefois signalées à l'utilisateur qui peut décider de les accepter ou de les refuser) étant basée sur Java, aucune réécriture de code n'est nécessaire Nous avons pu nous rendre compte une fois de plus de l'importance de l'architecture MVC : en effet, nous trouvant dans l'obligation de développer une application entièrement en Java, une interface graphique en HTML n'est plus possible. Nous avons donc développé une interface graphique en Java qui a pu être intégrée directement à notre projet. Nous avons simplement dû redéfinir les fonctions du contrôleur permettant l'affichage des données (communication interface graphique Java vers modèle en Java au lieu de communication HTML vers Java et inversement). Figure 7 - Interface graphique en Java pour la version Java Web Start

15 Projet 13 : Interactions audio sur le site web du LIA Client et serveur Devant s'appuyer sur des éléments standards et pérennes nous n'avons pas envisagé la possibilité d'une interaction directe entre le serveur web et le serveur CORBA de speeral_iiop. La solution retenue est un dispatcher en Java qui scrute le dossier des fichiers audio et demande leur transcription de manière séquentielle et synchrone à SPEERAL. Cette transcription est ensuite mise à disposition du client dans un dossier spécifique accessible à travers le serveur web. Le client scrute régulièrement ce dossier en attente des transcriptions. Figure 8 - Diagramme de séquence Actuellement le serveur est mono-client car le système actuel est mono-transcripteur. Organisation Etant donné que nous avons été contraints de recommencer notre projet du début à deux reprises, l'organisation au sein du groupe n'a pas toujours été évidente et le suivi d'un planning prévisionnel a été chose ardue. Nous avons chacun recherché séparément des solutions alternatives. Le fait que nous soyons dans des groupes de TP différents a également posé quelques problèmes, nos horaires ne correspondant pas toujours. Malgré tout, nous nous sommes toujours réparti le travail de façon plus ou moins équitable tout au long de ce semestre grâce à une bonne analyse des différentes composantes de la solution envisagée. La mise en place d'un wiki nous a permis de travailler de manière collaborative et d'appliquer nos connaissances acquises au premier semestre en ingénierie documentaire. Voici la répartition du travail entre les différents membres du groupe tout au long du second semestre :

16 Projet 13 : Interactions audio sur le site web du LIA

17 Projet 13 : Interactions audio sur le site web du LIA Bilan Notre travail durant cette année sur ce projet a débouché sur la création d'un prototype uniquement, suite au retard pris à cause d'une mauvaise orientation. Néanmoins, et ce malgré le retard pris en début de semestre, nous avons été capable de fournir trois déclinaisons du prototype applet Java de transcription de la parole application Java Web Start de transcription de la parole applet Java : commande vocale sur un objet de la page HTML (direction, changement de couleur, de taille... par la voix) Ce prototype fonctionne mais il ne s'agit pas d'une solution finalisée. Nous sommes capables : d'acquérir du son d'envoyer un flux audio vers un serveur HTTP d'envoyer un fichier audio présent sur un serveur HTTP vers un serveur SPEERAL de récupérer la transcription et de la traiter (affichage ou autre) Quelques pistes pour finaliser le projet : implémenter l'envoi de données audio compressées avec le codec Speex, spécialisé et optimisé pour la voix humaine pour obtenir des rapports de qualité et de taille supérieurs. Une implémentation de Speex pour Java est accessible par la librairie JSpeex créer un thread chargé de lire les transcriptions pour simplifier le code gérer une file d'attente pour le transcripteur pour éviter d'engorger le serveur pour l'applet : obtenir un certificat reconnu. La solution par applet nous parait la mieux adaptée, à savoir une interface web ne nécessitant aucun téléchargement pour le client (en considérant que Java est installé) et simple d'utilisation pour le Web Start : étoffer l'interface graphique réaliser une dépendance moins forte entre HTML et applet en utilisant une méthode unique pour chaque sens de dialogue améliorer la vitesse de reconnaissance temps réel en développant un serveur HTTP spécifique en Java à base de thread gérant chacun une séquence audio : inutile d'attendre la fin de la méthode POST pour commencer d'envoyer le flux audio au serveur CORBA plus besoin de dispatcher mesurer l'impact d'une compression de la voix (ex GSM) pour réduire la bande passante descendante nécessaire au serveur améliorer la reconnaissance du silence (version dynamique) explorer la voie "softphone"... L'utilisation de l'applet de commande vocale étant interactive, nous avons pu constater que les capacités d'apprentissage humaines sont bien supérieures à celles de la machine puisque en fait nous avons rapidement appris à "parler" de manière à avoir un taux de reconnaissance de 100%.

18 Projet 13 : Interactions audio sur le site web du LIA Pour l'anecdote une prononciation germanique donne d'excellent résultat et nous comprenons pourquoi l'allemand est la langue de prédilection des dresseurs de fauves et de chiens. De manière plus générale ce projet nous a permis : d'aborder des problématiques liées à la reconnaissance de la parole de prendre conscience de la difficulté de la tâche Conclusions et perspectives Bien que nous ayons été confrontés à une impasse au début du deuxième semestre nous sommes en mesure de proposer une solution opérationnelle. La forme est certes améliorable mais la voie trouvée (Java et HTTP) est solide et simple, elle répond parfaitement au critère de rusticité demandé par le cahier des charges. Cette solution peut donc être facilement mise en œuvre et il serait judicieux de l'intégrer à d'autres projets (jeu du voyageur de commerce avec choix vocal des villes,...) ou de l'utiliser pour de nouvelles applications (reconnaissance distante du locuteur,...). De manière plus générale nous pensons que ce vecteur devrait permettre au LIA de pouvoir présenter ses avancées au niveau de la thématique TALNO en s'affranchissant de contrainte de proximité. Remerciements Nous tenons à remercier : Georges Linares pour son aide dans la mise en œuvre de SPEERAL et iwsrv Benoît Favre pour son rôle de tuteur et son apport au projet (calibration du silence) Pascal Nocéra et Anthony Larcher pour leur rôle de tuteur