Latência - Áudio Digital no Windows

Latência - áudio digital no Windows

No NAMM Show de 2000, a Cakewalk convidou representantes da Microsoft e de mais de 30 fabricantes de hardware e software para o primeiro "Windows Professional Audio Roundtable". O objetivo deste debate é trabalhar em conjunto no sentido de se obter soluções que tornem o Windows a plataforma ideal para áudio profissional. Este artigo apresenta os resultados das discussões.

Latência: o que é desejado e o que é possível

O critério mais importante para o desempenho de uma workstation de áudio digital (DAW) é a "latência", isto é, o atraso que existe para que uma alteração no som feita pelo software seja efetivamente ouvida. A latência afeta a resposta global da DAW à ação do usuário, assim como sua aplicabilidade para monitoração em tempo-real do sinal na entrada. A tendência atual de sintetizadores virtuais ("software synthesizers") também destaca a influência da latência na execução ao vivo com instrumentos musicais baseados em software.

Quão baixa deve ser a latência? Um engenheiro de áudio experiente pode ouvir diferenças sutis de sensibilidade na gravação de uma bateria se mover o microfone algumas dezenas de centímetros, uma distância equivalente a um atraso de cerca de 1 milisegundo. Estudos mostram que o ser humano pode perceber diferenças interaurais (estéreo) de cerca de 10 microsegundos (0,01 milisegundos). Assim, quanto menor o atraso, melhor.

Qual o melhor que podemos conseguir? A despeito das divulgações feitas por fabricantes de hardware e software, ninguém ainda mediu cientificamente a latência do áudio numa DAW. Entretanto, sabemos com certeza de que há três grandes limitações para estabelecer um limite mínimo na latência de um aplicativo.

Os conversores digital/analógico (DAC) e analógico/digital (ADC) de uma placa de áudio têm um atraso inerente. A latência típica de um conversor está na faixa de 30 a 50 amostras de áudio (samples), o que representa 1 a 1,5 milisegundos de atraso quando se opera com uma taxa de amostragem de 44.1 kHz.
O sistema operacional (Windows 98, NT ou 2000) introduz uma latência de interrupção, o atraso que ocorre entre o pedido de interrupção (IRQ) do hardware e o controle de recepção mais básico do driver. A latência de interrupção é um fator fundamental para o desempenho de um sistema operacional e não está disponível para otimização.

Uma análise sobre a latência de interrupção no Windows foi apresentada por Erik Cota-Robles e James Held no evento OSDI’99, e os resultados mostraram que o melhor valor de latência é da ordem de 1 milisegundo, e o pior valor é da ordem de 100 milisegundos.
A ordem de processamento no sistema operacional acarreta temporizações imprevisíveis quando a tarefa de uma aplicação precisa disparar um fluxo de dados de áudio. Com um projeto mais apurado isso pode ser mais previsível, de forma que poderíamos superar essa limitação específica.

Quando consideramos os efeitos da latência dos conversores e da latência de interrupção, fica claro que o menor valor que poderemos atingir no Windows está em torno de 2 milisegundos. Na realidade, a influência da carga do sistema na latência de interrupção e a ordem de processamento acaba levando a um desempenho inconsistente (que acarreta drop-outs aleatórios), e por isso na prática a latência de áudio será muito maior.

Dessa forma, minimizando a incerteza que surge sob condições pesadas de operação ajuda a reduzir a latência de áudio. Como o Windows NT e o Windows 2000 têm latências de interrupção bem pequenas, essas plataformas seriam as mais adequadas para as aplicações de áudio. Acreditamos que no Windows 2000 se possa obter uma latência inferior a 5 milisegundos, mesmo sob condições pesadas de operação.

Desenvolvimento de Software e Hardware - Observações e Conclusões

Os fabricantes de software enfrentam um desafio desanimador. Os usuários pedem a menor latência possível, mas conseguir isso requer conhecimento de características do sistema operacional que não são documentadas nem mesmo conhecidas. Como foi demonstrado pela tecnologia WavePipe introduzida no Cakewalk Pro Audio 9, é possível obter baixa latência com os drivers comuns, mas isso é ainda muito dependente da qualidade do driver.

Os fabricantes de hardware têm um desafio ainda maior. Na plataforma Windows, há uma variedade de formatos de drivers a se considerar: VxD, NT e WDM. E em cima desses drivers vivem uma diversidade de APIs: MME, DirectX, ASIO e EASI.

Por isso, os fabricantes de hardware precisam desenvolver muita programação para poder suportar tantos modelos de drivers e tantas APIs. E o resultado é o comprometimento geral do desempenho do driver.

Veja as etapas que o fabricante de hardware precisa para planejar qual driver criar:

Escolher a API: MME, DirectX, ASIO ou EASI.
Escolher o sistema operacional: Windows 98, Windows NT.
Desenvolver o componente kernel (.VxD ou .SYS), utilizando o conjunto de ferramentas de desenvolvimento de drivers da Microsoft DDK para o sistema operacional escolhido.
Desenvolver o componente para suportar a API (.DRV ou .DLL).

Observação 1: Muitos drivers

Para que um dispositivo suporte tanto o Windows 98 quanto o Windows NT é necessário desenvolver 2 drivers diferentes de kernel (um driver VxD e um driver SYS ). Acima disso, para suportar MME, ASIO e EASI é necessário desenvolver 3 drivers diferentes no nível de modo usuário.

Para poder suportar todas as plataformas e APIs populares, o fabricante de hardware precisa implementar e testar cinco componentes de driver.

Observação 2: Pouco suporte ao modo kernel

Alguns fabricantes nunca deixam o modo kernel fazer seu processamento. Exemplos claros disso são os sintetizadores virtuais WDM KMixer e DirectMusic. Além disso, os fabricantes de softwares de gravação digital precisam passar mais tarefas de mixagem e DSP para o modo kernel.

As APIs de modo usuário como DirectX, ASIO ou EASI não oferecem o suporte adequado para o processamento em modo kernel.

Observação 3: O termo "driver" é mal compreendido

Voltando às quatro etapas do desenvolvimento do driver, vemos que todos os caminhos levam através do Microsoft DDK, e somente o DDK fornece as ferramentas para interfaceamento do hardware de forma padronizada. A maior parte do interfaceamento do hardware deve ser feita no modo kernel, dentro dos arquivos VxD ou SYS.

O verdadeiro "driver" roda no kernel e está empacotado como um arquivo VxD ou SYS. As tecnologias MME, ASIO e EASI são meramente APIs de modo usuário, e não drivers.

A melhor forma de gerenciar a complexidade do driver e ao mesmo tempo oferecer suporte adequado para futuras tecnologias é desenvolver um único driver de áudio no modo kernel, que é na realidade uma marca do Windows Driver Model (WDM).

Texto original de Ron Kuper (Cakewalk Music)
Tradução: Miguel Ratton

Este artigo foi publicado no music-center.com.br em 2001