Desenvolvendo um driver de miniporto WaveRT

Este tópico apresenta os pontos relacionados a software e hardware que você deve considerar ao decidir desenvolver seu próprio driver de miniporto WaveRT.

A Microsoft desenvolveu um conjunto de diretrizes de design de hardware para uma UAA (Arquitetura Universal de Áudio) e as diretrizes incorporam os recursos que recomendamos para um dispositivo de áudio WaveRT. As diretrizes de UAA são baseadas de perto na especificação de áudio de alta definição (HD) desenvolvida pela Intel.

Os sistemas operacionais Windows Vista e posteriores fornecem um driver de áudio HD para dispositivos de áudio compatíveis com UAA. Portanto, se o dispositivo de áudio for compatível com UAA, você não precisará desenvolver seu próprio driver de miniporta WaveRT. Mas para dispositivos de áudio que têm alguns recursos proprietários de hardware não UAA, você deve desenvolver seu próprio driver de miniporto WaveRT para dar suporte aos recursos proprietários.

Para ajudá-lo a desenvolver seu próprio driver de miniporto WaveRT, recomendamos que você primeiro examine o driver do adaptador de exemplo e, em seguida, examine os recursos UAA amigáveis do WaveRT.

O driver do adaptador de exemplo

Para obter informações sobre o driver de exemplo, consulte Drivers de áudio de exemplo.

Os recursos amigáveis do WaveRT

Depois de examinar o driver do adaptador de exemplo e começar a projetar seu driver de miniporto WaveRT, você deve verificar se ele dá suporte aos seguintes recursos de software e hardware. Como resultado, o driver de miniporto que você cria se torna compatível com o driver de porta WaveRT fornecido pelo sistema e com o modo de operação do mecanismo de áudio do Windows Vista.

• Baixa latência de hardware. Um driver de miniporto WaveRT deve fornecer uma implementação totalmente funcional do método IMiniportWaveRTStream::GetHWLatency . Esse método é necessário para dar suporte à propriedade KSPROPERTY_RTAUDIO_HWLATENCY .

• Interrupções fifo. Um driver de miniporto WaveRT deve gerar automaticamente interrupções quando ocorrerem estouros e subexecutações de FIFO. Esse recurso permite a detecção de falhas no fluxo de áudio quando você executa testes no dispositivo de áudio e no software de driver. Sem suporte de hardware (em outras palavras, interrupções FIFO), não existe nenhum método conveniente e confiável para obter informações de falha.

• Scatter-Gather DMA e looping de buffer. Quando o driver de miniporta dá suporte a um controlador de DMA que tem recursos de coleta de dispersão, ele permite que os dados sejam movidos para dentro e para fora do buffer cíclico sem a necessidade de intervenção do driver de miniporto.

  Quando o driver de miniporta dá suporte a um controlador DMA que pode executar loops de buffer, o controlador de DMA pode encapsular automaticamente até o início do buffer depois de atingir o final do buffer com uma operação de leitura ou gravação. Ele pode executar a quebra automática sem intervenção do driver de miniporta.

  Observe que o driver de porta WaveRT dá suporte a designs de hardware existentes que não têm a capacidade de executar transferências de coleta de dispersão ou loops de buffer automáticos.

  Se um dispositivo de áudio não tiver capacidade de coleta de dispersão, o driver de miniporto WaveRT deverá primeiro alocar buffers cíclicos que consistem em páginas fisicamente contíguas na memória. Em seguida, o driver de miniporta usa funções auxiliares no driver de porta WaveRT para executar as transferências de dados e o loop de buffer automático. A desvantagem é que, à medida que o pool de memória nãopagada de um sistema se torna cada vez mais fragmentado, é mais provável que uma solicitação para alocar um grande bloco de memória física contígua falhe. Um dispositivo com capacidade de coleta de dispersão não é afetado pela fragmentação de memória.

  Se um dispositivo de áudio não puder executar loops de buffer automaticamente quando o canal DMA atingir o final do buffer cíclico, o driver de miniporto WaveRT deverá intervir e configurar o canal para iniciar a transferência de dados no início do buffer.

• Registros de posição. Para novos designs, os implementadores de hardware devem incluir um registro de posição para cada canal de AMD. Um registro de posição indica a posição atual do buffer como um deslocamento de bytes do início do buffer cíclico. A leitura do registro de posição é zero no início do buffer. Quando o registro de posição atinge o final do buffer cíclico, ele é encapsulado automaticamente até o início do buffer (redefine para zero) e continua a incrementar à medida que a posição do buffer avança.

  Os registros de posição podem ser mapeados para a memória virtual para que os clientes possam ler os registros diretamente.

  O ideal é que os registros de posição indiquem a posição do buffer dos exemplos que estão atualmente se movendo pelos conversores digitais para analógicos e analógicos para digitais (DACs e ADCs) do dispositivo de áudio.

  No entanto, essas informações podem não estar diretamente disponíveis em um chipset de áudio que divide as funções digitais e analógicas em chips separados de controlador de barramento e codificador/decodificador (codec). Normalmente, os registros de posição estão localizados no chip do controlador de barramento e cada registro indica a posição dos dados de áudio em que o controlador está gravando ou lendo dos codecs.

  Depois de obter uma leitura desse tipo de registro de posição, o cliente pode estimar a posição atual dos exemplos que estão se movendo pelos DACs ou ADCs adicionando ou subtraindo o atraso por meio do codec. O cliente obtém o atraso de codec da solicitação de propriedade KSPROPERTY_RTAUDIO_HWLATENCY . Por esse motivo, um driver de miniporto WaveRT deve relatar com precisão o atraso do codec quando o driver de porta chama o método IMiniportWaveRTStream::GetHardwareLatency em resposta a esse tipo de solicitação de propriedade.

  Observe que o driver de porta WaveRT dá suporte a designs de hardware existentes que não têm registros de posição. Para um dispositivo com essa limitação, o driver de miniporto WaveRT deve falhar nas chamadas para o método IMiniportWaveRTStream::GetPositionRegister retornando o código de erro STATUS_NOT_SUPPORTED , o que força o driver de porta a falhar KSPROPERTY_RTAUDIO_POSITIONREGISTER solicitações de propriedade. Nesse caso, os clientes devem obter a posição atual por meio da propriedade KSPROPERTY_AUDIO_POSITION , o que incorre na sobrecarga de uma transição entre o modo de usuário e o modo kernel para cada leitura de posição.

• Registro de Relógio. Um registro de relógio é um recurso de hardware opcional, mas útil, para um dispositivo de áudio compatível com WaveRT. Os programas de aplicativos de áudio podem usar registros de relógio para sincronizar fluxos de áudio em dois ou mais dispositivos de áudio independentes que têm relógios de hardware separados e não sincronizados. Sem registros de relógio, um aplicativo não consegue detectar e compensar o descompasso entre os relógios de hardware.

  O relógio de exemplo que o hardware de áudio usa para marcar dados de áudio por meio dos conversores digitais para analógicos ou analógicos para digitais deve ser derivado do relógio interno que incrementa o registro do relógio. Um registro de relógio que incrementa a uma taxa assíncrona em relação ao relógio de exemplo não é de uso para sincronização e não deve ser exposto.

  Semelhante aos registros de posição, o registro de relógio pode ser mapeado para a memória virtual para que os clientes possam ler o registro diretamente.

• Objetos de processamento de áudio. Um driver de miniporto WaveRT bem projetado nunca deve tocar nos dados de áudio no buffer cíclico de um dispositivo de áudio. O hardware deve ser projetado para que os dados de áudio fluam diretamente entre o cliente e o hardware de áudio sem intervenção do software de driver de áudio.

As APOs estão disponíveis para uso somente com fluxos de áudio de modo compartilhado. Para fluxos de modo exclusivo, os aplicativos trocam dados diretamente com dispositivos de hardware WaveRT por meio de buffers cíclicos e nenhum outro componente pode tocar os dados nos buffers.

Para obter mais informações, consulte Objetos de processamento de áudio do Windows.