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