Combinación de API personalizadas y de Windows

  • Artículo

Los objetos de procesamiento de audio (API), proporcionan procesamiento de señal digital basado en software personalizable para secuencias de audio de Windows. Es posible combinar las API proporcionadas por Microsoft, con código desarrollado por asociados, encapsular y personalizar la funcionalidad existente.

Consulte estos temas para obtener información general sobre las API.

Las API se introdujeron por primera vez en Windows Vista y es posible que vea referencias a las API del sistema anteriores: sAPOs. Para obtener más información, consulta las notas del producto Efectos de audio personalizados en Windows Vista . Este documento técnico puede hacer referencia a temas de desarrollo de INTERFAZ de usuario y COM más antiguos .

Cómo combinar las API personalizadas y de Windows

Esta sección contiene instrucciones para implementar las API de efectos del sistema de audio personalizados mediante la creación de un contenedor fino alrededor del APO correspondiente. Personalizado APO hace referencia a la implementación de IHV del APO.

Hay dos tipos de API, SFX (Stream) y MFX (modo). En Windows 8.1, SFX se denominaba LFX (local) y MFX fue árbitro como API de GFX (global).

Los IHVs pueden implementar API de efectos de sistema de audio personalizados para reemplazar o ambas API de efectos de sistema de audio personalizados de SFX y MFX de Windows. En términos generales, los IMV o los OEM tienen dos estrategias básicas para combinar las API de efectos del sistema de audio personalizados con las API que proporciona Windows. Estas estrategias proporcionan flexibilidad a los IHD sobre cómo integran sus efectos personalizados con los de Windows.

Sustituya

Desarrolle un conocimiento detallado del APO de Windows que quiere reemplazar y sus características. Use ese conocimiento para implementar un APO personalizado que llame al APO de Windows de una manera que tenga más sentido para el IHV desde la perspectiva de su experiencia de usuario de destino. Esta estrategia es más adecuada para IHV o OEM que quieran:

  • Integre perfectamente sus efectos personalizados con los efectos de Windows.
  • Implemente su propia interfaz de usuario para controlar sus efectos y los efectos implementados por las API de Windows.

Para obtener más información sobre cómo escribir un APO, vea Objetos de procesamiento de audio de Windows.

Contenedor fino

Escriba el APO personalizado como un contenedor fino alrededor del APO de Windows. Esta estrategia es más adecuada para IHV o OEM que quieran:

  • Agregue sus efectos personalizados de la manera más sencilla posible.
  • Haga que la interfaz de usuario de Windows siga controlando los efectos.

Los IHV o los OEM que elijan Estrategia de la opción de contenedor fino, deben seguir revisando objetos de procesamiento de audio de Windows para obtener un conocimiento exhaustivo de los efectos del sistema de audio personalizados de Windows.

Nota: Con la estrategia de contenedor fino IHD no puede agregar interfaz de usuario para controlar sus efectos de sistema de audio personalizados agregados a la pestaña Mejoras de Windows. Solo hay una pestaña Mejoras y debe permanecer asociada a la página de propiedades de las API de Windows. La interfaz de usuario de IHV debe implementarse de alguna otra manera, como una aplicación de Panel de control independiente.

Información de programación

En esta sección se tratan los problemas generales de programación que se deben solucionar para implementar una API personalizada.

Tanto SFX(Stream) como las API de efectos del sistema de audio personalizados MFX(Mode) tienen las siguientes características generales:

  • Deben registrarse como objetos de servidor en proceso COM que se pueden crear instancias mediante CoCreateInstance.
  • Los CLSID son CLSID_CWMAudioLFXAPO y CLSID_CWMAudioGFXAPOpara las API de SFX y MFX, respectivamente. Los CLSID se declaran en wmcodecdsp.h y se definen en wmcodecdspuuid.lib.
  • Deben admitir la agregación COM. Sin embargo, no se espera que la agregación se use en el escenario de efectos del sistema de audio personalizado, por lo que no debería suponer ningún problema significativo.

Inicialización

Un APO personalizado debe inicializar el APO de ventana mediante una llamada a su método IAudioSystemEffects::Initialize . Normalmente, esto se realiza desde el método Initialize del APO personalizado. Los argumentos que se pasan al método Initialize del APO personalizado deben pasarse directamente al initialize de Windows APO. Esto permite que el APO capture su configuración de los almacenes de propiedades Endpoint y Fx en la estructura APOInitSystemEffects. Es posible que el APO personalizado capture la configuración y páselos selectivamente al APO, pero eso es básicamente estrategia A.

Si el APO personalizado reemplaza una característica, generalmente es aconsejable desactivar la característica correspondiente en el APO. Sin embargo, es posible que la desactivación de la característica no sea estrictamente necesaria, dependiendo de cómo funciona la característica. Para desactivar una característica, consulte el APO para su interfaz IPropertyStore y llame a IPropertyStore::SetValue. Las propiedades admitidas por el almacén de propiedades de APO se describen en "Propiedades de IPropertyStore admitidas". Más adelante en este tema.

Para obtener ejemplos de cómo comunicarse con el almacén de propiedades APO de efectos del sistema de audio personalizado de Windows, consulte los ejemplos en GitHub en: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Consulta del estado de la característica de APO

Si un APO personalizado simplemente reemplaza una característica de efectos de audio de Windows y no tiene su propia interfaz de usuario de configuración o almacén de configuración, es posible que tenga que determinar qué características están habilitadas en el APO correspondiente.

Hay al menos dos maneras de obtener esta información:

  • Opción A: Consultando directamente el almacén de propiedades Fx.

  • Opción B: Indirectamente, mediante la creación de instancias del APO y el uso de su interfaz IPropertyStore para consultar el almacén de propiedades.

Opción A

Esta opción tiene la ventaja de que se puede realizar sin crear instancias de un APO. Además, si un APO personalizado quiere supervisar el almacén de propiedades Fx, la opción A es la única manera de recibir notificaciones de cambio de propiedad sobre la marcha. Para obtener un ejemplo de la opción A, consulte el ejemplo "comprimir".

Con la opción A, el APO personalizado consulta el almacén de propiedades del punto de conexión principal (no Fx) para PKEY_AudioEngine_DeviceFormat. A continuación, usa la máscara de canal de ese formato como PID para la clave de propiedad que se usa para consultar el almacén de propiedades Fx. El GUID (fmtid) de la clave de propiedad que se usa para consultar el almacén de propiedades Fx es uno de los valores de XXX_XXX_KEY_GUID de wmcodecdsp.h. Los nombres de KEY_GUID corresponden de maneras obvias a los nombres MFPKEY que se trataron anteriormente en este tema.

Opción B

Esta opción tiene la ventaja de que puede controlar correctamente la posibilidad de que el APO de Windows pueda tener algunas de sus características habilitadas de forma predeterminada si la propiedad correspondiente en el almacén de propiedades Fx no existe.

Con la opción B, el APO personalizado simplemente consulta el APO para su interfaz IPropertyStore y llama a IPropertyStore::GetValue mediante una de las claves de MFPKEY_XXX que se trataron anteriormente en este tema.

Negociación de formato

Al implementar un APO de SFX personalizado que encapsula el APO de SFX, no especifique APO_FLAG_FRAMESPERSECOND_MUST_MATCH en las propiedades de registro del APO personalizado. Esta regla debe seguirse si el APO personalizado puede cambiar o no el formato del canal. Si el APO de SFX personalizado especificara esta marca, impediría que el SFX correspondiente realizar el relleno del altavoz, la virtualización de auriculares o el entorno virtual.

Una implementación personalizada de APO de SFX debe implementar o invalidar IAudioProcessingObject::IsInputFormatSupported. Es poco probable que la implementación de la clase base IsInputFormatSupported refleje con precisión el conjunto de posibles conversiones de canal implementadas por el APO de SFX personalizado y el APO de SFX.

El método IsInputFormatSupported de SFX personalizado debe llamar al IsInputFormatSupported del APO correspondiente. Esto garantiza que el APO de SFX controle todas las conversiones de canal que no estén administradas por el APO de SFX personalizado. Tenga en cuenta que es posible que el APO de SFX se actualice para admitir más conversiones en futuras versiones de Windows. Llamar al método IsInputFormatSupported de APO es una manera de asegurarse de que el conjunto de conversiones de canal compatibles con el APO personalizado contiene completamente el conjunto de conversiones de canal compatibles con el APO de SFX.

Lo que debe hacer el APO personalizado con el valor devuelto del método IsInputFormatSupported de SFX APO depende de qué conversiones de canal, si las hay, admite el APO de SFX personalizado.

Si el APO de SFX personalizado no admite ninguna de sus propias conversiones de canal, su método IsInputFormatSupported puede devolver el valor devuelto por el método IsInputFormatSupported de SFX APO directamente al autor de la llamada. Para obtener un ejemplo, vea los ejemplos "swap" y "compress".

Si el APO de SFX personalizado admite sus propias conversiones de canal, entonces un valor devuelto negativo (incluido S_FALSE) del método IsInputFormatSupported de SFX APO no se traduce necesariamente en un valor devuelto negativo al autor de la llamada. El APO de SFX personalizado podría, por ejemplo, admitir conversiones de canal que no son compatibles con el APO correspondiente. En ese caso, el APO de SFX personalizado debe combinar el valor devuelto del método IsInputFormatSupported de SFX APO con su propia lógica para determinar las entradas admitidas. Tenga en cuenta que el significado óptimo de "combinar" depende del tipo de conversión de canal que tenga prioridad. El mejor enfoque depende del diseño exacto de la implementación personalizada.

El método IsOutputFormatSupported en un APO de SFX no está interesado porque el formato de salida de un APO de SFX es el formato de combinación del dispositivo. Este formato se basa en consideraciones externas y no puede verse afectado por un APO de SFX o su formato de entrada. Por ese motivo, los ejemplos no intentan implementar la lógica correcta para IsOutputFormatSupported.

Las consideraciones anteriores no se aplican a las API de MFX porque el APO de MFX no implementa ninguna característica que requiera o implique cambiar el formato del canal. Por ese motivo, el ejemplo de MFX no hace nada especial para IsInputFormatSupported o IsOutputFormatSupported. La lógica de negociación de formato de un APO de MFX personalizado no se ve afectada por el hecho de que encapsula el APO de MFX.

LockForProcess/UnlockForProcess

El método IAudioProcessingObjectConfiguration::LockForProcess del APO personalizado debe llamar al método correspondiente en el APO. LockForProcess() es un buen lugar para tomar decisiones en cuanto al orden en que deben producirse las distintas fases de procesamiento. Por ejemplo, puede decidir si se debe aplicar primero el procesamiento de APO personalizado o el procesamiento del APO. Los tres ejemplos proporcionan ejemplos de esta lógica de decisión y los comentarios de los ejemplos proporcionan algunos antecedentes. Sin embargo, es imposible proporcionar instrucciones completamente generales sobre ese tema en este documento, ya que requeriría conocimiento de las características específicas del APO personalizado y cómo podrían interactuar con las características de las API.

GetLatency

La implementación de IAudioProcessingObject::GetLatency de APO personalizada debe llamar a GetLatency en el APO que se está encapsulando. Si el procesamiento de APO personalizado incurre en latencia, debe agregarlo al resultado devuelto por el APO antes de devolver el valor al autor de la llamada.

APOProcess

El método IAudioProcessingObjectRT::APOProcess de APO personalizado debe llamar al método APOProcess de APO antes, después o incluso durante el procesamiento. La decisión sobre cuándo llamar a APOProcess debe realizarse en LockForProcess, de modo que se puedan asignar los búferes intermedios necesarios. Las API admiten el procesamiento en contexto cada vez que sus formatos de entrada y salida son idénticos. En ese caso, el APO personalizado puede pasar el mismo APO_CONNECTION_PROPERTY que la propiedad de conexión de entrada y salida para el APO de Windows. Sin embargo, el APO personalizado no debe usar la propiedad de conexión de entrada del APO personalizado como la propiedad de conexión de salida para el APO. En general, las API no deben modificar su búfer de entrada.

Control de errores de APO

Si un APO devuelve un error al APO personalizado correspondiente, el APO personalizado debe actuar desde ese punto como si no hubiera ningún APO. Los ejemplos tratan todos los errores de APO como equivalentes a CoCreateInstance que no pueden crear el APO. Opcionalmente, el APO personalizado puede limitar el efecto de los errores del método LockForProcess del APO a la sesión actual. En otras palabras, el APO personalizado no usa el APO durante las llamadas posteriores a su método APOProcess. Sin embargo, el APO personalizado podría intentar volver a usar el APO si hay otra llamada LockForProcess más adelante, con distintos formatos.

Compilación y vinculación

Para usar el CLSID de APO y las definiciones de clave de propiedad, incluya wmcodecdsp.h y vincule con wmcodecdspuuid.lib. Para obtener más información, consulte el encabezado wmcodecdsp.h.

Ejemplos de APO

Hay cuatro ejemplos de efectos del sistema de audio de ejemplo. Los ejemplos de APO están disponibles en GitHub en: https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Directrices generales para efectos de sistema de audio personalizados

A continuación se muestran algunas directrices que deben seguir los IHD al implementar las API de efectos del sistema de audio personalizados.

  • Todos los efectos del sistema de audio deben proporcionar opciones de encendido y apagado. Los usuarios no deben verse obligados a usar un efecto de sistema de audio.
  • Las interacciones entre las características de SFX y MFX APO deben estar mediadas por las API y su interfaz de usuario relacionada.
  • Las características que se especifican como SFX o MFX aquí se pueden mover entre SFX y MFX en implementaciones personalizadas. Sin embargo, esto debe hacerse con la comprensión de que las opciones de encendido y apagado deben existir y que la accesibilidad y la idoneidad de las opciones no deben verse comprometidas.
  • Los implementadores deben recordar que SFX puede tener diferentes máscaras de canal de entrada y salida. El APO de MFX debe tener las mismas máscaras de canal de entrada y salida.

API proporcionadas por Windows

Para obtener información sobre las otras API proporcionadas por Windows, consulte estos temas.

Aumento de graves

Administración de graves

Sonido mejorado para equipos portátiles

DSP de igualdad de ruido

Protección con baja frecuencia

Corrección de la sala

Relleno del altavoz

Speaker Phantoming

Entorno virtual

Sonido envolvente virtualizado sobre auriculares

Información específica de personalización de APO

Ecualización de ruido (APO de SFX)

La ecualización de la intensidad es un procesamiento comprimido (dinámico) controlado por una métrica de intensidad perceptual. Corrección de la sala (APO de MFX)

La corrección de la sala usa un perfil que generó el Asistente para calibración de salas. Este perfil se almacena como un blob binario. El formato del blob no está publicado actualmente.

Conversión de canales (APO de SFX)

El APO de conversión de canal controla varias tareas.

Virtualización de auriculares

Este efecto se habilita si el formato de canal del contenido que se reproduce (N.x) es 2.0 o mayor, donde x puede ser 0 o 1. La máscara de salida debe ser estéreo (0x3). La máscara de entrada se limita a algunas combinaciones admitidas, que se enumeran en la tabla siguiente.

Máscaras de canal de virtualización de auriculares

Nombre 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

Entorno virtual

Este efecto también se conoce como plegado izquierdo /right (LTRT) o codificación de matriz izquierda/derecha. Se usa si el formato de canal del contenido que se reproduce (N.x) es 2.0 o mayor, donde x puede ser 0 o 1. El plegado LTRT normalmente es de 4,0 a 2,0. Normalmente, cualquier otro formato de entrada se controla aplicando N.x a 4.0 plegado genérico. Sin embargo, en nuestra implementación, el plegado LTRT es de forma nativa de 5.1 a 2.0. Cualquier otra entrada se controla aplicando primero N.x a 5.1 plegado genérico.

La máscara del canal de salida debe ser 0x3 (estéreo) y el número de canales de entrada ,incluido el subwoofer si está presente, no debe ser superior a ocho.

Relleno del altavoz

Este efecto se usa cuando el número de canales de entrada (N) es menor que el número de canales de salida (M). El efecto rellena el canal N.x en canales M.x, donde x puede ser 0 o 1.

Las máscaras de canal de la tabla 4(omitir el canal LFE) son compatibles con el relleno del altavoz. El relleno del altavoz admite cualquier combinación de presencia de canal de entrada o salida, por lo que los números de la izquierda son solo ejemplos. Las configuraciones reales pueden o no tener un subwoofer.

Máscaras de canal de relleno del altavoz

Nombre 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

No se admite el relleno del hablante si se cumple alguna de las siguientes condiciones:

  • La máscara de entrada es igual a la máscara de salida.
  • La única diferencia entre entrada y salida es que uno tiene canales izquierdo/derecho lateral; el otro tiene canales izquierdo/derecho atrás.
  • La entrada tiene más canales principales que los de salida.
  • La máscara de salida incluye los altavoces de izquierda y derecha central, pero la máscara de entrada no.
  • El conjunto de canales de la salida, pero no en la entrada, no incluye al menos uno de: centro delantero, atrás a la izquierda/derecha o a la izquierda/derecha.

Hay una excepción al segundo elemento de la lista. Si la única diferencia entre la entrada y la salida es que uno tiene canales izquierdo/derecho lateral y el otro tiene canales de izquierda o derecha atrás, se admite el relleno del altavoz si cualquiera de los formatos contiene canales que se encuentran entre sideLR y backLR en el orden de bits de máscara de canal. Hay tres canales de este tipo:

  • SPEAKER_FRONT_LEFT_OF_CENTER
  • SPEAKER_FRONT_RIGHT_OF_CENTER
  • SPEAKER_BACK_CENTER

Si la máscara de entrada o salida contiene cualquiera de estos tres canales, es posible que se admita el relleno del altavoz aunque no cumpla la segunda condición de la lista, sino solo si se cumplen las demás condiciones. Por ejemplo, el relleno del hablante de MASK_7_FRONT_BACK hacia o desde MASK_7_FRONT_SIDE es compatible con el relleno del hablante por este motivo.

En la tabla siguiente se incluye la lista completa de valores de canal.

Nombre 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

Los retrasos se usan para los canales de las configuraciones de salida que están "fuera" del intervalo frontal en la configuración de entrada. Por el contrario, si un altavoz de la configuración de salida es "entre" algunos altavoces de la configuración de entrada en el sentido frontal, la salida de ese altavoz se genera mezclando algunos de los canales de entrada en cualquiera de los lados del canal de salida.

Run-Time Consideraciones al reutilizar las API de Windows

Esta sección contiene información adicional que los IHD y los OEM pueden resultar útiles al implementar sus efectos de sistema de audio personalizados.

Una implementación de APO personalizada:

  • Usa CoCreateInstance para crear una instancia de una o varias instancias de las API de efectos del sistema de audio personalizado de Windows.
  • Configura cada instancia para habilitar el conjunto deseado de características.
  • Inserta cada instancia en un lugar adecuado dentro de la canalización interna del APO personalizado.

¿Por qué una o varias instancias?

Para evitar interacciones no deseadas, la mayoría de las características requieren un orden relativo determinado. Dado que las API de Windows implementan varias características dentro de un único APO, es posible que se necesiten varias instancias de ese APO para garantizar la ordenación correcta. Por ejemplo, supongamos que tres características habilitadas (A, B y C) deben ordenarse ABC. La implementación personalizada controla B, pero delega A y C al APO de Windows. A continuación, A y C deben estar en instancias independientes del APO de Microsoft para que la implementación personalizada de B pueda producirse entre ellos.

Windows implementa la corrección de sala en el APO de MFX, lo que significa que es un objeto COM independiente del APO de SFX. Una implementación personalizada podría elegir delegar la corrección de sala en la implementación de Windows, pero colocarla en un APO de SFX personalizado. Después, la implementación de SFX personalizada podría necesitar delegar algún procesamiento en la implementación de APO de SFX de Windows y otro procesamiento en la implementación de APO de Windows MFX.

Control de las limitaciones de diferentes combinaciones de formato de entrada-salida

Muchas características, especialmente la administración de graves, no funcionan en determinados casos. Por ejemplo, la administración de graves hacia delante no está definida si la propiedad de configuración del altavoz bajo es "AllSmall" o "AllLarge" y el formato de salida no incluye un canal de subwoofer o la marca NoSub está establecida. No siempre es posible detectar el error durante la llamada A IPropertyStore::SetValue . El método intenta habilitar la característica, pero los formatos de entrada y salida no se conocen en ese momento porque LockForProcess debe producirse después de todas las manipulaciones de propiedades. Esto significa que es posible habilitar una característica, verlo aparentemente correcto, pero no tener lugar el procesamiento correspondiente.

Hay dos estrategias disponibles para tratar estas situaciones:

  • Analice detenidamente las secciones específicas de características de este documento para poder predecir exactamente cuándo una característica determinada se realizará o no se realizará correctamente.
  • Llame a IPropertyStore::GetValue después de llamar a LockForProcess para comprobar el estado de las propiedades importantes.

Cuando LockForProcess determina que no se puede habilitar una característica determinada(debido a los formatos de entrada y salida o al valor de alguna otra propiedad), LockForProcess actualiza el valor de la propiedad correspondiente en el almacén de propiedades.

Interacción entre Speaker Fill y Bass Management

Cuando el relleno del altavoz está encendido y se conecta un subwoofer, la administración de graves hacia delante debe producirse antes de que el altavoz llene para evitar el filtrado de comb de la señal de baja frecuencia por el retraso envolvente del relleno del altavoz.

Cuando se habilita el relleno del altavoz y no se conecta ningún subwoofer, se pueden realizar dos tipos de administración de graves hacia delante:

  • Si los altavoces frontales izquierdo/derecho son grandes, la administración de graves hacia delante enruta la parte de baja frecuencia de los canales envolventes y centrados en los altavoces frontales izquierdo/derecho. La gestión del bajo hacia delante debe venir después de que el altavoz rellene este caso.
  • Si todos los altavoces son pequeños, la administración de graves hacia delante se convierte en protección de baja frecuencia para todos los altavoces principales.

Esto puede ocurrir antes o después del relleno del altavoz. Sin embargo, por motivos de rendimiento, es mejor tener una administración de graves hacia delante antes de rellenar el altavoz.

El APO de Windows implementa ciertas configuraciones comunes de relleno de altavoz, como 2.0 => 5.1, con código optimizado especial que controla la administración de bajos inversos en el mismo paso que el relleno del altavoz.

Interacción entre Folddown y Bass Management

La virtualización de auriculares solo admite la administración de bajos inversos:

  • La administración de graves hacia delante no tiene sentido con la virtualización de auriculares.
  • Para simplificar la implementación, no se admite la protección de baja frecuencia ni la potenciación de graves.

Cuando cualquiera de las virtualización de auriculares, la codificación envolvente virtual o los efectos de relleno del altavoz están activados, la administración de bajos inversos se controla durante ese paso. La administración de bajos inversos todavía se controla a través de la propiedad de administración de bajos inversos de APOs como si fuera una característica independiente. En estos casos, la administración inversa del bajo simplemente controla los coeficientes de plegado para el canal de entrada .1. Un problema abierto es que la administración de bajos inversos no se puede deshabilitar cuando LTRT está activado. En ese caso, la gestión de bajos inversos utiliza una ganancia de canal subwoofer no convencional.

Las API de efectos del sistema de audio de Windows aplican algún procesamiento menor( ganancia y retraso), incluso cuando no hay características habilitadas. El objetivo de este procesamiento es asegurarse de que los parámetros de ganancia y retraso no cambian cuando se habilita una característica sobre la marcha. El motivo es que el retraso es inherente a la implementación de algunas características, y algunas características aplican una ganancia <1 para evitar una salida excesivamente alta en determinadas situaciones. El conjunto de características disponibles depende de los formatos de salida de entrada y de determinadas propiedades, por lo que se obtiene y retrasa la normalización acumulativa.

Si las características no se activarán o desactivarán sobre la marcha, la ganancia de normalización se puede deshabilitar estableciendo la MFPKEY_CORR_NORMALIZATION_GAIN propiedad en FALSE llamando a IPropertyStore::SetValue. La propiedad puede ser TRUE de forma predeterminada.

No hay ningún mecanismo para deshabilitar el retraso de normalización porque se supone menos probable que sea censurable que la ganancia de normalización. Si el retraso de normalización es censurable, simplemente omita el APO en cuestión.

Consulte también