Compartilhar via

Combinar APOs personalizados e do Windows

  • Artigo

ApOs (objetos de processamento de áudio), fornecem processamento de sinal digital baseado em software personalizável para fluxos de áudio do Windows. É possível combinar APOs fornecidas pela Microsoft, com código desenvolvido pelo parceiro, encapsulando e personalizando a funcionalidade existente.

Consulte estes tópicos para obter informações gerais sobre APOs.

As APOs foram introduzidas pela primeira vez no Windows Vista e você pode ver referências às APOs do sistema anteriores – sAPOs. Para obter mais informações, consulte o white paper Efeitos de áudio personalizados no Windows Vista . Este white paper pode fazer referência a tópicos mais antigos de desenvolvimento com e interface do usuário.

Como combinar APOs personalizados e do Windows

Esta seção contém diretrizes para implementar APOs de efeitos personalizados do sistema de áudio, criando um wrapper fino em torno do APO correspondente. Personalizado O APO refere-se à implementação do APO do IHV.

Há dois tipos de APOs, SFX (Stream) e MFX (Modo). Em Windows 8.1, o SFX era conhecido como LFX (local) e o MFX era referenciado como APOs GFX (global).

Os IHVs podem implementar APOs de efeitos personalizados do sistema de áudio para substituir as APOs do sistema de áudio personalizado SFX e MFX do Windows. Em termos gerais, IHVs ou OEMs têm duas estratégias básicas para combinar APOs de efeitos personalizados do sistema de áudio com as APOs que o Windows fornece. Essas estratégias dão aos IHVs flexibilidade sobre como integram seus efeitos personalizados aos do Windows.

Substituir

Desenvolva uma compreensão detalhada do APO do Windows que você deseja substituir e seus recursos. Use essa compreensão para implementar um APO personalizado que chama o APO do Windows de uma maneira que faça mais sentido para o IHV da perspectiva de sua experiência de usuário de destino. Essa estratégia é mais adequada para IHVs ou OEMs que desejam:

  • Integre perfeitamente seus efeitos personalizados aos efeitos do Windows.
  • Implemente sua própria interface do usuário para controlar seus efeitos e os efeitos implementados pelas APOs do Windows.

Para obter mais informações sobre como escrever um APO, consulte Objetos de processamento de áudio do Windows.

Wrapper fino

Escreva o APO personalizado como um wrapper fino ao redor do APO do Windows. Essa estratégia é mais adequada para IHVs ou OEMs que desejam:

  • Adicione seus efeitos personalizados da maneira mais simples possível.
  • Fazer com que a interface do usuário do Windows continue a controlar os efeitos.

IHV ou OEMs que escolhem Estratégia a opção de wrapper fino, ainda devem examinar os Objetos de Processamento de Áudio do Windows para obter uma compreensão completa dos efeitos do sistema de áudio personalizado do Windows.

Observação: com a estratégia de wrapper fino, os IHVs não podem adicionar interface do usuário para controlar os efeitos do sistema de áudio personalizado adicionados à guia Aprimoramentos do Windows. Há apenas uma guia Aprimoramentos e ela deve permanecer associada à página de propriedades para as APOs do Windows. A interface do usuário do IHV deve ser implementada de alguma outra forma, como um aplicativo Painel de Controle separado.

Informações de programação

Esta seção aborda os problemas gerais de programação que devem ser resolvidos para implementar apOs personalizados.

As APOs de efeitos do sistema de áudio personalizado SFX(Stream) e MFX(Mode) têm as seguintes características gerais:

  • Eles devem ser registrados como objetos de servidor em processo COM que podem ser instanciados usando CoCreateInstance.
  • Os CLSIDs são CLSID_CWMAudioLFXAPO e CLSID_CWMAudioGFXAPOpara as APOs SFX e MFX, respectivamente. Os CLSIDs são declarados em wmcodecdsp.h e definidos em wmcodecdspuuid.lib.
  • Eles devem dar suporte à agregação COM. No entanto, não se espera que a agregação seja usada no cenário de efeitos personalizados do sistema de áudio, portanto, não deve apresentar problemas significativos.

Inicialização

Um APO personalizado deve inicializar o APO da Janela chamando seu método IAudioSystemEffects::Initialize . Normalmente, isso é feito a partir do método Initialize do APO personalizado. Todos os argumentos passados para o método Initialize do APO personalizado devem ser passados diretamente para Inicializar do APO do Windows. Isso permite que o APO busque suas configurações do ponto de extremidade e dos repositórios de propriedades Fx na estrutura APOInitSystemEffects. É possível fazer com que o APO personalizado busque as configurações e as passe seletivamente para o APO, mas isso é essencialmente a Estratégia A.

Se o APO personalizado substituir um recurso, geralmente é aconselhável desativar o recurso correspondente no APO. No entanto, desativar o recurso pode não ser estritamente necessário, dependendo de como o recurso funciona. Para desativar um recurso, consulte o APO para sua interface IPropertyStore e chame IPropertyStore::SetValue. As propriedades compatíveis com o repositório de propriedades do APO são descritas em "Propriedades IPropertyStore com suporte". Mais adiante neste tópico.

Para obter exemplos de como se comunicar com o repositório de propriedades do APO de efeitos do sistema de áudio personalizado do Windows, consulte os exemplos no GitHub em: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Consultar o estado do recurso do APO

Se um APO personalizado apenas substituir um recurso de efeitos de áudio do Windows e não tiver sua própria interface do usuário de configuração ou repositório de configurações, talvez seja necessário determinar quais recursos estão habilitados no APO correspondente.

Há pelo menos duas maneiras de obter essas informações:

  • Opção A: consultando diretamente o repositório de propriedades Fx.

  • Opção B: indiretamente, instanciando o APO e usando sua interface IPropertyStore para consultar o repositório de propriedades.

Opção A

Essa opção tem a vantagem de que ela pode ser feita sem instanciar um APO. Além disso, se um APO personalizado quiser monitorar o repositório de propriedades Fx, a Opção A será a única maneira de receber notificações de alteração de propriedade em tempo real. Para obter um exemplo da Opção A, consulte o exemplo "compactar".

Com a Opção A, o APO personalizado consulta o main repositório de propriedades do ponto de extremidade, não Fx, para PKEY_AudioEngine_DeviceFormat. Em seguida, ele usa a máscara de canal desse formato como o PID para a chave de propriedade usada para consultar o repositório de propriedades Fx. O GUID (fmtid) para a chave de propriedade usada para consultar o repositório de propriedades Fx é um dos valores de XXX_XXX_KEY_GUID de wmcodecdsp.h. Os nomes de KEY_GUID correspondem de maneiras óbvias aos nomes MFPKEY que foram discutidos anteriormente neste tópico.

Opção B

Essa opção tem a vantagem de que pode lidar corretamente com a possibilidade de que o APO do Windows possa eventualmente ter alguns de seus recursos habilitados por padrão se a propriedade correspondente no repositório de propriedades Fx não existir.

Com a Opção B, o APO personalizado simplesmente consulta o APO para sua interface IPropertyStore e chama IPropertyStore::GetValue usando uma das chaves de MFPKEY_XXX que foram discutidas anteriormente neste tópico.

Formatar negociação

Ao implementar um APO SFX personalizado que encapsula o APO do SFX, não especifique APO_FLAG_FRAMESPERSECOND_MUST_MATCH nas propriedades de registro do APO personalizado. Essa regra deve ser seguida se o APO personalizado pode ou não alterar o formato do canal. Se o APO SFX personalizado especificasse esse sinalizador, isso impediria que o SFX correspondente fizesse preenchimento de alto-falante, virtualização de fone de ouvido ou surround virtual.

Uma implementação personalizada do APO do SFX deve implementar ou substituir IAudioProcessingObject::IsInputFormatSupported. É improvável que a implementação isInputFormatSupported da classe base reflita com precisão o conjunto de conversões de canal possíveis que foram implementadas pelo APO SFX personalizado e pelo APO do SFX.

O método IsInputFormatSupported do SFX APO personalizado deve chamar IsInputFormatSupported do APO correspondente. Isso garante que o APO do SFX manipule todas as conversões de canal que não são tratadas pelo APO SFX personalizado. Observe que o APO do SFX pode ser atualizado para dar suporte a mais conversões em versões futuras do Windows. Chamar o método IsInputFormatSupported do APO é uma maneira de garantir que o conjunto de conversões de canal com suporte pelo APO personalizado contenha completamente o conjunto de conversões de canal com suporte do APO SFX.

O que o APO personalizado deve fazer com o valor retornado do método IsInputFormatSupported do SFX APO depende de quais conversões de canal, se houver, o APO SFX personalizado dá suporte.

Se o SFX APO personalizado não der suporte a nenhuma de suas próprias conversões de canal, seu método IsInputFormatSupported poderá retornar o valor retornado pelo método IsInputFormatSupported do APO do SFX diretamente para o chamador. Para obter um exemplo, consulte os exemplos de "trocar" e "compactar".

Se o SFX APO personalizado der suporte a suas próprias conversões de canal, um valor de retorno negativo, incluindo S_FALSE, do método IsInputFormatSupported do APO do SFX não necessariamente se traduzirá em um valor de retorno negativo para o chamador. O APO SFX personalizado poderia, por exemplo, dar suporte a conversões de canal que não são compatíveis com o APO correspondente. Nesse caso, o APO SFX personalizado deve combinar o valor retornado do método IsInputFormatSupported do APO do SFX com sua própria lógica para determinar entradas com suporte. Observe que o significado ideal de "combinar" depende de qual tipo de conversão de canal deve ter precedência. A melhor abordagem depende do design exato da implementação personalizada.

O método IsOutputFormatSupported em um APO SFX não é interessante porque o formato de saída de um APO SFX é o formato de combinação do dispositivo. Esse formato é baseado em considerações externas e não pode ser afetado por um APO SFX ou seu formato de entrada. Por esse motivo, os exemplos não tentam implementar a lógica correta para IsOutputFormatSupported.

As considerações acima não se aplicam a APOs MFX porque o APO do MFX não implementa nenhum recurso que exija ou indique a alteração do formato do canal. Por esse motivo, a amostra MFX não faz nada especial para IsInputFormatSupported ou IsOutputFormatSupported. A lógica de negociação de formato de um APO MFX personalizado não é afetada pelo fato de que ele está encapsulando o APO do MFX.

LockForProcess/UnlockForProcess

O método IAudioProcessingObjectConfiguration::LockForProcess do APO personalizado deve chamar o método correspondente no APO. LockForProcess() é um bom lugar para tomar decisões sobre a ordem em que as várias fases de processamento devem ocorrer. Por exemplo, ele pode decidir se deve aplicar o processamento personalizado do APO ou o processamento do APO primeiro. Todos os três exemplos fornecem exemplos dessa lógica de decisão e os comentários nos exemplos fornecem alguns planos de fundo. No entanto, é impossível fornecer diretrizes completamente gerais sobre esse assunto neste documento porque exigiria conhecimento dos recursos específicos do APO personalizado e como eles poderiam interagir com os recursos de APOs.

GetLatency

A implementação IAudioProcessingObject::GetLatency do APO personalizada deve chamar GetLatency no APO que está sendo encapsulado. Se o processamento personalizado do APO gerar latência, ele deverá adicioná-lo ao resultado que foi retornado pelo APO antes de retornar o valor ao chamador.

APOProcess

O método IAudioProcessingObjectRT::APOProcess do APO personalizado deve chamar o método APOProcess do APO antes, depois ou mesmo durante o processamento. A decisão sobre quando chamar o APOProcess deve ser tomada no LockForProcess, para que todos os buffers intermediários necessários possam ser alocados. As APOs dão suporte ao processamento in-loco sempre que os formatos de entrada e saída forem idênticos. Nesse caso, o APO personalizado pode passar o mesmo APO_CONNECTION_PROPERTY que a propriedade de conexão de entrada e saída para o APO do Windows. No entanto, o APO personalizado não deve usar a propriedade de conexão de entrada do APO personalizado como a propriedade de conexão de saída para o APO. Em geral, as APOs não devem modificar o buffer de entrada.

Tratamento de erros de APO

Se um APO retornar um erro para o APO personalizado correspondente, o APO personalizado deverá agir desse ponto em diante como se não houvesse nenhum APO. Os exemplos tratam todos os erros do APO como equivalentes à falha de CoCreateInstance ao criar o APO. Opcionalmente, o APO personalizado pode limitar o efeito de erros do método LockForProcess do APO para a sessão atual. Em outras palavras, o APO personalizado não usa o APO durante chamadas subsequentes para seu método APOProcess. No entanto, o APO personalizado poderá tentar usar o APO novamente se houver outra chamada LockForProcess posteriormente, com formatos diferentes.

Compilação e vinculação

Para usar o CLSID do APO e as definições de chave de propriedade, inclua wmcodecdsp.h e vincule com wmcodecdspuuid.lib. Para obter mais informações, consulte cabeçalho wmcodecdsp.h.

Exemplos de APO

Há quatro exemplos de exemplos de efeitos do sistema de áudio. Os exemplos do APO estão disponíveis no GitHub em: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Diretrizes gerais para efeitos personalizados do sistema de áudio

Veja a seguir algumas diretrizes que os IHVs devem seguir ao implementar APOs de efeitos personalizados do sistema de áudio.

  • Todos os efeitos do sistema de áudio devem fornecer opções de ativação/desativação. Os usuários não devem ser forçados a usar um efeito do sistema de áudio.
  • As interações entre os recursos no SFX e no APO do MFX devem ser mediadas pelas APOs e pela interface do usuário relacionada.
  • Os recursos especificados como SFX ou MFX aqui podem ser movidos entre SFX e MFX em implementações personalizadas. No entanto, isso deve ser feito com o entendimento de que as opções de ativação/desativação devem existir e que a acessibilidade e a adequação das opções não devem ser comprometidas.
  • Os implementadores devem lembrar que o SFX pode ter máscaras de canal de entrada e saída diferentes. O APO do MFX deve ter as mesmas máscaras de canal de entrada e saída.

APOs fornecidos pelo Windows

Para obter informações sobre as outras APOs fornecidas pelo Windows, consulte estes tópicos.

Bass Boost

Gerenciamento de baixo

Som aprimorado para computadores laptop

DSP de equalização de intensidade

Proteção de baixa frequência

Correção de Sala

Preenchimento do Alto-Falante

Viva-voz Fantasma

Virtual Surround

Som surround virtualizado sobre fones de ouvido

Informações específicas de personalização do APO

Equalização de intensidade (APO SFX)

A equalização de intensidade é um processamento compactado (dinâmica) que é impulsionado por uma métrica de intensidade perceptiva. Correção de sala (APO MFX)

A correção de sala usa um perfil gerado pelo Assistente de Calibragem de Sala. Esse perfil é armazenado como um blob binário. O formato do blob não está publicado no momento.

Conversão de canal (APO SFX)

O APO de Conversão de Canal lida com várias tarefas.

Virtualização de fone de ouvido

Esse efeito será habilitado se o formato do canal do conteúdo que está sendo reproduzido (N.x) for 2.0 ou maior, em que x pode ser 0 ou 1. A máscara de saída deve ser estéreo (0x3). A máscara de entrada é limitada a algumas combinações com suporte, que estão listadas na tabela abaixo

Máscaras de Canal de Virtualização de Fone de Ouvido

Nome Valor
MASK_STEREO MASK_FRONTLR 0x3
MASK_3_FRONT (SPEAKER_FRONT_CENTER | MASK_FRONTLR) 0x7
MASK_4_SQUARE (MASK_FRONTLR | MASK_BACKLR) 0x33
MASK_4_DIAMOND (MASK_FRONTLR | MASK_FBCENTERS) 0x107
MASK_5_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER) 0x3F
MASK_5_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER) 0x60F

Virtual Surround

Esse efeito também é chamado de codificação de matriz esquerda /direita (LTRT) ou esquerda/direita. Ele será usado se o formato de canal do conteúdo que está sendo reproduzido (N.x) for 2.0 ou maior, em que x pode ser 0 ou 1. A dobragem LTRT normalmente é de 4,0 a 2,0. Qualquer outro formato de entrada geralmente é manipulado aplicando primeiro N.x a 4.0 folddown genérico. No entanto, em nossa implementação, a dobragem LTRT é nativamente de 5.1 a 2.0. Qualquer outra entrada é manipulada pela primeira vez aplicando N.x a 5.1 folddown genérico primeiro.

A máscara de canal de saída deve ser 0x3 (estéreo) e o número de canais de entrada, incluindo o subwoofer, se presente, não deve ter mais de oito.

Preenchimento do Alto-Falante

Esse efeito é usado quando o número de canais de entrada (N) é menor que o número de canais de saída (M). O efeito preenche o canal N.x para canais M.x, em que x pode ser 0 ou 1.

As máscaras de canal na Tabela 4, ignorando o canal LFE, têm suporte para preenchimento de alto-falante. O preenchimento do alto-falante dá suporte a qualquer combinação de presença de canal subwoofer de entrada ou saída, portanto, os números à esquerda são apenas exemplos. As configurações reais podem ou não ter um subwoofer.

Máscaras de Canal de Preenchimento do Alto-Falante

Nome Valor
MASK_STEREO MASK_FRONTLR 0x3
MASK_3_FRONT (SPEAKER_FRONT_CENTER | MASK_FRONTLR) 0x7
MASK_4_SQUARE (MASK_FRONTLR | MASK_BACKLR) \ 0x33
MASK_4_DIAMOND (MASK_FRONTLR | MASK_FBCENTERS) 0x107
MASK_5_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER) 0x3F
MASK_5_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER) 0x60F
MASK_7_SIDE_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER | MASK_SIDELR) 0x63F
MASK_7_FRONT_SIDE (MASK_FRONTLR | MASK_SIDELR | SPEAKER_FRONT_CENTER | MASK_CENTERLR) 0x6CF
MASK_7_FRONT_BACK (MASK_FRONTLR | MASK_BACKLR | SPEAKER_FRONT_CENTER | MASK_CENTERLR) 0xFF

O preenchimento do alto-falante não terá suporte se qualquer um dos seguintes itens for verdadeiro:

  • A máscara de entrada é igual à máscara de saída.
  • A única diferença entre entrada e saída é que um tem canais laterais esquerdo/direito; o outro tem canais para a esquerda/direita.
  • A entrada tem mais canais main do que a saída.
  • A máscara de saída inclui os alto-falantes central esquerdo/direito, mas a máscara de entrada não.
  • O conjunto de canais na saída, mas não na entrada, não inclui pelo menos um dos seguintes: front center, back left/right ou side left/right.

Há uma exceção para o segundo item na lista. Se a única diferença entre entrada e saída for que um tem canais laterais esquerdo/direito e o outro tem canais esquerdo/direito, o preenchimento do alto-falante terá suporte se qualquer um dos formatos contiver canais que ficariam entre sideLR e backLR na ordem de bits da máscara de canal. Há três desses canais:

  • SPEAKER_FRONT_LEFT_OF_CENTER
  • SPEAKER_FRONT_RIGHT_OF_CENTER
  • SPEAKER_BACK_CENTER

Se a máscara de entrada ou saída contiver qualquer um desses três canais, o preenchimento do alto-falante poderá ter suporte, mesmo que não atenda à segunda condição na lista, mas somente se as outras condições forem atendidas. Por exemplo, o preenchimento do alto-falante de MASK_7_FRONT_BACK de ou para MASK_7_FRONT_SIDE é compatível com o preenchimento do alto-falante por esse motivo.

A tabela a seguir tem a lista completa de valores de canal.

Nome Valor
SPEAKER_FRONT_LEFT 0x1
SPEAKER_FRONT_RIGHT 0x2
SPEAKER_FRONT_CENTER 0x4
SPEAKER_LOW_FREQUENCY 0x8
SPEAKER_BACK_LEFT 0x10
SPEAKER_BACK_RIGHT 0x20
SPEAKER_FRONT_LEFT_OF_CENTER 0x40
SPEAKER_FRONT_RIGHT_OF_CENTER 0x80
SPEAKER_BACK_CENTER 0x100
SPEAKER_SIDE_LEFT 0x200
SPEAKER_SIDE_RIGHT 0x400

Os atrasos são usados para canais nas configurações de saída que estão "fora" do intervalo de front-back na configuração de entrada. Por outro lado, se um alto-falante na configuração de saída estiver "entre" alguns alto-falantes na configuração de entrada no sentido front-back, a saída para esse alto-falante será gerada misturando alguns dos canais de entrada em ambos os lados do canal de saída.

considerações sobre Run-Time ao reutilização de APOs do Windows

Esta seção contém algumas informações adicionais que IHVs e OEMs podem achar úteis ao implementar seus efeitos personalizados do sistema de áudio.

Uma implementação de APO personalizada:

  • Usa CoCreateInstance para instanciar uma ou mais instâncias das APOs de efeitos do sistema de áudio personalizado do Windows.
  • Configura cada instância para habilitar o conjunto de recursos desejado.
  • Insere cada instância em um local apropriado dentro do pipeline interno do APO personalizado.

Por que uma ou mais instâncias?

Para evitar interações indesejáveis, a maioria dos recursos exige uma determinada ordenação relativa. Como as APOs do Windows implementam vários recursos dentro de um único APO, várias instâncias desse APO podem ser necessárias para garantir a ordenação correta. Por exemplo, suponha que três recursos habilitados — A, B e C — devem ser ordenados abc. A implementação personalizada manipula B, mas delega A e C ao APO do Windows. A e C devem estar em instâncias separadas do Microsoft APO para que a implementação personalizada de B possa ocorrer entre elas.

O Windows implementa a correção de sala no APO do MFX, o que significa que ele é um objeto COM separado do APO SFX. Uma implementação personalizada pode optar por delegar a correção de sala para a implementação do Windows, mas colocá-la em um APO SFX personalizado. A implementação personalizada do SFX pode precisar delegar algum processamento para a implementação do APO do SFX do Windows e outro processamento para a implementação do APO do Windows MFX.

Manipulando as limitações de combinação de formato de entrada/saída diferente

Muitos recursos, especialmente o gerenciamento de baixos, não funcionam em determinados casos. Por exemplo, o gerenciamento de baixo para frente será indefinido se a propriedade de configuração do alto-falante baixo for "AllSmall" ou "AllLarge" e o formato de saída não incluir um canal de subwoofer ou o sinalizador NoSub estiver definido. Nem sempre é possível detectar a falha durante a chamada IPropertyStore::SetValue . O método tenta habilitar o recurso, mas os formatos de entrada e saída não são conhecidos no momento porque LockForProcess deve ocorrer após todas as manipulações de propriedade. Isso significa que é possível habilitar um recurso, vê-lo aparentemente bem-sucedido, mas não fazer com que o processamento correspondente ocorra.

Duas estratégias estão disponíveis para lidar com essas situações:

  • Estude cuidadosamente as seções específicas do recurso deste documento para poder prever exatamente quando um determinado recurso terá ou não êxito.
  • Chame IPropertyStore::GetValue depois que LockForProcess for chamado para marcar o estado das propriedades importantes.

Quando LockForProcess determina que um recurso específico não pode ser habilitado devido aos formatos de entrada e saída ou ao valor de alguma outra propriedade, LockForProcess atualiza o valor da propriedade correspondente no repositório de propriedades.

Interação entre o Preenchimento do Locutor e o Gerenciamento de Baixo

Quando o preenchimento do alto-falante está ativado e um subwoofer está conectado, o gerenciamento de baixo avançado deve ocorrer antes do preenchimento do alto-falante para evitar a filtragem de pente do sinal de baixa frequência pelo atraso de surround do preenchimento do alto-falante.

Quando o preenchimento do alto-falante está habilitado e nenhum subwoofer está conectado, dois tipos de gerenciamento de baixo avançado são possíveis:

  • Se os alto-falantes frontal esquerdo/direito forem grandes, o gerenciamento de baixos para frente roteará a parte de baixa frequência dos canais surround e central para os alto-falantes frontal esquerdo/direito. O gerenciamento de baixo avançado deve vir após o preenchimento do alto-falante nesse caso.
  • Se todos os alto-falantes forem pequenos, o gerenciamento de graves avançados se tornará uma proteção de baixa frequência para todos os alto-falantes main.

Isso pode ocorrer antes ou depois do preenchimento do alto-falante. No entanto, por motivos de desempenho, é melhor ter gerenciamento de baixo avançado antes do preenchimento do alto-falante.

O APO do Windows implementa determinadas configurações comuns de preenchimento de alto-falante, como 2.0 => 5.1, com código otimizado especial que manipula o gerenciamento de baixo reverso na mesma etapa que o preenchimento do alto-falante.

Interação entre o Folddown e o Gerenciamento de Baixo

A virtualização de fone de ouvido dá suporte apenas ao gerenciamento de baixo reverso:

  • O gerenciamento de baixo avançado não faz sentido com a virtualização do fone de ouvido.
  • Para simplificar a implementação, não há suporte para proteção de baixa frequência e aumento de baixo.

Quando qualquer virtualização de fone de ouvido, codificação virtual surround ou efeitos de preenchimento do alto-falante estão ativados, o gerenciamento de baixo reverso é tratado durante essa etapa. O gerenciamento de baixo reverso ainda é controlado por meio da propriedade de gerenciamento de baixo reverso de APOs como se fosse um recurso separado. Nesses casos, o gerenciamento de baixo reverso simplesmente controla os coeficientes do folddown para o canal de entrada .1. Um problema aberto é que o gerenciamento de baixo reverso não pode ser desabilitado quando o LTRT está ativado. Nesse caso, o gerenciamento de baixo reverso usa um ganho de canal subwoofer não convencional.

As APOs de efeitos do sistema de áudio do Windows aplicam algum processamento secundário — ganho e atraso — mesmo quando nenhum recurso está habilitado. O objetivo desse processamento é garantir que os parâmetros de ganho e atraso não sejam alterados quando um recurso estiver habilitado em tempo real. O motivo é que o atraso é inerente à implementação de alguns recursos e um ganho <1 é aplicado por alguns recursos para evitar uma saída excessivamente alta em determinadas situações. O conjunto de recursos disponíveis depende dos formatos de entrada-saída e de determinadas propriedades, assim como o ganho e o atraso da normalização cumulativa.

Se os recursos não forem ativados ou desativados em tempo real, o ganho de normalização poderá ser desabilitado definindo a MFPKEY_CORR_NORMALIZATION_GAIN propriedade como FALSE chamando IPropertyStore::SetValue. A propriedade pode ser TRUE por padrão.

Não há mecanismo para desabilitar o atraso de normalização porque é presumidamente menos provável que seja desagradável do que o ganho de normalização. Se o atraso de normalização for indisponível, basta ignorar o APO em questão.

Confira também