processamento de áudio Hardware-Offloaded
O processamento de áudio descarregado por hardware permite que as tarefas de processamento de áudio main sejam executadas fora da CPU main do computador.
O processamento de áudio pode ser muito intensivo computacionalmente. Portanto, em muitos cenários, pode ser benéfico permitir que um processador dedicado cuide de tarefas de processamento, como, por exemplo, misturar e aplicar efeitos.
Ao implementar um driver para áudio descarregado, você desenvolve um driver capaz de processar fluxos de áudio descarregados e expor essa capacidade ao sistema de áudio do Windows.
Os tópicos a seguir nesta seção discutem o desenvolvimento do driver, o impacto do aplicativo e outros problemas que você deve estar ciente ao desenvolver um driver de áudio para um adaptador de áudio que implementa um mecanismo de áudio de hardware para lidar com fluxos de áudio descarregados.
Implementação do driver de áudio descarregado por hardware
Interfaces auxiliares para processamento de áudio descarregado
Relatório de falhas para áudio descarregado
Para obter informações sobre APOs descarregados, consulte Efeitos de APO descarregados por hardware
Visão geral da arquitetura de processamento de áudio Hardware-Offloaded
O mecanismo de áudio de software
O diagrama a seguir mostra o mecanismo de áudio de software do Windows.
Os fluxos de áudio chegam no mecanismo de áudio de software da camada WASAPI (API de sessão de áudio) do Windows e, possivelmente, por meio de uma API de nível superior, como o Media Foundation. No SFX (efeitos de fluxo do mecanismo de áudio de software), pode ser aplicado por fluxo antes que os fluxos separados sejam mistos e, em seguida, passados por quaisquer efeitos de ponto de extremidade disponíveis (EFX) e enviados para o hardware de renderização e alto-falantes.
O mecanismo de áudio de hardware
O mecanismo de áudio de hardware é implementado no adaptador de áudio e, em grande parte, espelha a funcionalidade do mecanismo de áudio de software. E embora o Windows dê suporte ao processamento de áudio descarregado por hardware, o driver de áudio de um determinado adaptador de áudio é responsável por expor os recursos subjacentes do hardware de áudio, usando a topologia mostrada no diagrama a seguir.
O mecanismo de áudio de hardware deve aceitar um único fluxo de processo de host e até n fluxos descarregados. Esses fluxos descarregados são roteados diretamente da camada do aplicativo para serem processados em hardware. Em outras palavras, os fluxos descarregados não serão passados pelo mecanismo de áudio de software. O diagrama mostra uma implementação que foi projetada para lidar com até três fluxos descarregados. O fluxo de processo do host é a saída final do mixer de software de todos os fluxos que foram processados no mecanismo de áudio de software. Cada mecanismo de áudio de hardware também deve conter um mixer de hardware.
Para manter a paridade com o mecanismo de áudio de software e a interface WASAPI, é necessário que o mecanismo de áudio de hardware forneça o fluxo de saída de áudio final de volta à pilha de áudio na forma de um fluxo de loopback. Isso é especialmente crítico para aplicativos e cenários que dependem do Cancelamento de Eco Acústico, o que requer conhecimento do fluxo de saída final para cancelar ecos e evitar comentários.
Para implementar um caminho para um fluxo de loopback, o driver de áudio é responsável por expor um pino de loopback. Esse pin retornará os dados de áudio da saída final do mecanismo de áudio, se os dados forem codificados para um formato PCM. Caso contrário, o resultado pós-mistura (mas pré-codificação) será retornado. Isso significa que, no caso de dados de áudio processados com um hardware EFX que codifica para um formato não PCM, o fluxo de loopback é obtido diretamente após o mixer de hardware, antes do estágio EFX no mecanismo de áudio de hardware. Para obter informações sobre a topologia de filtro KS que representa o mecanismo de áudio de hardware, consulte Implementação do driver de áudio descarregado por hardware.
A arquitetura de áudio integrada
O diagrama a seguir mostra uma visão geral da arquitetura resultante quando um mecanismo de áudio de hardware funciona com o mecanismo de áudio de software do Windows.
Em um cenário em que o driver de áudio indicou seu suporte para processamento de áudio descarregado, os primeiros n (nesse caso, três) fluxos inicializados serão roteados diretamente da camada WASAPI para o mecanismo de áudio de hardware, ignorando o mecanismo de áudio de software. Todos os novos fluxos de áudio subsequentes ao n com suporte do mecanismo de áudio de hardware serão roteados por meio do mecanismo de áudio de software para processamento. O fluxo resultante do mecanismo de áudio de software é então enviado para o mecanismo de áudio de hardware como um fluxo de processo de host. O fluxo de processo do host é misturado com os primeiros n fluxos, o processamento EFX é aplicado e o fluxo resultante é enviado para os alto-falantes.
A topologia de filtro KS
Em sistemas operacionais Windows 8 e posteriores, foi fornecido suporte para um mecanismo de áudio de hardware a bordo para processar fluxos de áudio. Quando você desenvolve esse adaptador de áudio, o driver de áudio associado deve expor esse fato ao sistema de áudio do modo de usuário de maneira específica, para que o sistema de áudio possa descobrir, usar e expor corretamente os recursos desse adaptador e de seu driver.
Para permitir que os drivers de áudio exponham os recursos de hardware desses novos adaptadores de áudio, Windows 8 introduziu uma topologia de filtro KS que o driver deve usar:
Conforme mostrado na figura anterior, uma topologia de filtro KS representa os caminhos de dados por meio do hardware e também mostra as funções disponíveis nesses caminhos. No caso de um adaptador de áudio que pode processar áudio descarregado, há as seguintes entradas e saídas (chamados de pinos) no filtro KS:
Um pin de Processo de Host. Isso representa a entrada no filtro KS do mecanismo de áudio de software.
Um pino loopback. Isso representa uma saída do mecanismo de áudio de hardware para a camada WASAPI (API de sessão de áudio) do Windows.
Vários pinos de áudio descarregados. Embora a figura mostre apenas um pino desse tipo, um IHV é livre para implementar qualquer número (n) de pinos.
O serviço real no sistema de áudio do modo de usuário que "leva" à descoberta do adaptador de áudio e seu driver é o AudioEndpointBuilder. O serviço AudioEndpointBuilder monitora a classe KSCATEGORY_AUDIO para chegadas e remoções da interface do dispositivo. Quando um driver de dispositivo de áudio registra uma nova instância da classe de interface do dispositivo KSCATEGORY_AUDIO , uma notificação de chegada da interface do dispositivo é acionada. O serviço AudioEndpointBuilder detecta a notificação de chegada da interface do dispositivo e usa um algoritmo para examinar a topologia dos dispositivos de áudio no sistema para que ele possa tomar as medidas apropriadas.
Quando você desenvolve o driver de áudio para dar suporte a um adaptador capaz de processar áudio descarregado, o driver deve usar o ponto de extremidade de áudio KSNODETYPE_AUDIO_ENGINE para expor os recursos do mecanismo de áudio de hardware. Para obter mais informações sobre o processo de descoberta de ponto de extremidade de áudio, consulte Algoritmo do Construtor de Ponto de Extremidade de Áudio.
Considerações sobre a interface do usuário
Você desenvolveu o driver de áudio para controlar os recursos de hardware subjacentes de um adaptador de áudio capaz de processar o áudio descarregado. Isso significa que o driver tem o melhor conhecimento sobre como controlar os recursos do adaptador. Portanto, você deve desenvolver uma interface do usuário que exponha os recursos do adaptador ao usuário final na forma de opções que ele pode selecionar, habilitar e/ou desabilitar.
No entanto, se você já tiver uma interface do usuário usada para controlar APOs (objetos de processamento de áudio) que você desenvolveu, essa interface do usuário poderá ser estendida para funcionar com seu novo adaptador de áudio. Nesse caso, suas extensões para a interface do usuário forneceriam controle de software para as APOs e controle de hardware para o adaptador.
Impacto do aplicativo
A funcionalidade descrita para esse novo tipo de adaptador de áudio e seu driver associado pode ser usada por aplicativos UWP por meio de WASAPI, Media Foundation, Media Engine ou as marcas de áudio> HTML 5<. Observe que Wave e DSound não podem ser usados, pois não estão disponíveis para aplicativos UWP. Observe também que os aplicativos de área de trabalho não podem usar os recursos de descarregamento de adaptadores de áudio que dão suporte a áudio descarregado por hardware. Esses aplicativos ainda podem renderizar áudio, mas somente por meio do pino de host que usa o mecanismo de áudio de software.
Se um aplicativo UWP transmitir conteúdo de mídia e usar Media Foundation, Media Engine ou as marcas de áudio> HTML 5<, o aplicativo será automaticamente aceito para descarregamento de hardware, desde que a categoria de áudio adequada tenha sido definida para o fluxo. A aceitação do descarregamento de hardware é feita por fluxo.
Aplicativos UWP que usam WASAPI ou comunicações de streaming precisam aceitar explicitamente o descarregamento de hardware.
Tópicos relacionados
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de