Partilhar via


Desenvolvendo um driver de miniporta WaveRT

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

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

O Windows Vista e sistemas operacionais Windows posteriores fornecem um driver de áudio HD para dispositivos de áudio compatíveis com UAA. Portanto, se o seu dispositivo de áudio é compatível com UAA, você não precisa desenvolver seu próprio driver de miniporta WaveRT. Mas para dispositivos de áudio que têm alguns recursos de hardware proprietários, não-UAA, você deve desenvolver seu próprio driver de miniporta WaveRT para suportar os recursos proprietários.

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

O driver do adaptador de exemplo

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

Os recursos compatíveis com o WaveRT

Depois de revisar o driver do adaptador de exemplo e começar a projetar seu driver de miniporta WaveRT, você deve verificar se ele suporta os seguintes recursos de software e hardware. Como resultado, o driver de miniporta que você cria torna-se 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 miniporta WaveRT deve fornecer uma implementação totalmente funcional do método IMiniportWaveRTStream::GetHWLatency . Este método é necessário para suportar a propriedade KSPROPERTY_RTAUDIO_HWLATENCY .

  • FIFO interrompe. Um driver de miniporta WaveRT deve gerar automaticamente interrupções quando ocorrem sobrecargas e subexecuções de FIFO. Esse recurso permite a deteção de falhas no fluxo de áudio quando você executa testes no dispositivo de áudio e no software do driver. Sem suporte de hardware (em outras palavras, interrupções FIFO), não existe método conveniente e confiável para obter informações de glitches.

  • Scatter-Gather DMA e Buffer Looping. Quando o driver da miniporta suporta um controlador DMA com recursos 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 da miniporta.

    Quando o driver da miniporta suporta um controlador DMA que pode efetuar loops de buffer, o controlador DMA pode retornar automaticamente ao início do buffer depois de atingir o final do buffer com uma operação de leitura ou gravação. Ele pode executar o wrap around sem a intervenção do seu driver de miniport.

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

    Se um dispositivo de áudio não tiver capacidade de dispersão-coleta, o driver de miniporta WaveRT deve primeiro alocar buffers cíclicos que consistem em páginas que são fisicamente contíguas na memória. O driver de miniporta usa funções auxiliares no driver de porta WaveRT para executar as transferências de dados e o looping automático do buffer. A desvantagem é que, à medida que o pool de memória não paginada de um sistema se torna cada vez mais fragmentado, uma solicitação para alocar um grande bloco de memória física contígua tem maior probabilidade de falhar. Um dispositivo com capacidade de dispersão-coleta não é afetado pela fragmentação da memória.

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

  • Registos de Posições. Para novos projetos, os implementadores de hardware devem incluir um registro de posição para cada canal DMA. Um registro de posição indica a posição atual do buffer como um deslocamento em bytes a partir 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 automaticamente se envolve no início do buffer (redefine para zero) e continua a aumentar à 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.

    Idealmente, os registradores de posição devem indicar a posição do buffer das amostras que estão atualmente se movendo através dos conversores digital-analógico e analógico-para-digital (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 registradores de posição estão localizados no chip do controlador de barramento, e cada registro indica a posição dos dados de áudio 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 das amostras que estão se movendo através dos DACs ou ADCs adicionando ou subtraindo o atraso através do codec. O cliente obtém o atraso do codec a partir da solicitação de propriedade KSPROPERTY_RTAUDIO_HWLATENCY . Por esse motivo, um driver de miniporta 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 suporta designs de hardware existentes que não possuem registros de posição. Para um dispositivo com essa limitação, o driver de miniporta WaveRT deve falhar chamadas para o método IMiniportWaveRTStream::GetPositionRegister retornando o código de erro STATUS_NOT_SUPPORTED , 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 através da propriedade KSPROPERTY_AUDIO_POSITION, que acarreta uma sobrecarga de uma transição entre o modo de usuário e o modo kernel para cada leitura de posição.

  • Registo do relógio. Um registro de relógio é um recurso de hardware opcional, mas útil, para um dispositivo de áudio compatível com WaveRT. Programas de aplicativos de áudio podem usar registradores 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 registradores de relógio, um aplicativo é incapaz de detetar e compensar o desvio entre os relógios de hardware.

    O relógio de amostra que o hardware de áudio usa para marcar dados de áudio através dos conversores digital-analógico ou analógico-para-digital deve ser derivado do relógio interno que incrementa o registro de relógio. Um registro de relógio que aumenta a uma taxa assíncrona em relação ao relógio de amostra não é útil 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 miniporta 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 do driver de áudio.

Os APOs estão disponíveis para uso apenas 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 nos dados nos buffers.

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