Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 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 los APOs descentralizados, consulte Efectos de APO descentralizados de hardware.
Introducción a la arquitectura de procesamiento de audio de Hardware-Offloaded
El motor de audio del 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 API de sesión de audio de Windows (WASAPI) y, posiblemente, a través de una API de nivel superior, como Media Foundation. En el motor de audio de software, los efectos de secuencia (SFX) pueden aplicarse individualmente a cada secuencia antes de mezclar las secuencias independientes. Después, pasan a través de cualquier efecto de salida disponible (EFX) y son enviados al hardware de salida y a los altavoces para su reproducción.
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. Aunque Windows admite el procesamiento de audio descargado por hardware, el controlador de audio para 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 única secuencia de proceso de host y hasta n secuencias externalizadas. Estos flujos descargados se enrutan directamente desde la capa de aplicación para ser procesados en hardware. En otras palabras, las secuencias descargadas no se pasarán a través del motor de audio de software. El diagrama 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 que se procesaron 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 devuelva el flujo de audio final a la pila de audio en forma de flujo de retorno. Esto es especialmente crítico para las aplicaciones y escenarios que se basan en la cancelación de eco acústico, lo que requiere conocimiento del flujo de salida final para cancelar los ecos y evitar comentarios.
Para implementar una ruta para un stream de bucle invertido, el controlador de audio es responsable de mostrar 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 después de la mezcla (pero antes de la codificación). 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, el flujo de retroalimentación se toma directamente después del mezclador de hardware, antes de la fase EFX en el motor de audio del hardware. Para obtener información sobre la topología del filtro KS que representa el motor de audio de hardware, consulte Implementación del controlador de audio desplazado por hardware.
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 fuera de línea, las primeras n (en este caso, tres) secuencias que se inicializan serán enrutadas directamente desde la capa WASAPI al motor de audio de hardware, pasando por alto 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. El flujo resultante del motor de audio de software se envía al motor de audio de hardware como un flujo de proceso del host. El flujo 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 los sistemas operativos Windows 8 y versiones 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, de modo 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 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:
Un pin de proceso de host. Esto representa la entrada en el filtro KS del motor de audio de software.
Un pin de bucle de retorno. 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 pines de audio descargados. Aunque la ilustración muestra solo un pin de este tipo, un IHV es libre de implementar cualquier número (n) de pins.
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 clase de interfaz de dispositivo KSCATEGORY_AUDIO , se desencadena una notificación de llegada de 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 el Algoritmo del Constructor de Puntos de Conexión de Audio.
Consideraciones sobre la interfaz de usuario
Ha desarrollado el controlador de audio para controlar las funcionalidades de hardware subyacentes de un adaptador de audio que es capaz de procesar audio descargado. Esto significa que el controlador tiene el mejor conocimiento sobre cómo controlar las características del adaptador. Por lo tanto, debe desarrollar una interfaz de usuario que exponga 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 se puede ampliar para trabajar con el nuevo adaptador de audio. En este caso, las extensiones a 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
La funcionalidad descrita para este nuevo tipo de adaptador de audio y su controlador asociado, se puede usar en aplicaciones para UWP 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 <audio> HTML 5, la aplicación se suscribe automáticamente a la descarga en hardware siempre que se haya configurado 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