Summary

  • El borrador del W3C de 15 de diciembre de 2011 describió la Web Audio API como un grafo de objetos AudioNode dentro de un AudioContext, capaz de procesar y sintetizar sonido más allá de la reproducción básica.
  • La Recomendación de 17 de junio de 2021 incorporó automatización temporal, renderizado sin salida inmediata y procesamiento personalizado con AudioWorklet. El script organiza; el navegador ejecuta la parte de audio en tiempo real.

En una sala de ensayo hay una vieja máquina de discos con un botón rojo. El compositor le pide un sonido que comience suave, pase por un filtro, se desplace hacia la izquierda y termine justo cuando el personaje del juego aterriza. La máquina responde con su único talento: tocar otra vez el disco. No está averiada. Está fuera de su oficio. Una página web que debía reaccionar al usuario necesitaba algo más que iniciar una grabación.

El borrador del W3C publicado el 15 de diciembre de 2011 propuso una interfaz de alto nivel para procesar y sintetizar audio. Su pieza central era un grafo de encaminamiento: varios objetos AudioNode se conectan para determinar cómo viaja la señal. Una fuente puede entrar en un filtro, pasar por un control de ganancia, cambiar de posición espacial y llegar al destino audible. JavaScript organiza las conexiones. El documento señalaba que la mayor parte del procesamiento real correría en la implementación subyacente, habitualmente optimizada, aunque también admitía procesamiento directo por script. El compositor enchufa; el navegador hace trabajar los altavoces.

La distinción era necesaria. El elemento de audio de HTML había dado a las páginas reproducción básica, un avance real frente a etapas anteriores. El borrador de 2011 miraba a juegos y aplicaciones interactivas con necesidades de mezcla, filtrado y síntesis. Una pista grabada puede acompañar una escena. No puede, por sí sola, ajustarse a cada movimiento del jugador o convertir una nota en otra textura mientras suena. El grafo ofrecía operaciones comunes que cada aplicación podía combinar a su manera.

Las operaciones tenían piezas reconocibles. AudioContext alojaba el circuito. Había nodos de origen, de ganancia, de filtro y de retardo; analizadores para alimentar visualizaciones; separadores y mezcladores de canales; y un destino donde terminaba el sonido escuchado. Una fuente podía recorrer varios efectos y varias fuentes podían reunirse antes de la salida. El resultado no pertenecía a un botón mágico. Surgía de las conexiones entre componentes pequeños.

También hacía falta un reloj propio. En un juego, un golpe que suena tarde parece un actor entrando después de que cayó el telón. El diseño temprano describía el tiempo de AudioContext y la programación de eventos sonoros respecto a ese reloj. El programa podía decidir cuándo empezar o detener una fuente. La tarea de JavaScript era preparar la función, no despertarse para empujar cada muestra de audio mientras la página atiende otros asuntos.

El borrador del 10 de octubre de 2013 seguía colocando el grafo en el centro. Era ya el quinto borrador público. El texto describía sonido de juegos complejos, aplicaciones interactivas, mezcla y filtros. El botón de reproducir seguía sirviendo perfectamente a una canción entera. La nueva API se dirigía a quien necesitaba construir un comportamiento sonoro a partir de piezas, igual que una escena se construye con objetos y movimiento.

La Recomendación del 17 de junio de 2021 presentó una partitura mucho más completa. AudioParam permitía variar parámetros como la ganancia dentro de una línea temporal de audio. OfflineAudioContext podía procesar un grafo y guardar el resultado en un búfer sin reproducirlo inmediatamente. Una aplicación podía preparar, examinar o reutilizar ese resultado. Fuentes, procesadores, tiempo y destino seguían siendo las referencias esenciales de la mesa.

Para los efectos a medida, la Recomendación describió AudioWorklet. Un AudioWorkletNode en el grafo se empareja con un AudioWorkletProcessor que realiza el procesamiento en un ámbito especial. La especificación también distinguía el hilo de control del hilo de renderizado. La interfaz de una página puede retrasarse por mil motivos; el camino del sonido tiene obligaciones temporales más estrictas. Dar al programa una mesa de mezclas no significaba pedirle que calcule cada muestra en el mismo hilo que anima un menú.

La historia oficial de publicaciones va del borrador de diciembre de 2011 a la Recomendación de junio de 2021. Son fechas del trabajo normativo, no cifras sobre adopción ni el calendario de un navegador concreto. El intervalo ayuda a entender la cantidad de reglas necesarias: conexiones, canales, relojes, nodos personalizados, recursos y salida. Una mesa de mezclas no funciona porque tenga muchos mandos; funciona porque cada conexión y cada mando tienen una conducta previsible.

La libertad de la aplicación seguía intacta. Un juego podía situar una explosión, una herramienta musical conectar osciladores y filtros, y una lección usar un analizador para mostrar la forma del sonido. El navegador proporcionaba piezas y ejecución compartidas; cada programa decidía su arreglo. La página dejaba de limitarse a pedir «reproduce este archivo» y podía describir cómo debía construirse el sonido.

La máquina de discos conserva su lugar. A veces una canción y un botón son todo lo que se necesita. Pero cuando el sitio pide una orquesta que responda a cada gesto, ese botón trabaja con una plantilla de personal ridícula. Web Audio colocó una mesa de mezclas delante del navegador y entregó al programa los controles. Todavía hacía falta escribir buena música.