Summary

  • Le projet de Web Audio API publié par le W3C le 15 décembre 2011 décrivait un graphe de nœuds AudioNode au sein d’un AudioContext, destiné à traiter et à synthétiser du son au-delà de la simple lecture.
  • La recommandation du 17 juin 2021 a défini notamment l’automatisation temporelle, le rendu hors lecture immédiate et les traitements personnalisés avec AudioWorklet. L’application organise le graphe ; le moteur du navigateur calcule le son.

Dans une salle de répétition, le juke-box connaît une réponse à toutes les demandes : appuyer sur son bouton rouge. Le compositeur, lui, voudrait qu’un son démarre doucement, traverse la scène, passe dans un filtre, puis s’arrête au moment précis où un personnage tombe. « Rejouer la chanson » ne fera pas l’affaire. Les pages web avaient gagné une lecture audio de base, mais les jeux et outils musicaux réclamaient une matière que l’on puisse modeler.

Le projet du W3C daté du 15 décembre 2011 proposait une interface pour traiter et synthétiser le son. Son image centrale était un graphe de routage : plusieurs objets AudioNode reliés entre eux déterminent le trajet du signal. Une source peut alimenter un filtre, passer par un réglage de volume, être placée dans l’espace puis arriver à la sortie. JavaScript construit et règle les connexions. Le document précisait que l’essentiel du traitement avait lieu dans l’implémentation sous-jacente du navigateur, généralement optimisée, tout en autorisant aussi le traitement par script. Le compositeur branche les câbles ; la machine fait vibrer l’air.

Cette distinction répondait à une limite concrète. L’élément audio de HTML rendait la lecture ordinaire possible et comptait déjà beaucoup. Le projet de 2011 visait plus loin : jeux, applications interactives, mixage, filtres et synthèse. Un morceau enregistré peut accompagner une page. Il ne sait pas, à lui seul, réagir à la position d’un joueur ni transformer une note pendant qu’elle sonne. Le graphe donnait à l’application des pièces communes qu’elle pouvait assembler dans plusieurs ordres.

Ces pièces portaient des noms de travail. AudioContext accueillait le graphe. Des nœuds sources fournissaient le son, un nœud de gain changeait son niveau, un filtre travaillait certaines fréquences, un délai décalait le signal, un analyseur pouvait alimenter une visualisation, et un nœud de destination conduisait vers la sortie audible. Le projet prévoyait aussi la séparation et la réunion des canaux. Une même source pouvait passer par plusieurs effets ; plusieurs sons pouvaient être mélangés avant les haut-parleurs. Aucun bouton isolé n’avait à connaître tout l’orchestre.

Il fallait également un temps musical, pas seulement le temps approximatif du reste de la page. Dans un jeu, un bruit qui arrive après l’action ressemble à une réplique oubliée. Le premier projet décrivait une horloge d’AudioContext et la programmation des événements sonores par rapport à elle. L’application pouvait placer le début et la fin d’un son sur cette ligne temporelle. Elle n’avait pas à réveiller JavaScript pour chaque échantillon en espérant que l’interface graphique lui laisserait la parole à l’instant voulu.

Le projet de travail du 10 octobre 2013 conservait le graphe comme modèle principal. Il s’agissait du cinquième projet public, signe d’une grammaire encore affinée. Le texte parlait de sons complexes de jeux, d’applications interactives, de mixage et de filtrage. Le lecteur audio simple avait toujours sa place pour un morceau entier. La nouvelle interface visait les pages qui voulaient construire le son pendant que l’utilisateur agissait.

La recommandation du 17 juin 2021 donnait au dispositif une partition plus complète. AudioParam permettait de faire varier un paramètre, par exemple le gain, selon le temps audio. OfflineAudioContext rendait un graphe dans un tampon sans le jouer immédiatement dans les haut-parleurs. Une application pouvait préparer un résultat, l’examiner ou le réutiliser. Sources, traitements, destination et temps restaient les repères de base ; le navigateur devait faire tenir ensemble les décisions prises par la page.

AudioWorklet ouvrait une place aux traitements sur mesure. La recommandation décrivait le couple AudioWorkletNode, du côté du graphe principal, et AudioWorkletProcessor, dans un espace de traitement particulier. Cette paire permettait d’ajouter un effet propre à l’application. Le document distinguait aussi le fil de contrôle du fil de rendu. La page décide des connexions et des paramètres ; le chemin qui produit le son suit des contraintes temporelles plus sévères que celles d’un clic sur un menu. Faire attendre une note parce que l’interface prépare un autre élément aurait été un chef d’orchestre bien distrait.

La chronologie des publications du W3C va du projet de décembre 2011 à la recommandation de juin 2021. Ces dates sont celles des documents, pas une mesure du nombre de navigateurs ou d’auditeurs. Elles montrent cependant qu’un graphe sonore exige une longue liste de règles : connexions, canaux, calendrier, traitement et sortie. Une table de mixage utilisable tient moins à la quantité de boutons qu’à leur comportement commun.

L’application gardait une grande liberté. Un jeu pouvait placer une explosion dans l’espace ; un instrument en ligne pouvait relier oscillateurs et filtres ; une leçon pouvait montrer le signal grâce à un analyseur. Le navigateur fournissait les mécanismes partagés. Chacun écrivait sa partition. Le résultat n’était pas un juke-box forcé de devenir pianiste : c’était un atelier dans lequel une page pouvait décrire le son qu’elle voulait faire entendre.

Le bouton Lecture reste excellent lorsqu’il faut simplement écouter un morceau. Mais il devient un employé bien seul dès qu’un monde interactif réclame un orchestre. Web Audio API a installé la console, fixé les prises et confié l’exécution au navigateur. Il reste au compositeur à choisir de bonnes notes.