Latencia de transmisión durante la grabación

Mientras una secuencia de registros de audio está en estado De ejecución, el rol del controlador de puerto WaveRT es mínimo. Como se muestra en el diagrama siguiente, durante el proceso de grabación, el dispositivo de audio captura datos de audio y lo escribe en el búfer cíclico. A continuación, el motor de audio lee estos datos del búfer. Esta actividad no requiere ninguna intervención del controlador de puerto. Es decir, los datos de audio fluyen directamente entre el hardware de audio y la aplicación en modo de usuario sin que los componentes de software del modo kernel los toquen.

En el diagrama siguiente, las posiciones de registro y lectura progresan continuamente de izquierda a derecha a medida que el flujo fluye a través del búfer. Cuando el registro o la posición de lectura llegan al final del búfer, se ajusta al inicio del búfer.

El diagrama anterior identifica la posición de registro como la ubicación del búfer de la muestra que el dispositivo de audio está grabando actualmente (capturando desde el micrófono a través del convertidor analógico a digital o ADC). Tenga en cuenta que la posición del registro es la ubicación futura del búfer en la que el dispositivo de audio escribe la muestra después de pasar a través del FIFO. La posición de lectura es la posición del búfer desde la que el motor de audio lee el ejemplo siguiente.

Latencia desde el momento en que el dispositivo de audio captura una muestra de audio en el ADC hasta que el cliente lee simplemente es la separación entre las posiciones de registro y lectura. Esta separación es la suma de los siguientes orígenes de latencia (marcados como A y B en el diagrama):

Latencia A: después de capturar datos del ADC, el dispositivo de audio almacena los datos en un FIFO de hardware hasta que pueda escribir los datos en el búfer cíclico.

Latencia B: después de que el dispositivo de audio escriba datos en el búfer cíclico, los datos residen en el búfer hasta que el cliente lee los datos.

El cliente no tiene control sobre la latencia A, que depende completamente del hardware. Un FIFO típico podría almacenar aproximadamente 64 muestras del ADC. Sin embargo, el cliente controla la latencia B. Si la latencia B es demasiado grande, se introducen retrasos innecesarios en el sistema, pero lo que hace que sea demasiado pequeño para leer datos demasiado pronto, antes de que el dispositivo de audio haya escrito en el búfer.

Aunque el cliente puede configurar un temporizador para activar periódicamente su subproceso de lectura de búfer, este método no logra la latencia más pequeña. Para reducir aún más la latencia, el cliente puede configurar el dispositivo de audio para generar una notificación de hardware cada vez que el dispositivo termine de escribir un nuevo bloque de datos de captura en el búfer. En este caso, el subproceso de cliente se activa mediante notificaciones de hardware en lugar de mediante un temporizador.

Al hacer que el dispositivo de audio notifique periódicamente al motor de audio, el cliente puede hacer que la latencia sea más pequeña de lo que sería práctico.

El cliente (normalmente el motor de audio) puede obtener un resumen de los retrasos que el dispositivo de audio contribuye a la latencia de transmisión mediante el envío de una solicitud de KSPROPERTY_RTAUDIO_HWLATENCY al controlador de puerto waveRT.

Una vez que el cliente determina la cantidad de separación que se debe mantener entre el registro y las posiciones de lectura, el cliente supervisa los cambios en la posición del registro para determinar cuánto debe demorar la posición de lectura. En Windows Server 2008 y sistemas operativos posteriores, el cliente envía un KSPROPERTY_AUDIO_POSITION o una solicitud de propiedad KSPROPERTY_RTAUDIO_POSITIONREGISTER para determinar la posición del registro. El último método de solicitud es más eficaz porque permite al cliente leer la posición del registro directamente sin la transición a una rutina en modo kernel para la información.