Mesure in situ de l`absorption acoustique des matériaux dans le

281
A Système de mesure et informatique
L’annexe qui suit doit être vue comme un complément au chapitre sur le
système de mesure. Elle traite dans un premier temps du rassemblement des
éléments constituant un système informatique qui respecte les exigences de la
mesure in situ, en conformité avec la double logique, technique et économique,
formulée lors de l’analyse du problème. La concrétisation de ce système idéal est
abordée ensuite. Le système restant à ce jour inachevé, la dernière partie
s’intéresse aux perspectives.
A.1 Métrologie informatique - choix d’une base de travail
Ici, l’objectif n’est pas de réinventer la roue, mais, pour filer la métaphore,
de faire en sorte que sa rotation connaisse le moins possible d’accidents de
parcours, et ne soit pas réservée aux privilégiés. On procède ici par couches, en
allant du plus concret et matériel vers le plus abstrait et immatériel.
A.1.1 Hardware : PC portable et périphériques génériques
Les tâches à réaliser étant complexes, il est certainement beaucoup moins
onéreux de recourir à l’appareil virtuel et adaptable par excellence qu’est
l’ordinateur pour contrôler la mesure, engendrer et acquérir les signaux plutot
que de développer une électronique spécifique. L’équipement de mesure complet
devant être facilement transportable, notre choix se restreint aux portables de
type compatible PC ou de marque Apple. Sur le plan des périphériques, la
première catégorie l’emporte largement sur la seconde. Nous optons donc pour
un compatible PC.
Une interface audio est nécessaire pour permettre au PC d’engendrer et
d’enregistrer des signaux. Toujours dans une optique de réduction des coûts, il
serait souhaitable de choisir dans la gamme des cartes existantes. La
démocratisation du multimédia aidant, des cartes de très bonne facture en termes
de résolution, distorsion et de rapport signal sur bruit sont disponibles à des prix
raisonnables. De ce fait notre souhait n’est plus du tout irréaliste. Un étudiant de
282 Annexe Mesure et informatique
l’université de Trondheim a d’ailleurs bénéficié de la bibliographie constituée
durant ce mémoire pour réaliser un système MLS, aujourd’hui commercialisé, qui
repose sur le périphérique audio standard d’un ordinateur portable fonctionnant
sous Windows 95.
A.1.2 Le système d’exploitation : priorités fixes à défaut de temps
réel
A.1.2.1 L’incompétence des systèmes courants
Elément semble-t-il mal connu de bon nombre d’utilisateurs d’ordinateurs
en métrologie, les systèmes d’exploitations courants ne sont pas "temps-réel".
Cela signifie que le temps d’éxécution d’une tâche n’est pas critique pour eux.
Pour plus de détails sur la notion de temps-réel en informatique, le lecteur pourra
se reporter à [Comp.realtime-1998]. Il semble sur ce point que le monde de la
mesure acoustique ait beaucoup à apprendre de celui de la performance musicale
par ordinateur. Sa littérature propose quelques références sur le sujet [Fichera1991] [Viara-1991], la nôtre aucune, sauf erreur. Or, dans le cas de l’utilisation
d’un ordinateur pour la génération et l’acquistion simultanée de signaux, la
question du caractère temps-réel est d’une importance primordiale. En effet, en
théorie, rien ne garantit que le transfert des signaux se fera de manière
suffisamment rapide ou régulière. D’autres tâches sont actives au moment où la
mesure s’effectue et le système d’exploitation distribue le temps CPU à chacune
suivant leurs priorités.
Sous Windows 95 (aujourd’hui 98), système d’exploitation multitâches
destiné à la bureautique, ces priorités ne sont pas contrôlables par l’utilisateur.
Par ailleurs il semble que le programmeur ne soit pas mieux loti, car les notions
de processus, de multitâche et de priorité n’apparaissent nulle part dans la
documentation pourtant pléthorique sur le système phare d’aujourd’hui commercialement parlant. En fait, ce système prévoit tout de même une classe de
processus dits "temps réel", mais les spécialistes jugent pour nous qu’elle ne
mérite pas ce qualificatif [Timmerman_Monfret-1997]. Dans ces conditions, il se
peut que des erreurs se produisent, comme dans le cas d’un transfert de données.
Prenons un exemple presque quotidien, la gravure de CD-Rom. Cette opération
nécessite un débit de données sensiblement constant entre la mémoire de
l’ordinateur et le graveur, au risque de devoir recommencer la gravure sur un
283
disque neuf. La constance du débit n’est atteinte que si l’on empêche tout autre
tâche, telle qu’un économiseur d’écran, de s’exécuter. Les débits en question sont
pourtant peu élevés, lorsqu’on les compare aux capacités d’un microprocesseur
actuel ou d’un bus d’échange. Par définition, la gravure dite "double vitesse",
courante à l’heure de la présente rédaction, correspond en effet au débit engendré
par le duplex - lecture et enregistrement simultanés - sur 2x2 canaux, à 44.1 kHz
et 16 bits de résolution par échantillon, soit environ 350 kilo-octets/s. Le cas
échéant, les erreurs ne seront pas nécessairement signalées par le système
d’exploitation. Cette conclusion est valable également pour MacOS, le système
d’exploitation d’Apple, du moins avant que sa version X ne soit disponible.
Ceci n’empêche pas les spécialistes des logiciels de métrologie de
développer pour Windows ou MacOS. Si les performances d’environnements de
développement tels que LabView se sont très nettement améliorées au fil des
années, la même faiblesse subsiste sur ces systèmes d’exploitation. Dans l’absolu,
rien ne garantit que la mesure s’effectuera correctement à chaque fois. Nous ne
savons pas si des mécanismes de vérification du bon déroulement des mesures
ont été intégrés auxdits logiciels. En tout cas, en 1995, lors de l’essai d’un
générateur de signal sinusoïdal fourni comme démonstration des fonctionnalités
de LabView et d’une carte d’acquisition propriétaire, il fut possible d’entendre
pendant quelques instants dans le haut-parleur relié à la sortie de la carte via un
amplificateur de puissance, des grésillements correspondant aux déplacements
de la souris, signes d’un changement inopiné d’activité pour le processeur.
Inopiné et mal venu, mais ne donnant pas lieu au moindre message d’erreur de la
part du programme de contrôle. Expérience suffisante pour nous pousser à
rechercher un système d’exploitation mieux adapté.
A.1.2.2 Des systèmes plus adaptés : OS/2 et les UNIX pour PC
OS/2, développé conjointement par IBM et Microsoft pour la plate-forme
PC, apportait la solution. Multiprocessus, ce système connaît quatre catégories de
priorités, dont la priorité "temps critique" [[Deitel_Kogan-1992], p 137].
Malheureusement, malgré une conception autrement plus solide et ouverte que
celle de Windows, ce système semblait condamné en 1995, du fait de l’abandon
de son développement par Microsoft.
Parmi les systèmes spécifiquement temps réel, QNX est certainement le
284 Annexe Mesure et informatique
plus connu. Il fonctionne sur plusieurs plates-formes matérielles dont les
compatibles PC. Ce choix peut sembler s’imposer. Mais la couche système
d’exploitation n’est pas la dernière à considérer dans notre sélection. On
remarquera par ailleurs que d’autres concurrents existent [Comp.realtime-1998].
Sans aller jusqu’au système temps-réel, nous avons fait allusion aux
priorités entre les différentes tâches processeur. Une solution consisterait à
déterminer par des essais le niveau de priorité suffisant pour que l’acquisition de
signaux se déroule bien, et à imposer cette valeur au système d’exploitation. Il
suffit donc de disposer d’un système d’exploitation multitâches un peu évolué,
comme UNIX. L’offre de versions d’UNIX, le standard des stations de travail, ou
de Mach [[Tanenbaum-1992], §15] dont plusieurs sont domaine public, est en fait
assez large. Au début de ce travail, Linux commençait par exemple à prendre
forme. NeXTSTEP était, quand à lui, à la fois tout à fait au point et seul à proposer
un environnement graphique convivial.
Il n’était pas encore question de penser à WindowsNT, très largement
inspiré d’UNIX, qui ne fonctionnait que pour des configurations de PC de haut de
gamme à processeurs multiples. Aujourd’hui, cette solution serait à envisager, du
point de vue système du moins, quoiqu’elle soit connue pour être d’une grande
voracité en ressources système.
A.1.3 La gestion du son sur ordinateur et les outils de
développement
En 1995, les outils fournis sous Windows pour contrôler le son sur un
ordinateur étaient très rudimentaires. Le compilateur Borland C++ 4.0,
contemporain de ce millésime, ne proposait rien d’autre que des fonctions de très
bas niveau, du point de vue de l’abstraction s’entend. Au programmeur de se
plonger dans les profondeurs de l’architecture du système et des drivers de carte.
La fonctionnalité son, non prioritaire, n’était vraisemblablement pas encore
implantée sous Linux.
NeXTSTEP, outre le fait qu’il proposait des outils de développement qui
ont fait de lui une référence pendant plusieurs années auprès des programmeurs
professionnels, était seul à fournir des bibliothèques d’objets, parmi lesquels une
véritable interface de développement d’application, l’App Kit, et des bibliothèques
285
audio, le Sound Kit et le Music Kit, qui permettaient, du fait de leur niveau
d’abstraction élevé, un développement très rapide d’applications dans le
domaine.
Le choix de NeXTSTEP 3.3 s’imposait donc sur tous les plans. Le langage
natif de NeXTSTEP est l’Objective-C, comme son nom l’indique un langage
orienté objets (davantage objets que le C++) dérivé du langage C. Son
apprentissage est assez facile. Pour plus de détails, le lecteur pourra se reporter à
l’introduction donnée en annexe. Une seule incertitude planait au sujet de
NeXTSTEP, celle de sa réussite commeciale…
A.2 Tentatives de réalisation
A.2.1 Le Sound Kit
L’essentiel pour nous était de disposer d’un programme permettant la
lecture et l’enregistrement simultanés de signaux. Pour commencer, nous avons
choisi de n’exploiter que le Sound Kit, qui répondait sur le papier à nos besoins, et
de développer avec une carte son grand public, de type Soundblaster 16. Celle-ci
permet l’enregistrement et la lecture sur deux canaux avec une résolution
maximale de 16 bits et une fréquence d’échantillonnage de 44.1 kHz, ce qui est
amplement suffisant pour nos mesures.
A.2.1.1 Fonctionnalités prometteuses du Sound Kit
Le Sound Kit est la partie objet du software spécifique son de NeXTSTEP. Il
contient 10 classes représentant les différents éléments et données impliquées
dans un système d’enregistrement / lecture / visualisation audio, autour de
Sound, la classe servant à représenter et manipuler les données audio. Trois lignes
de code sont suffisantes pour créer une instance de l’objet Sound, lui associer un
fichier de son, et lancer sa lecture :
…
id MLS;
…
MLS=[[Sound alloc] initFromSoundfile:"nom_de_fichier"];
[MLS play];
…
En guise de test des fonctionnalités, il nous a été dès lors très facile de
programmer un générateur MLS, avec interface graphique intégrée utilisant
l’App Kit. La partie audio du code est fournie en annexe (Cf C.1). Il est possible
286 Annexe Mesure et informatique
d’engendrer des séquences de très longue durée (ordre > 20 si nécessaire) avec ce
générateur. De même, un enregistreur bi-canaux a été programmé rapidement (Cf
C.2.2).
A.2.1.2 Le duplex impossible : bug dans le système
Les difficultés sont apparues au moment de combiner lecture et
enregistrement. Le fonctionnement du programme correspondant n’est pas du
tout satisfaisant. Enregistrement et lecture s’excluent mutuellement. Le recours
aux objets dédiés au contrôle de périphérique audio NXSoundIn et NXSoundOut
est sans effet. De même, toutes les tentatives sont restées vaines avec les fonctions
de plus bas niveau.
L’explication
de
ces
problèmes
est
venue
beaucoup
plus
tard.
Premièrement, la carte Soundblaster 16 ne permet pas lecture et enregistrement
en simultané, sauf en mode 8 bits, ce qui n’est pas acceptable pour les besoins de
nos mesures. Deuxièmement, le module drivers de NeXTSTEP souffre d’un bug
qui empêche cette opération, cela quel que soit le modèle de périphérique audio
utilisé. Les entrées / sorties audio étant un aspect non critique du fonctionnement
d’un ordinateur en général, ce problème n’a jamais été résolu, au profit de
questions plus prioritaires pour la compagnie.
Une solution aurait peut-être consisté à installer deux cartes audio sur la
même carte mère. NeXTSTEP permet l’installation de deux périphériques audio
identiques. Mais l’essai s’est avéré infructueux, les cartes n’étant pas reconnues
par le Sound Kit. En laboratoire, on aurait pu associer deux ordinateurs disposant
chacun d’une carte audio, du fait de la capacité du SoundKit à commander des
ressources audio distantes de façon aussi sibylline que les ressources locales.
A.2.1.3 A plus bas niveau, portage incomplet
La bibliothèque Sound de NeXTSTEP fournit aussi des fonctions de bas
niveau permettant le contrôle d’une carte à processeur de traitement de signal
(Digital Signal Processor, DSP), les Driver Functions. On touche ici aux limites du
portage de NeXTSTEP depuis le hardware spécifique sur lequel il a été développé
vers le hardware PC : les fonctions existent bien, mais très peu de cartes à DSP sont
supportées, et celles-ci n’étaient plus commercialisées au moment de l’achat de la
licence NeXTSTEP que nous avons utilisée.
287
A.2.2 Le MusicKit
A.2.2.1 Fonctionnalités
Généralités
Pour sortir de l’impasse, nous avons exploré les possibilités du MusicKit,
développé par le Center for Computer Research in Music and Acoustics (CCRMA) de
l’université de Stanford (E.U.). Le but de ce kit, qui est la synthèse et la
performance musicales, paraît bien éloigné de nos préoccupations. Mais musique
et mesures acoustiques ne sont pas aussi étrangères. Les synthétiseurs sont des
générateurs de signaux en général plus sophistiqués que ceux que nous utilisons
pour nos expériences. La musique par ordinateur procède souvent en modifiant
des signaux du monde extérieur dont il faut faire l’acquisition. Enfin le respect de
contraintes temporelles est un aspect critique de la qualité d’une performance
musicale, comme le rappellent les références évoquées ci-dessus. Nous pouvons
donc ici faire abstraction du champ d’application originel de ces classes d’objets.
Dans un langage plus "sérieux", elles modélisent la synthèse et l’acquistion de
signaux et fournissent des outils de contrôle temporel.
L’analogie a tout de même ses limites. La différence la plus importante se
trouve dans l’"orientation" du fonctionnement. En mesure, le but final, du point
de vue de l’ordinateur, est d’enregistrer quelque chose. En musique, le flux est
inverse : il s’agit surtout de produire un signal.
Détails : orchestre, chef, DSP
Le MusicKit est un édifice d’envergure, 20 Méga-octets de code. Il est facile
de s’y égarer, malgré un très net effort de documentation et d’illustration de ses
fonctionnalités. Résumons celles qui nous intéressent directement. Le MusicKit
s’appuie sur la combinaison ordinateur hôte et cartes audio à DSP - les DSP
doivent appartenir à la famille 56000 de Motorola. Leur nombre est, en l’absence
de réseau, limité par celui des slots disponibles pour des extensions sur la carte
mère de l’ordinateur hôte. Celui-ci sert de maître d’œuvre. Il se charge de la
mobilisation des ressources, de leur paramétrage, de leur activation à temps
contraint ou non. Le fonctionnement à temps contraint implique l’initialisation
d’une instance de la classe Conductor.
Chaque carte à DSP est représentée au niveau logiciel par une instance de
la
classe
Orchestra.
Chaque
orchestre
regroupe
un
certain
nombre
288 Annexe Mesure et informatique
d’"instruments", des fonctions de production ou de traitement de signal
élémentaires - générateurs, filtres, amplificateurs, retards…- chacune est
l’instance d’un Unit Generator particulier. Attention donc, un générateur unité
n’est pas nécessairement un générateur de signaux. Ces générateurs-unités sont
connectés les uns aux autres par des instances de patch points. La classe patch point
hérite de la classe SynthData, conçue pour représenter des zones de mémoire de
données DSP. Le MusicKit est livré avec un grand nombre de ces générateursunités, portions de code assembleur DSP56000 encapsulées dans une classe
Objective-C. Parmi ces modules, citons, outre un générateur de signal sinusoïdal
classique, une version modulable en fréquence grâce à un générateur de rampe et
un générateur pseudo-aléatoire de type congruence linéaire. Un certain nombre
d’éléments sont donc en place pour un système permettant la comparaison des
mérites des procédés d’acquisition proposés au chapitre précédent. Si nécessaire,
il est possible d’en programmer d’autres en assembleur 56000, mais la tâche
s’annonce ardue pour le néophyte, d’autant plus qu’aucun outil de débuggage
n’existe sur hardware Intel.
Elément important, l’activité du DSP se partage entre les différents
générateurs-unités chargés en mémoire dans une situation donnée, avec comme
règle d’avoir produit exactement 16 échantillons à la sortie d’un générateur avant
de passer à un autre, ceci pour des raisons d’efficacité de fonctionnement.
L’"orientation" de fonctionnement différente dont il a été question a pour
conséquence l’absence d’une fonctionnalité qui serait bien utile en mesure, à
savoir la possibilité de transférer en mémoire hôte les échantillons lus à la sortie
des convertisseurs analogique/numérique par un générateur-unité d’entrée
(InUG). On notera au passage que la lecture d’un fichier de son précalculé via le
DSP n’est pas prévue non plus.
En termes de chronologie, il est nécessaire de distinguer deux phases dans
le fonctionnement d’un orchestre. La première est celle de la configuration, qui
consiste en un transfert des générateurs-unités et des données en mémoire DSP.
La deuxième est celle du fonctionnement, pendant laquelle il n’est plus possible
de transférer des données entre hôte et DSP, mais simplement d’envoyer des
commandes via le port hôte du DSP.
289
A.2.2.2 Mise en pratique
Ces travaux s’étendent sur une assez longue période, de l’été 1996 à
l’automne 1998, car ils ont été menés avec un niveau de priorité assez bas. Ils
s’appuient sur la version 4.1.1 du MusicKit, puis sa version 4.2 à partir de l’été
1997, en combinaison avec une des deux cartes de marque Turtle Beach cidessous :
• Tahiti : DSP 56001 et convertisseurs 18 bits
• Fiji : DSP 56002 et convertisseurs 20 bits
L’impossibilité d’enregistrer à partir du MusicKit implique que ce Kit ne
peut être auto-suffisant par rapport à nos besoins. Combiner la génération par le
MusicKit et l’acquistion par le SoundKit est la seule voie possible.
Un premier système MLS limité
L’approche la plus simple, à savoir la lecture d’un fichier contenant une
séquence préalablement calculée, est à rejeter pour la raison précisée ci-dessus.
De même, on pourrait penser qu’il est possible de concevoir un générateur
MLS par construction d’un registre à décalage à l’aide d’une combinaison de
générateurs-unités existants, de type ligne à retard et sommateur, mais la
contrainte des 16 échantillons mentionnée ci-dessus empêche de procéder ainsi,
sauf à accepter une fréquence maximale de signal extrêmement basse égale à
44100/16=2750 Hz !
Trois possibilités restent, en l’absence d’un générateur unité produisant
une MLS. La première, utiliser un générateur-unité de type oscillateur générique
(OscgUG). Un oscillateur générique balaie en boucle une instance de SynthData
contenant une période de signal précalculée. Dans notre cas, il suffirait donc de
calculer les valeurs de la séquence à l’aide du processeur-hôte et de les ranger
dans une instance de SynthData connectée à un oscillateur générique (Cf Figure121).
290 Annexe Mesure et informatique
Table
Oscg
Out2Sum
Figure-121 : génération de signaux de forme d’onde quelconque
avec le Music Kit. Les patchpoints ne sont pas représentés ici.
Utiliser un oscillateur générique ne pose pas de difficulté. Mais le procédé
trouve très vite ses limites, du fait de la petite taille de la mémoire de données
externe de la carte à DSP. Numériquement, il n’est pas possible d’engendrer une
séquence d’ordre supérieur à 12, ce qui est trop faible pour nos besoins. La
compilation des deux courtes portions de code rappelées en annexe montre le bon
fonctionnement en duplex de la combinaison MusicKit / SoundKit utilisée (Cf
C.2). Il est possible de gagner un ordre en exploitant la séparation de la mémoire
de données en deux bancs X et Y. Le principe consiste alors à mettre en place un
oscillateur générique pour chaque banc de mémoire, et à stoquer la première
moité du signal dans un vecteur rangé dans le banc X et la seconde dans le banc
Y. Les sorties des oscillateurs génériques sont reliées aux deux entrées d’un
générateur-unité de commutation servant à sélectionner la sortie d’oscillateur à
connecter au générateur-unité de sortie, au terme d’une demie période (Cf Figure122). Cela nécessite l’emploi d’un conductor pour envoyer la commande de
basculement le moment venu.
Table
X
Oscg
DSwitch
Out2Sum
Oscg
Y
Table
Figure-122 : maximisation de la durée de synthèse par exploitation
des deux bancs de mémoire.
291
Une deuxième voie consisterait à utiliser l’interface procédurale fournie
par le Music Kit. Elle contient des fonctions qui permettent de communiquer avec
les drivers de cartes à DSP, de transférer des données avec contrôle temporel ou
non, et d’exécuter des instructions DSP, le tout à la demande du processeur-hôte.
Il suffirait en théorie de mettre en place un générateur-unité de sortie, et
d’envoyer périodiquement des échantillons vers le patchpoint auquel son entrée
est connectée. Le temps a manqué pour passer à la pratique.
Reste la solution radicale, l’écriture d’un générateur unité dédié.
Malheureusement, l’assembleur spécifique est plutôt ardu à apprendre pour
l’habitué des langages procéduraux ou objets. Une telle méthode ne serait pas
dans l’esprit de cette exploration, qui souhaitait montrer la possibilité d’un
développement générique. Mais la solution est là, qui attend un programmeur
disponible et un tant soit peu tenace.
A.3 Perspectives
A.3.1 Le devenir de NeXTSTEP
NeXT Computer, devenu Apple Enterprise Software, suite à un rachat
inattendu, a abandonné progressivement le support technique de NeXTSTEP 3.3,
et d’OPENSTEP 4.x, dernières versions du système…Malgré ses immenses
talents, ce système d’exception [Byte-1994], [[DiCosmo_Nora-1998], p 159-160] se
meurt après n’avoir connu qu’un succès d’estime.
Quid de la solution retenue ? A-t-elle déjà sombré dans les oubliettes de
l’industrie informatique ? Non pas. Openstep, spécification publique d’objets
définie conjointement par Sun Microsystems et NeXT Computer en 1994, est
toujours à flots. Elle est partie intégrante de Rhapsody, version de développement
de MacOS X, la nouvelle génération du système d’exploitation d’Apple.
Rhapsody, reposant sur le même noyau Mach que NeXTSTEP, est un système de
type UNIX du point de vue de ses fondations, donc permettant le contrôle de
priorités par l’utilisateur. Au même titre que NeXTSTEP, Rhapsody est multiplateforme, fonctionnant indifféremment sur PC et sur MacIntosh. Cela signifie
que ce système d’exploitation serait disponible pour tous les ordinateurs
portables, une avancée par rapport à NeXTSTEP, qui était limité au monde PC.
Malheureusement, pour des raisons obscures, MacOS X ne sera disponible que
292 Annexe Mesure et informatique
sur MacIntosh, alors que bon nombre de développements du système ont été
réalisés sur PC.
En ce qui concerne le développement d’applications spécifiques au son et
au signal, une correction du DriverKit est attendue qui permettra enfin lecture et
enregistrement en simultané sans que l’on doive employer deux cartes audio.
A.3.2 La généralisation du temps réel
Le standard Posix, dont la vocation est l’uniformisation des interfaces des
systèmes d’exploitations UNIX, vient de s’étendre au temps réel avec sa version 4
[Friesenham-1998]. Au niveau des systèmes particuliers, une version temps réel
de Mach est désormais disponible [RTMach-1997], mais son intégration à des
systèmes grand public n’a pas encore été réalisée. Une extension temps réel vient
aussi d’apparaître pour Linux [Yodaiken_EtAl-1998].
A.3.3 Le son, parent pauvre du multimédia
En 1998, la dernière édition de Visual C++, une référence en matière de
développement sous Windows (95 et NT), ne proposait toujours aucune classe
audio. Linux offrait, quant à lui, des outils de bas niveau [Tranter-1997].
Sur le plan du hardware, la généralisation des cartes audio de bonne qualité
se confirme. Des convertisseurs de 20 bits de résolution ne sont plus rares. Les
DSP se démocratisent, ainsi que les entrées / sorties numériques. De telles
entrées / sorties permettent d’interposer un enregistreur numérique dans la
chaîne de mesure, ce qui étend considérablement les possibilités de stockage, sans
compromettre la qualité des mesures. Mais l’amélioration des performances est
particulièrement lente comparée à la croissance vertigineuse de celles de cartes
vidéo. Au niveau hardware, et bien davantage encore au niveau software, le son
reste le parent pauvre du multimédia.
A.3.4 L’informatique domaine public
Openstep, disponible par ailleurs comme "surcouche" de WindowsNT, est
à l’origine du projet GNUstep, soutenu par la Free Software Foundation qui vise
à porter cette spécification sur Linux. Ce système d’exploitation pour PC et
MacIntosh, entre autres, est le plus répandu des UNIX domaine public à l’heure
293
actuelle. Le but de GNUstep est fournir à Linux les environnements utilisateur et
développeur conviviaux qui lui manquent.
Par ailleurs, le portage du MusicKit pour Openstep est très avancé. En
dehors de la phase de synthèse et d’acquisition, les traitements peuvent être
effectués par des logiciels domaine public comme Octave, qui est un clone de
Matlab. La visualisation peut être confiée à gnuplot, lui aussi domaine public.
D’où la perspective d’un système de mesure presque intégralement
domaine public, minimisant par ailleurs les coûts de développement,
combinaison de Linux, Openstep, MusicKit, Octave et gnuplot, sous réserve que
des drivers pour les cartes audio reconnues par le MusicKit soient disponibles
sous Linux. Ce portage devrait être facilité par le fait que Linux et NeXTSTEP
reposent l’un comme l’autre sur Mach.