Summary

  • O Working Draft do W3C de 15 de dezembro de 2011 descreveu a Web Audio API como um grafo de AudioNode dentro de um AudioContext, ampliando o trabalho da página para processamento e síntese de som.
  • A Recomendação de 17 de junho de 2021 definiu controle temporal de parâmetros, renderização offline e processamento personalizado com AudioWorklet. O script monta o circuito; o navegador executa a parte pesada do áudio.

Na sala de ensaio, uma antiga máquina de música oferece um orgulhoso botão vermelho. O compositor pede que o som comece baixo, atravesse a sala, passe por um filtro e pare quando o personagem do jogo tocar o chão. A máquina sugere tocar o disco inteiro outra vez. Ela continua competente no serviço que conhece. A encomenda mudou. Uma página capaz de reproduzir uma gravação ainda precisava de meios para construir sons que respondessem à pessoa.

O Working Draft do W3C de 15 de dezembro de 2011 propôs uma interface de alto nível para processar e sintetizar áudio. Sua ideia principal era um grafo de roteamento: objetos AudioNode conectados definem como o sinal chega ao ouvinte. Uma fonte pode passar por filtro, controle de volume, posicionamento e destino final. JavaScript cria o arranjo. O documento dizia que a maior parte do processamento real ocorreria na implementação subjacente do navegador, em geral otimizada, embora também admitisse processamento direto por script. O compositor organiza os cabos; a máquina empurra o som.

Essa divisão tinha motivo. O elemento de áudio do HTML trouxera a reprodução básica para a web. O rascunho de 2011 olhava para jogos e aplicações interativas que precisavam misturar, filtrar e sintetizar. Uma gravação pronta acompanha uma cena. Ela não muda sozinha de direção quando o jogador se desloca nem constrói um instrumento a partir de um oscilador e um filtro. O grafo oferecia peças comuns que cada aplicação podia ligar em ordens diferentes.

As peças tinham funções bem específicas. AudioContext era o espaço do circuito. Nós de fonte entregavam material; ganho alterava nível; filtros mexiam nas frequências; atraso deslocava o sinal no tempo; análise fornecia dados para visualização; o nó de destino levava à saída audível. O primeiro rascunho também descrevia separar e reunir canais. Várias fontes podiam ser misturadas, ou uma fonte percorrer uma sequência de efeitos. O som nascia do desenho das ligações, não de um botão com poderes sobrenaturais.

Era preciso ainda um relógio. Se a batida de uma porta chega meio segundo depois da imagem, o jogador percebe uma falha, não uma pausa dramática. O desenho inicial incluía o tempo de AudioContext e o agendamento de eventos em relação a ele. A aplicação podia programar o início e o fim de um som. Não precisava pedir ao JavaScript da interface que acordasse para cada amostra de áudio enquanto atendia a menus e animações.

O Working Draft de 10 de outubro de 2013 ainda colocava o grafo no centro. Era o quinto rascunho público. O texto falava de áudio de jogos, aplicações interativas, mistura e filtros. O botão de tocar seguia ótimo para uma faixa inteira; a API nova servia a páginas que precisavam construir um comportamento sonoro. A diferença se parecia com escolher uma gravação ou montar a sessão de estúdio.

Na Recomendação de 17 de junho de 2021, a mesa ganhou uma partitura detalhada. AudioParam permitia fazer um valor como o ganho variar segundo o tempo do áudio, em vez de depender de uma fila de chamadas apressadas da página. OfflineAudioContext podia renderizar um grafo para um buffer sem reproduzi-lo imediatamente nos alto-falantes. Uma aplicação podia preparar ou examinar esse material antes de usá-lo. Fonte, processamento, relógio e saída continuavam sendo a estrutura do trabalho.

A especificação também abriu espaço para efeitos feitos sob medida por AudioWorklet. Um AudioWorkletNode no grafo trabalhava em par com um AudioWorkletProcessor numa área especial de processamento. A aplicação podia criar um módulo próprio sem transformar a interface inteira numa linha de produção de amostras. A Recomendação distinguia a thread de controle da thread de renderização. O som tem exigências de tempo que uma página ocupada com outro evento não pode resolver com boa vontade e um cronômetro de JavaScript.

A história de publicações do W3C vai do rascunho de dezembro de 2011 à Recomendação de junho de 2021. São datas de documentos, não um gráfico de adoção de navegadores. Elas mostram o tamanho do trabalho: definir conexões, canais, tempos, processamento e saída de modo que as peças funcionem juntas. Ter muitos controles é fácil; fazer cada controle cumprir a promessa quando ligado aos outros é o verdadeiro serviço da norma.

A aplicação ainda podia escolher sua música. Um jogo posicionaria uma explosão; uma ferramenta musical ligaria osciladores e filtros; uma aula desenharia o sinal obtido por um analisador. O navegador oferecia a mecânica compartilhada e cada programa montava sua peça. Uma página deixava de ordenar apenas “toque este arquivo” e passava a descrever como produzir o som.

A máquina de música não perdeu seu emprego. Uma canção pronta merece um botão simples. Mas uma orquestra que acompanha a ação do usuário não cabe no turno de um funcionário só. A Web Audio API pôs a mesa de som no navegador e entregou à aplicação um conjunto de controles. Se a composição ficou boa, aí é outra avaliação.