Procesamiento de audio de Hardware-Offloaded
El procesamiento de audio descargado por hardware permite realizar las tareas principales de procesamiento de audio fuera de la CPU principal del equipo.
El procesamiento de audio puede ser muy intensivo en el cálculo. Por lo tanto, en muchos escenarios, puede ser beneficioso permitir que un procesador dedicado se ocupe de tareas de procesamiento como, por ejemplo, mezclar y aplicar efectos.
Al implementar un controlador para el audio descargado, desarrolla un controlador que puede procesar secuencias de audio descargadas y exponer esa capacidad al sistema de audio de Windows.
En los temas siguientes de esta sección se describe el desarrollo de controladores, el impacto de la aplicación y otros problemas que debe tener en cuenta al desarrollar un controlador de audio para un adaptador de audio que implementa un motor de audio de hardware para controlar las secuencias de audio descargadas.
Implementación del controlador de audio descargado de hardware
Interfaces auxiliares para el procesamiento de audio descargado
Informes de problemas para audio descargado
Para obtener información sobre las API descargadas, consulte Efectos de APO descargados de hardware.
Introducción a la arquitectura de procesamiento de audio de Hardware-Offloaded
El motor de audio de software
En el diagrama siguiente se muestra el motor de audio de software de Windows.
Las secuencias de audio llegan al motor de audio de software desde la capa de la API de sesión de audio (WASAPI) de Windows y, posiblemente, a través de una API de nivel superior, como Media Foundation. En los efectos de secuencia del motor de audio de software (SFX), se puede aplicar por secuencia antes de que se mezclen las secuencias independientes y, a continuación, pasar a través de los efectos de punto de conexión disponibles (EFX) y enviarse al hardware y altavoces de representación.
El motor de audio de hardware
El motor de audio de hardware se implementa en el adaptador de audio y, en gran medida, refleja la funcionalidad del motor de audio de software. Y aunque Windows admite el procesamiento de audio descargado por hardware, el controlador de audio de un adaptador de audio determinado es responsable de exponer las funcionalidades subyacentes del hardware de audio, mediante la topología que se muestra en el diagrama siguiente.
El motor de audio de hardware debe aceptar una secuencia de proceso de host única y hasta n secuencias descargadas. Estos flujos descargados se enrutan directamente desde el nivel de aplicación que se va a procesar en hardware. En otras palabras, las secuencias descargadas no se pasarán a través del motor de audio de software. En el diagrama se muestra una implementación diseñada para controlar hasta tres flujos descargados. La secuencia del proceso de host es la salida final del mezclador de software de todas las secuencias procesadas en el motor de audio de software. Cada motor de audio de hardware también debe contener un mezclador de hardware.
Para mantener la paridad con el motor de audio de software y la interfaz WASAPI, es necesario que el motor de audio de hardware proporcione la secuencia de salida de audio final a la pila de audio en forma de secuencia de bucle invertido. Esto es especialmente crítico para las aplicaciones y escenarios que se basan en la cancelación acústica de eco, lo que requiere conocimiento del flujo de salida final para cancelar los ecos y evitar comentarios.
Para implementar una ruta de acceso para una secuencia de bucle invertido, el controlador de audio es responsable de exponer un pin de bucle invertido. Este pin devolverá los datos de audio de la salida final del motor de audio, si los datos se codifican en un formato PCM. De lo contrario, se devolverá el resultado posterior a la mezcla (pero codificación previa). Esto significa que, en el caso de los datos de audio que se procesan con un hardware EFX que codifica en un formato que no es PCM, la secuencia de bucle invertido se toma directamente después del mezclador de hardware, antes de la fase EFX en el motor de audio de hardware. Para obtener información sobre la topología de filtro KS que representa el motor de audio de hardware, consulte Implementación del controlador de audio descargado de hardware.
La arquitectura de audio integrada
En el diagrama siguiente se muestra información general de la arquitectura resultante cuando un motor de audio de hardware funciona con el motor de audio de software de Windows.
En un escenario en el que el controlador de audio ha indicado su compatibilidad con el procesamiento de audio descargado, las primeras n (en este caso, tres) secuencias que se inicializan se enrutarán directamente desde la capa WASAPI al motor de audio de hardware, pasando el motor de audio de software. Las nuevas secuencias de audio posteriores a n compatibles con el motor de audio de hardware se enrutarán a través del motor de audio de software para su procesamiento. La secuencia resultante del motor de audio de software se envía al motor de audio de hardware como secuencia de proceso de host. La secuencia de proceso de host se mezcla con las primeras n secuencias, se aplica el procesamiento de EFX y, a continuación, se envía la secuencia resultante a los altavoces.
Topología de filtro KS
En Windows 8 y sistemas operativos posteriores, se ha proporcionado compatibilidad con un motor de audio de hardware incorporado para procesar secuencias de audio. Al desarrollar este tipo de adaptador de audio, el controlador de audio asociado debe exponer este hecho al sistema de audio en modo de usuario de una manera específica, para que el sistema de audio pueda detectar, usar y exponer correctamente las características de este adaptador y su controlador.
Para que los controladores de audio expongan las funcionalidades de hardware de estos nuevos adaptadores de audio, Windows 8 introdujo una topología de filtro KS que el controlador debe usar:
Como se muestra en la ilustración anterior, una topología de filtro KS representa las rutas de acceso de datos a través del hardware y también muestra las funciones que están disponibles en esas rutas de acceso. En el caso de un adaptador de audio que puede procesar audio descargado, hay las siguientes entradas y salidas (denominadas patillas) en el filtro KS:
Una patilla de proceso de host. Esto representa la entrada en el filtro KS del motor de audio de software.
Una patilla de bucle invertido. Esto representa una salida del motor de audio de hardware a la capa de la API de sesión de audio de Windows (WASAPI).
Número de patillas de audio descargados. Aunque la figura muestra solo un pin de este tipo, un IHV es libre de implementar cualquier número (n) de patillas.
El servicio real en el sistema de audio en modo de usuario que "conduce" a la detección del adaptador de audio y su controlador, es AudioEndpointBuilder. El servicio AudioEndpointBuilder supervisa la clase KSCATEGORY_AUDIO para las llegadas y eliminaciones de la interfaz de dispositivo. Cuando un controlador de dispositivo de audio registra una nueva instancia de la KSCATEGORY_AUDIO clase de interfaz de dispositivo, se activa una notificación de llegada de la interfaz de dispositivo. El servicio AudioEndpointBuilder detecta la notificación de llegada de la interfaz de dispositivo y usa un algoritmo para examinar la topología de los dispositivos de audio en el sistema para que pueda tomar las medidas adecuadas.
Al desarrollar el controlador de audio para admitir un adaptador capaz de procesar audio descargado, el controlador debe usar el punto de conexión de audio KSNODETYPE_AUDIO_ENGINE para exponer las funcionalidades del motor de audio de hardware. Para obtener más información sobre el proceso de detección de puntos de conexión de audio, consulte Algoritmo del Generador de puntos de conexión de audio.
Consideraciones sobre la interfaz de usuario
Ha desarrollado el controlador de audio para controlar las capacidades de hardware subyacentes de un adaptador de audio que es capaz de procesar audio descargado. Esto significa que el controlador tiene los mejores conocimientos sobre cómo controlar las características del adaptador. Por lo tanto, debe desarrollar una interfaz de usuario que expondrá las características del adaptador al usuario final en forma de opciones que pueden seleccionar, habilitar o deshabilitar.
Sin embargo, si ya tiene una interfaz de usuario que se usa para controlar objetos de procesamiento de audio (API) que ha desarrollado, esta interfaz de usuario podría ampliarse para trabajar con el nuevo adaptador de audio. En este caso, las extensiones de la interfaz de usuario proporcionarían control de software para las API y el control de hardware para el adaptador.
Impacto en la aplicación
Las aplicaciones para UWP pueden usar la funcionalidad descrita para este nuevo tipo de adaptador de audio y su controlador asociado a través de WASAPI, Media Foundation, Media Engine o las etiquetas de audio> HTML 5<. Ten en cuenta que wave y DSound no se pueden usar, ya que no están disponibles para las aplicaciones para UWP. Tenga en cuenta también que las aplicaciones de escritorio no pueden usar las funcionalidades de descarga de adaptadores de audio que admiten audio descargado por hardware. Estas aplicaciones todavía pueden representar audio, pero solo a través del pin host que hace uso del motor de audio de software.
Si una aplicación para UWP transmite contenido multimedia y usa Media Foundation, Media Engine o las etiquetas de audio> HTML 5<, la aplicación se optó automáticamente por la descarga de hardware siempre y cuando se haya establecido la categoría de audio adecuada para la secuencia. La participación en la descarga de hardware se realiza por secuencia.
Las aplicaciones para UWP que usan WASAPI o las comunicaciones de streaming tienen que optar explícitamente por la descarga de hardware.
Temas relacionados
Implementación del controlador de audio descargado de hardware