Desarrollo de un controlador waveRT Miniport

En este tema se presentan los puntos relacionados con el software y el hardware que debe tener en cuenta al decidir desarrollar su propio controlador de miniporte waveRT.

Microsoft ha desarrollado un conjunto de directrices de diseño de hardware para una arquitectura de audio universal (UAA) y las directrices incorporan las características que se recomiendan para un dispositivo de audio WaveRT. Las directrices de UAA se basan estrechamente en la especificación de audio de alta definición (HD) desarrollada por Intel.

Windows Vista y versiones posteriores Los sistemas operativos Windows proporcionan un controlador de audio HD para dispositivos de audio compatibles con UAA. Por lo tanto, si el dispositivo de audio es compatible con UAA, no tiene que desarrollar su propio controlador de miniporte waveRT. Pero para los dispositivos de audio que tienen algunas características de hardware propietarias que no son UAA, debe desarrollar su propio controlador de miniporte waveRT para admitir las características propietarias.

Para ayudarle a desarrollar su propio controlador de miniporte waveRT, le recomendamos que revise primero el controlador del adaptador de ejemplo y, a continuación, revise las características uaA compatibles con WaveRT.

Controlador de adaptador de ejemplo

Para obtener información sobre el controlador de ejemplo, vea Controladores de audio de ejemplo.

Las características compatibles con WaveRT

Después de revisar el controlador del adaptador de ejemplo y empezar a diseñar el controlador de miniporte waveRT, debe comprobar que admite las siguientes características de software y hardware. Como resultado, el controlador de minipuerto que compilas se vuelve compatible con el controlador de puerto WaveRT proporcionado por el sistema y con el modo de funcionamiento del motor de audio de Windows Vista.

• Baja latencia de hardware. Un controlador de miniporte waveRT debe proporcionar una implementación totalmente funcional del método IMiniportWaveRTStream::GetHWLatency . Este método es necesario para admitir la propiedad KSPROPERTY_RTAUDIO_HWLATENCY .

• Interrupciones de FIFO. Un controlador de miniporte waveRT debe generar automáticamente interrupciones cuando se producen saturaciones y subejeaciones de FIFO. Esta característica permite la detección de problemas en la secuencia de audio al ejecutar pruebas en el dispositivo de audio y el software del controlador. Sin soporte de hardware (es decir, interrupciones FIFO), no existe ningún método cómodo y confiable para obtener información de problemas.

• Scatter-Gather bucle de DMA y búfer. Cuando el controlador de minipuerto admite un controlador DMA que tiene funcionalidades de recopilación de dispersión, permite mover datos dentro y fuera del búfer cíclico sin necesidad de intervención del controlador de minipuerto.

  Cuando el controlador de minipuerto admite un controlador DMA que puede realizar bucles de búfer, el controlador DMA puede encapsularse automáticamente hasta el inicio del búfer después de llegar al final del búfer con una operación de lectura o escritura. Puede realizar el ajuste sin intervención del controlador de minipuerto.

  Tenga en cuenta que el controlador de puerto WaveRT admite diseños de hardware existentes que carecen de la capacidad de realizar transferencias de recopilación de dispersión o bucles de búfer automáticos.

  Si un dispositivo de audio no tiene capacidad de recopilación de dispersión, el controlador de miniporte waveRT primero debe asignar búferes cíclicos que constan de páginas que están físicamente contiguas en la memoria. A continuación, el controlador de miniporte usa funciones auxiliares en el controlador de puerto WaveRT para realizar las transferencias de datos y el bucle automático del búfer. El inconveniente es que, a medida que el grupo de memoria no paginado de un sistema se fragmenta cada vez más, es más probable que se produzca un error en una solicitud para asignar un bloque grande de memoria física contigua. Un dispositivo con capacidad de recopilación de dispersión no se ve afectado por la fragmentación de memoria.

  Si un dispositivo de audio no puede realizar automáticamente bucles de búfer cuando el canal DMA llega al final del búfer cíclico, el controlador de miniporte waveRT debe intervenir y configurar el canal para comenzar la transferencia de datos al principio del búfer.

• Posiciones de registros. En el caso de los nuevos diseños, los implementadores de hardware deben incluir un registro de posición para cada canal DMA. Un registro de posición indica la posición del búfer actual como desplazamiento de bytes desde el principio del búfer cíclico. La lectura del registro de posición es cero al principio del búfer. Cuando el registro de posición alcanza el final del búfer cíclico, se ajusta automáticamente al principio del búfer (se restablece a cero) y continúa incrementándose a medida que avanza la posición del búfer.

  Los registros de posición se pueden asignar a la memoria virtual para que los clientes puedan leer los registros directamente.

  Idealmente, los registros de posición deben indicar la posición del búfer de las muestras que se mueven actualmente a través de los convertidores analógico a analógico y analógico a digital (DAC y ADC) del dispositivo de audio.

  Sin embargo, es posible que esta información no esté disponible directamente desde un conjunto de chips de audio que divida las funciones digitales y analógicas en chips separados de controlador de bus y codificador/descodificador (códec). Normalmente, los registros de posición se encuentran en el chip del controlador de bus y cada registro indica la posición de los datos de audio en los que el controlador está escribiendo o leyendo desde los códecs.

  Después de obtener una lectura de este tipo de registro de posición, el cliente puede calcular la posición actual de las muestras que se mueven a través de los DAC o ADC agregando o restando el retraso a través del códec. El cliente obtiene el retraso del códec de la solicitud de propiedad KSPROPERTY_RTAUDIO_HWLATENCY . Por este motivo, un controlador de miniporte waveRT debe notificar con precisión el retraso del códec cuando el controlador de puerto llama al método IMiniportWaveRTStream::GetHardwareLatency en respuesta a este tipo de solicitud de propiedad.

  Tenga en cuenta que el controlador de puerto WaveRT admite diseños de hardware existentes que carecen de registros de posición. Para un dispositivo con esta limitación, el controlador de miniporte waveRT debe producir un error en las llamadas al método IMiniportWaveRTStream::GetPositionRegister devolviendo el código de error STATUS_NOT_SUPPORTED , lo que obliga al controlador de puerto a producir un error KSPROPERTY_RTAUDIO_POSITIONREGISTER solicitudes de propiedad. En este caso, los clientes deben obtener la posición actual a través de la propiedad KSPROPERTY_AUDIO_POSITION , lo que incurre en la sobrecarga de una transición entre el modo de usuario y el modo kernel para cada lectura de posición.

• Registro del reloj. Un registro de reloj es una característica de hardware opcional pero útil para un dispositivo de audio compatible con WaveRT. Los programas de aplicaciones de audio pueden usar registros de reloj para sincronizar secuencias de audio en dos o más dispositivos de audio independientes que tienen relojes de hardware independientes y no sincronizados. Sin registros de reloj, una aplicación no puede detectar y compensar el desfase entre los relojes de hardware.

  El reloj de ejemplo que usa el hardware de audio para procesar los datos de audio a través de los convertidores digitales a analógicos o analógicos a digitales debe derivarse del reloj interno que incrementa el registro del reloj. Un registro de reloj que se incrementa a una velocidad asincrónica con respecto al reloj de muestra no es de uso para la sincronización y no debe exponerse.

  De forma similar a los registros de posición, el registro del reloj se puede asignar a la memoria virtual para que los clientes puedan leer el registro directamente.

• Objetos de procesamiento de audio. Un controlador de miniporte waveRT bien diseñado nunca debe tocar los datos de audio en el búfer cíclico de un dispositivo de audio. El hardware debe diseñarse para que los datos de audio fluyan directamente entre el cliente y el hardware de audio sin intervención del software del controlador de audio.

Las API solo están disponibles para su uso con secuencias de audio en modo compartido. En el caso de secuencias en modo exclusivo, las aplicaciones intercambian datos directamente con dispositivos de hardware WaveRT a través de búferes cíclicos y ningún otro componente puede tocar los datos de los búferes.

Para obtener más información, vea Objetos de procesamiento de audio de Windows.