Accueil > Web > Les Audio Workers à Best Of Web 2015

Les Audio Workers à Best Of Web 2015

Cet article a été initialement rédigé par son auteur en juillet.

Le 5 juin 2015 a eu lieu le premier Best Of Web 2015 à Paris, un rassemblement des meilleurs Meetups de l’année. Cet article fait suite à l’article de présentation de la Web Audio API. Ici nous nous intéressons à un nœud spécifique de la Web-Audio API, les Audio Workers.

Une des fonctionnalités les plus attendues par les développeurs qui font du web audio sont les Audio Workers. Nous allons voir ici ce qu’apportent ces nœuds, en quoi ils sont différents des autres et surtout pourquoi la communauté JS est autant excitée à ce sujet.

Avant-propos

Les Audio Workers sont toujours en cours de spécification, aucun navigateur ne les supporte actuellement. Cette article peut donc potentiellement décrire certaines fonctionnalités qui seront totalement différentes dans le futur. D’ailleurs, si vous avez des idées pour améliorer les spécifications n’hésitez pas à aller en discuter sur le fil github associé.

Le principe

Les Audio Workers sont des nœuds personnalisés. C’est à dire qu’ici, nous avons le droit de modifier le signal bit par bit. Il est aussi possible de créer des paramètres spécifiques à ces nœuds. Tout comme les autres nœuds, nous pouvons utiliser toutes les fonctions disponibles pour les audio params comme linearRampToValueAtTime par exemple.

De plus les Web Workers possèdent un système de messagerie. Il est en effet possible d’envoyer des messages à chaque nœud du même type. Le système de messagerie suggère que chaque instance partage un tronc commun : il s’appelle l’AudioWorkerGlobalScope.

Comparaison avec ce que l’on a déjà

ScriptProcessorNode

Actuellement, pour avoir un nœud qui fait des traitements spécifiques nous avions le nœud ScriptProcessorNode. Ce nœud, à l’instar de l’AnalyserNode, fonctionne avec un buffer. Tandis que le buffer de l’AnalyserNode est en lecture seule, celui du ScripProcessorNode est en écriture. Voici un exemple de code pour multiplier l’amplitude par 2 d’un signal :

Avec ce genre de nœud, on peut réellement faire tous les traitements que l’on souhaite sur le signal. Néanmoins, hormis la modularité que peut apporter le système des audio params, l’apport des Audio ne saute pas aux yeux.

La même chose mais avec un Web Worker

Le module des Web Workers permet d’inclure directement le nom du fichier contenant le code de notre nœud. Le code est donc séparé en deux fichiers :

Main.js

nodeFactory.js

A première vue, il n’y a pas de grandes différences avec le ScriptProcessorNode, sauf qu’il y a une couche d’abstraction supplémentaire ici. Cela rend le code plus joli lors de la création de nouveau type de nœuds, mais rien de plus.

Une histoire de file d’exécution

Comme nous l’avons vu dans l’article précédent, la web audio api n’est pas exécutée dans le même file d’exécution que celui du rendu et même que celui de l’exécution du JS en général.

Or, le code à l’intérieur du ScriptProcessorNode est exécuté dans la file d’exécution principale et cela soulève de gros problèmes de performance. En effet, ce code sera impacté par les performances de Rendering, d’exécution du reste du JS et autre code de la page. Cela signifie qu’un bug sonore peut survenir si en même temps on demande au navigateur de nous afficher un tableau de 1000 lignes.

Les codes à l’intérieur des Web Audio Worker quant à eux s’exécutent dans la file d’exécution réservée à l’audio. La possibilité de bug audio à cause d’un rendering gourmand est alors nulle !

Asynchronisme incompatible avec l’Audio

Quand un ScriptProcessorNode cherche à redéfinir sa sortie, la modification se fait de manière asynchrone. Comme le nœud ne peut pas simplement attendre, le nœud insère de la latence. En effet, le nœud attend une certaine volumétrie de données (la taille du buffer) et ensuite fait les appels asynchrones entre les différentes files d’exécution. Ensuite le nœud ajoute encore de la latence pour avoir le temps de traiter les données.

Pour illustrer le propos, le développeur de Google Chris Wilson explique que ce type de nœud inclus une latence d’environ 23ms pour un buffer de 512 bits et plus de 50ms pour un buffer de 1024 bits (qui est la valeur pas défaut).

Avec les Web Audio Worker, le code est directement exécuté dans la file d’exécution de l’audio. Il n’y a pas d’appel transverse, donc l’appel aux fonctions peut se faire de façon synchrone. La seule latence sera le temps d’exécution de notre code.

Conclusion

Les Web Audio Workers apporteront beaucoup plus de flexibilité dans notre manière d’écrire du code avec la Web Audio API et apporteront aussi beaucoup plus de performance. Le seul regret que l’on peut avoir est que le code dans les scriptProcessorNode ne soit pas exécuté dans la bonne file d’exécution. Cela aurait résolu pas mal de problèmes de performance. A cause de ça, le scriptProcessorNode sera amené à disparaître. Il est d’ailleurs déjà “deprecated” dans la spécification. Mais il est vrai que c’est difficile de faire une spécification parfaite dès le départ.

Liens utiles

Categories: Web Tags: , , ,


9 − = cinq