Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O processamento de áudio descarregado de hardware permite que as principais tarefas de processamento de áudio sejam executadas fora da CPU principal do computador.
O processamento de áudio pode ser muito intensivo computacionalmente. Assim, 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 que é 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 de drivers, o impacto da aplicação e outras questões das quais deve estar ciente ao desenvolver um driver de áudio para um adaptador de áudio que implementa um motor de áudio de hardware para gerir fluxos de áudio descarregados.
Implementação de driver de áudio descarregado de 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 de hardware
Visão geral da arquitetura de processamento de áudio Hardware-Offloaded
O motor de áudio do software
O diagrama a seguir mostra o mecanismo de áudio do software Windows.
Os fluxos de áudio chegam ao mecanismo de áudio do software a partir 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 software, os efeitos de fluxo do motor de áudio (SFX) podem ser aplicados em uma base de fluxo por fluxo antes de que sejam misturados os fluxos separados, e, em seguida, passados por quaisquer efeitos de ponto final disponíveis (EFX) e enviados para o hardware responsável pela renderização e os alto-falantes.
O mecanismo de áudio de hardware
O mecanismo de áudio de hardware é implementado no adaptador de áudio e espelha em grande parte a funcionalidade do mecanismo de áudio do software. E embora o Windows ofereça suporte ao processamento de áudio descarregado de hardware, o driver de áudio para 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 de aplicativo para serem processados no hardware. Em outras palavras, os fluxos transferidos não serão processados pelo motor de áudio do 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 do software. Cada mecanismo de áudio de hardware também deve conter um mixer de hardware.
A fim de manter a paridade com o motor de áudio de software e a interface WASAPI, é necessário que o motor de áudio de hardware forneça o fluxo de saída de áudio final de volta para a 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, que requer conhecimento do fluxo de saída final para cancelar ecos e evitar feedback.
Para implementar um caminho para um fluxo de loopback, o driver de áudio é responsável por expor um pino de loopback. Esse pino 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, será retornado o resultado após a mistura, mas antes da codificação. Isso significa que, no caso de dados de áudio processados com um EFX de hardware 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 motor de áudio de hardware, consulte Implementação do driver de áudio com descarga de 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 onde o driver de áudio indicou seu suporte para processamento de áudio descarregado, os primeiros n (neste caso, três) fluxos que são inicializados serão roteados diretamente da camada WASAPI para o mecanismo de áudio de hardware, ignorando o mecanismo de áudio do software. Quaisquer novos fluxos de áudio subsequentes ao n suportado pelo mecanismo de áudio de hardware serão encaminhados pelo mecanismo de áudio de software para processamento. O fluxo resultante do mecanismo de áudio do software é então enviado para o mecanismo de áudio do hardware como um fluxo de processo do 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 do filtro KS
No Windows 8 e sistemas operacionais posteriores, foi fornecido suporte para um mecanismo de áudio de hardware integrado para processar fluxos de áudio. Quando você desenvolve tal adaptador de áudio, o driver de áudio associado deve expor esse fato para o sistema de áudio de modo de usuário de uma maneira específica, para que o sistema de áudio possa descobrir, usar e expor corretamente os recursos desse adaptador e seu driver.
Para possibilitar que os drivers de áudio exponham os recursos de hardware desses novos adaptadores de áudio, o Windows 8 introduziu uma topologia de filtro KS que o driver deve usar:
Como mostrado na figura anterior, uma topologia de filtro KS representa os caminhos de dados através do hardware e também mostra as funções que estão disponíveis nesses caminhos. No caso de um adaptador de áudio que pode processar áudio descarregado, existem as seguintes entradas e saídas (chamadas pinos) no filtro KS:
Um pino do Processo de Host. Isso representa a entrada no filtro KS do mecanismo de áudio do software.
Um pino de 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 efetivo no sistema de áudio em modo usuário que "leva" à descoberta do adaptador de áudio e do respetivo 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 regista uma nova instância da classe de interface de dispositivo KSCATEGORY_AUDIO, uma notificação de chegada da interface de dispositivo é acionada. O serviço AudioEndpointBuilder deteta 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 desenvolve o driver de áudio para suportar um adaptador capaz de processar áudio descarregado, o driver deve utilizar o endpoint de áudio KSNODETYPE_AUDIO_ENGINE para expor as capacidades do mecanismo de áudio de hardware. Para obter mais informações sobre o processo de descoberta de dispositivos de saída de áudio, consulte Algoritmo do Criador de Pontos de Extremidade de Áudio.
Considerações sobre a interface do usuário
Você desenvolveu seu driver de áudio para controlar os recursos de hardware subjacentes de um adaptador de áudio que é capaz de processar áudio descarregado. Isso significa que seu 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 que é usada para controlar objetos de processamento de áudio (APOs) que você desenvolveu, essa interface do usuário pode 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 os APOs e controle de hardware para o adaptador.
Impacto do aplicativo
A funcionalidade descrita para este novo tipo de adaptador de áudio e seu driver associado pode ser usada por aplicações UWP via WASAPI, Media Foundation, Media Engine ou pelas tags de áudio HTML 5 <audio>. Observe que o Wave e o 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 suportam áudio descarregado de hardware. Esses aplicativos ainda podem renderizar áudio, mas apenas através do pino do host que faz uso do mecanismo de áudio do software.
Se uma aplicação UWP transmitir conteúdo de mídia e utilizar o Media Foundation, o Media Engine ou as tags de áudio HTML 5, a aplicação será automaticamente elegível para descarregamento de hardware, contanto que a categoria de áudio adequada tenha sido definida para o fluxo. A opção pelo descarregamento de hardware é feita individualmente para cada fluxo.
Os aplicativos UWP que usam WASAPI ou comunicações de streaming precisam aceitar explicitamente o descarregamento de hardware.