Gestionnaire temps réel de flux de données

Ce gestionnaire est destiné aux programmeurs. Sa tâche est de simplifier considérablement le travail de développement d'une application manipulant des flots de données de type temps réel ou non. Elle a pour but de faciliter la création d'applications "multimédia" temps réel càd manipulant des sons, des vidéos, etc.

I - Présentation du problème

Je vais essayer de vous faire sentir l'intérêt d'un tel gestionnaire à travers un exemple.

Imaginons que nous voulions réaliser un Amplificateur numérique pour guitare électrique. L'intérêt d'en réaliser une version logicielle est évidente: on limite les coûts en utilisant le matériel que l'on possède déjà chez soi, on peut effectuer des mises à jour logicielles pour obtenir par exemple de nouveaux effets, on peut enregistrer le résultat sur disque dur, etc.

Pour cet exemple, limitons nous aux réglages classiques disponibles sur un tel ampli. Ce sont le volume, le réglage des basses, médiums et aiguës, et enfin le taux de distortion.

Voici le schéma fonctionnel du système à réaliser, du moins tel que je le concoit.

Ce système comporte 7 blocs fonctionnels (unités). Il y a 1 entrée que nous appellerons "Producteur", 1 sortie ou "Consommateur" et 5 unités de transformation ou "Filtres" . Il est bien sûr possible d'imaginer des systèmes qui comportent plusieurs producteurs et/ou plusieurs consommateurs.

Le fonctionnement de l'ensemble semble à priori assez simple. La carte son envoie à intervalles réguliers des blocs de données. Ces blocs sont acheminés vers les 3 filtres. Une fois les 3 filtrages réalisés le mixeur peut additionner les échantillons reçus et envoyer le résultat à la distorsion qui elle même achemine sa sortie vers les haut parleurs.

Seulement, ce flux n' est pas si simple à gérer en pratique! Voici quelques uns des problèmes qui se posent:

• Indépendance et réutilisabilité des unités. Les unités (producteur, consommateur, filtre) doivent être indépendantes les unes des autres de manière à pouvoir être réutilisées dans d'autres programmes, avec d'autres connections et d'autres paramètres, et stockées dans des librairies. Notre gestionnaire de flux doit donc comporter une sorte de "médiateur" qui seul connaît les liaisons effectivement réalisées entre les différentes unités et qui se charge d'acheminer les données.

• Création des connections. Deux unités peuvent être interconnectées entre elles à partir du moment où elles sont capables de s'accorder sur le format des données qu'elles s'échangent. Un protocole de communication doit donc être établi.

• Gestion des timings. Celle-ci est particulièrement critique et est sans doute l'un des points les plus délicats. Je n'énumérerai qu'un seul des nombreux problèmes à traiter. Imaginons que notre système soit en fonctionnement, le bloc audio en cours de traitement est par exemple le numéro 100. Seulement, une personne utilise l'ordinateur et fait augmenter la charge CPU de telle sorte que le bloc 100 ne soit pas prêt à temps pour être joué. Il faut à ce moment là que le consommateur sache réagir (par exemple remplacer le bloc manquant par un blanc) et que le système abandonne le traitement de ce bloc, qui de toute façon ne sera jamais joué.

• Délai de propagation entre le producteur et le consommateur. Celui-ci doit être judicieusement choisit. Pour notre système, il ne doit pas être trop élevé car je doute qu' il soit particulièrement agréable pour le musicien qui vient de jouer une note d'attendre 1 demi seconde pour que le son apparaisse sur les haut parleurs. En revanche, plus ce temps de propagation sera long, moins le système sera perturbé par les variations de charge du CPU.

• Systèmes multi-processeurs. Chaque unité doit pouvoir fonctionner en multi-threading de manière à ce que par exemple les filtrages soient répartis sur tout les processeurs disponibles.

• Exportation de connections. Dans cet exemple, on peut vouloir exporter la sortie du système de manière à l'utiliser comme entrée dans d'autres programmes pour par exemple effectuer un enregistrement sur disque dur ou bien une quelconque visualisation...

En fait, on s'aperçoit assez vite que ces problèmes ne concernent pas uniquement notre application mais toute une catégorie de programmes. Et ceux-ci ne manipulent pas uniquement des données audio mais n'importe quel type de flux de données.

En voici un autre exemple pris au hasard:

Table pour DJs:

II - Utilité du gestionnaire

Le gestionnaire est un espèce de framework capable de gérer pour l'utilisateur (le programmeur) toutes les contraintes liées à la gestion des flux. L'utilisateur n' a plus qu'à créer les différentes unités selon un modèle bien définit et à les enregistrer auprès du gestionnaire. Il crée ensuite les liaisons et participe à la négociation du format des échanges. Il paramètre les unités ainsi que le gestionnaire afin d'obtenir le comportement désiré (ex temps réel dur ou souple). Et enfin, il n' a plus qu'à mettre le tout en marche.

III - Bibliothèques d' extension

Ensuite, bien sûr, il serait intéressant de réaliser des sur-couches ou plug-ins audio, vidéo et autres à ce système de manière à simplifier encore le processus de développement. Ces extensions pourraient entre autres définir différentes unités essentielles. En audio, nous aurions des choses classiques comme le mixage, divers types de filtrage, l'équalisation, l'écho, la réverbération, etc. On aurait aussi des unités comme l'acquisition sonore (le micro) ou encore un lecteur de fichiers mp3. Alors, pour réaliser l'ampli pour guitare, nous n'aurions plus à programmer que l'unité de distorsion! Toutes les autres unités seraient déjà disponible en librairies. Pour programmer un player de mp3, il n'y aurait plus qu'à cascader un lecteur de mp3, un équaliseur, un visualiseur de spectre, une sortie audio, et de contrôler le tout avec une petite interface graphique.

Idem pour la vidéo, on peut réaliser des filtres RGB, le réglage du contraste, des surimpressions, etc. Voyez The Gimp pour voir un peu l'étendue des possibilités!

IV - Quelques références

J' ai cherché à savoir si un gestionnaire de flux tel que je l'imaginait existait déjà. Et je n'ai à l' heure actuelle par trouvé grand chose dans le genre. Sauf une.

En parcourant le site web de Be, je me suis aperçu que le BeOS dispose déjà d'un tel système, extrêmement proche de ce que j' avais imaginé. Ce système s'appelle le Media Kit. Et c'est, d'après Be, l'une des innovations marquante de l'OS. Innovation dont nous ne saurions nous passer à l'avenir sur notre OS favori!

Voici donc une liste de liens sur divers articles traitant du Media Kit. Je ne peut pas dire qu' ils soient tous d' une clarté exemplaire, mais peut-être vous permettront ils de mieux comprendre l'importance d' un gestionnaire de flux.

Be - Developer Library: Media Kit: http://www.be.com/developers/developer_library/media_kit.html

Be - The Be Book for Release 4: http://www.be.com/documentation/be_book/index.html

Guillaume Badaut - 18/03/1999