2.6
Conclusions
Dans ce chapitre nous avons détaillé les différents éléments de l’architecture globale d’un système de classification audio. Bien que l’on parle “d’apprentissage automatique”, nous avons pu voir que l’élabora- tion d’un système d’apprentissage n’est elle, pas automatisée puisqu’il faut à chaque étape faire un choix sur chacune des techniques utilisées.
La phase de caractérisation du signal, qui constitue le fondement du système de classification audio, nécessite soit de construire les descripteurs ad hoc en fonction du problème donné, soit de ne retenir qu’un ensemble de descripteurs pertinents, parmi des descripteurs existants. Cette étape conditionne généralement le système de classification tout entier puisqu’un jeu de descripteurs adapté permet dans certains cas d’obtenir de bonnes performances alors même que le classifieur utilisé par la suite est très simple. L’utilisation de bons descripteurs permettra de simplifier le problème de classification. L’étape de sélection peut se faire selon des modalités multiples et il faut alors déterminer le critère de sélection et la procédure de recherche.
Ensuite, le choix du classifieur reste également à la charge de l’expérimentateur. Là encore, il n’existe pas de consensus absolu et le choix se fera généralement de manière empirique, selon les performances souhaitées et la complexité autorisée par le système final, bien que, comme nous l’avons vu, d’un point de vue théorique certaines techniques peuvent sembler plus séduisantes que d’autres (SVM par exemple). Toutefois, même avec ces garanties, les bonnes performances d’un modèle dépendent principalement de l’ajustement de ses paramètres afin d’éviter le phénomène de sur-apprentissage. Pour cela, en suivant un protocole de validation approprié, permettant d’estimer les paramètres du classifieur et de valider le modèle, il est possible d’éviter ce problème.
Enfin, bien que la caractérisation du signal et la modélisation par le classifieur soient les étapes les plus importantes, on retrouve également d’autres aspects pouvant influer sur les performances de classifi- cation. On notera par exemple le choix de la topologie du problème (hiérarchie des classes audio ou non) ou encore le recours à des combinaisons de classifieurs pouvant aboutir à de meilleures performances de prédictions (ensemble methods).
Chapitre 3
Classification audio temps réel
Sommaire
3.1 Propriétés d’un système temps réel . . . . 27 3.1.1 Un prise de décision rapide . . . 27 3.1.2 Un système à faible latence . . . 28 3.1.3 Sévérité et criticité des systèmes temps réel . . . 28 3.2 État de l’art de la classification audio temps réel . . . . 29 3.2.1 Approches pour une classification faible latence . . . 30 3.2.2 Faible complexité . . . 33 3.3 Discussion . . . . 34 3.3.1 Bilan des systèmes temps réel . . . 34 3.3.2 Perspectives . . . 34
Le chapitre précédent nous donne tous les éléments pour aborder la classification audio de manière générale. Dans ce chapitre nous allons nous focaliser davantage sur les problématiques qui nous importent, à savoir mettre en place un système de classification audio fonctionnant sous contrainte de faible latence. On présente tout d’abord les caractéristiques d’un système dit temps réel. Cette présentation nous per- mettra de faire le point sur les différentes notions qui sous-tendent un fonctionnement à faible latence. Puis par la suite nous passerons en revue les approches employées pour les systèmes de classification audio présentant des contraintes temporelles.
3.1
Propriétés d’un système temps réel
Dans les disciplines de l’informatique et de l’ingénierie, un système est dit temps réel s’il est capable de contrôler un phénomène physique à une vitesse adaptée à l’évolution de celui-ci. Le système doit répondre à des stimulis externes en un temps fini et spécifié, et l’exactitude des résultats est aussi important que le respect des contraintes temporelles (Stankovicet al. 1992), (Stankovic et al. 1998). Cette définition
fait appel à plusieurs notions que sont :
• la performance : les résultats obtenus par le système doivent bien évidemment être exacts/suf- fisants,
• la rapidité : le temps nécessaire pour prendre une décision doit être fini et spécifié,
• la latence : le système doit répondre à une vitesse adaptée au phénomène physique observé ainsi qu’aux objectifs visés par l’application finale.
3.1.1
Un prise de décision rapide
Pour qu’un système soit temps réel, il faut que celui-ci réponde à certaines contraintes d’un point de vue du temps de calcul. Pour une tâche donnée, le temps d’exécution doit être borné même si le traitement doit s’opérer pour une durée illimitée. Idéalement, le programme doit s’exécuter à temps constant, c’est-à- dire qu’il existe une valeur k telle que le temps d’exécution de l’opération soit au plus k, indépendamment de la taille du problème.
Par exemple, en traitement numérique du signal, si un traitement nécessite 2.01 secondes pour analyser et synthétiser un son d’une durée de 2.00 secondes, ce traitement n’est pas temps réel. S’il nécessite 1.99 secondes, dans ce cas il devient temps réel. Si ce traitement devait s’opérer sur un signal d’une durée infinie, son temps d’exécution serait tout de même borné.
Pour satisfaire de telles contraintes, il est nécessaire de contrôler le temps d’exécution de chaque processus et s’assurer que celle-ci n’excède pas une certaine durée. Cela fait appel à la connaissance de nombreux paramètres techniques (fréquence du processeur, temps d’accès mémoire, etc.) mais aussi à plusieurs théories informatiques telle que la théorie de l’ordonnancement pour gérer la planification des tâches, la priorisation des processus (Shin & Ramanathan 1994). Un autre défi lors de l’élaboration
d’un système temps réel est d’estimer sa prédictibilité, c’est-à-dire prouver que toutes les contraintes temporelles seront respectées pour avoir les garanties nécessaires du bon fonctionnement d’une opération (dépend des hypothèses de charge, de la fréquence d’entrée des données, des erreurs non contrôlables etc.).
3.1.2
Un système à faible latence
Un temps d’exécution borné et spécifié est une condition nécessaire mais non suffisante pour qu’un système soit considéré comme temps réel. Afin de pouvoir contrôler un phénomène, il faut que le système traite les données à une vitesse en accord avec la vitesse d’évolution du phénomène observé, ainsi qu’avec les conditions d’utilisation du système. En d’autres termes, un système temps réel ne doit pas seulement être “rapide” mais avoir un fonctionnement adapté aux données observées et aux conditions d’utilisation de l’application.
On peut alors parler de la latence d’un système qui serait le délai maximal autorisé entre le déclen- chement d’un événement et la prise de décision attendue (échéance). La latence est régit par la nature des données observées ainsi que les objectifs d’utilisation du système final. Pour être temps réel, il faut que la latence soit contrôlée et rentre dans les spécifications de l’application et des données utilisées.
En effet, on ne peut pas attendre la même réactivité pour un système de contrôle d’assistance au freinage d’une voiture et un système de prévision météo, du fait du caractère très différent pour ces deux applications. Dans ces deux cas de figure, les données ne vont pas arriver à la même vitesse et ne nécessitent pas une prise de décision selon les mêmes modalités temporelles.
À cela s’ajoute les contraintes fixées par les concepteurs d’un système : en fonction de la nature du problème, sous quel délai le système doit-il répondre ? Ces limites varient grandement selon le but de l’ap- plication finale et à titre d’exemple, on peut retrouver différents ordres de grandeur pour les échéances selon les besoins :
• milliseconde pour des radars,
• seconde pour les systèmes de visualisation humaine,
• quelques heures pour le contrôle de production impliquant des réactions chimiques, • une journée pour des prévisions météo,
• plusieurs mois ou années pour les systèmes de navigation de sonde spatiales.
Toute la nuance entre les systèmes temps réel réside dans la définition de cette latence. En audio, les contraintes temporelles sont généralement dictées par le confort d’utilisation : un traitement qui engendre un délai perceptible pour l’auditeur, dû à une latence trop élevée, ne rentrera pas dans le cadre d’une utilisation temps réel.
3.1.3
Sévérité et criticité des systèmes temps réel
Parmi les critères qui peuvent définir les limites de la latence, on trouve la notion de sévérité des systèmes temps réel. Cette notion fait appel à la tolérance à la réactivité du système et aux conséquences engendrées. On distingue pour cela trois catégories de temps réel :
• le temps réel strict (hard real time) impose un respect rigoureux des contraintes temporelles. En cas de dépassement de l’échéance imposée, le résultat n’a plus de valeur et cette absence de résultat peut conduire à des situations critiques, voire catastrophiques. Ce type de système est présent sur des applications sensibles comme le pilotage automatique d’un avion, le système de contôle de site sensible , etc.
• le temps réel ferme (firm real time) requiert d’avoir une réponse avant l’échéance sans quoi le résultat ne sera plus exploitable. Les conséquences d’un manquement de l’échéance ne sont pas
3.2 État de l’art de la classification audio temps réel