Partager via

Combiner des API personnalisées et Windows

  • Article

Les objets de traitement audio (APO) fournissent un traitement du signal numérique basé sur un logiciel personnalisable pour les flux audio Windows. Il est possible de combiner des API fournies par Microsoft avec du code développé par le partenaire, en encapsulant et en personnalisant les fonctionnalités existantes.

Reportez-vous à ces rubriques pour obtenir des informations générales sur les API.

Les API ont été introduites pour la première fois dans Windows Vista et vous pouvez voir des références aux API système antérieures - sAPOs. Pour plus d’informations, consultez le livre blanc Effets audio personnalisés dans Windows Vista . Ce livre blanc peut faire référence à d’anciennes rubriques de développement com et d’interface utilisateur .

Comment combiner des API personnalisées et Windows

Cette section contient des instructions pour implémenter des API d’effets de système audio personnalisés, en créant un wrapper mince autour de l’APO correspondant. Personnalisé APO fait référence à l’implémentation par IHV de l’APO.

Il existe deux types d’APO, SFX (Stream) et MFX (mode). Dans Windows 8.1, SFX a été appelé LFX (local) et MFX a été arbitré en tant qu’APO GFX (global).

Les IHVs peuvent implémenter des APO d’effets de système audio personnalisés pour remplacer l’un ou l’autre des API d’effets du système audio personnalisé Windows SFX et MFX. D’une manière générale, les IHVs ou les OEM ont deux stratégies de base pour combiner des APO d’effets de système audio personnalisés avec les API que Windows fournit. Ces stratégies donnent aux IHVs une flexibilité quant à la façon dont ils intègrent leurs effets personnalisés à ceux de Windows.

Replace

Développez une compréhension détaillée de l’APO Windows que vous souhaitez remplacer et de ses fonctionnalités. Utilisez cette compréhension pour implémenter une APO personnalisée qui appelle l’APO Windows d’une manière qui est la plus logique pour l’IHV du point de vue de l’expérience utilisateur cible. Cette stratégie convient le mieux aux IHV ou aux oem qui souhaitent :

  • Intégrez en toute transparence leurs effets personnalisés aux effets Windows.
  • Implémentez leur propre interface utilisateur pour contrôler leurs effets et les effets implémentés par les API Windows.

Pour plus d’informations sur l’écriture d’une APO, consultez Objets de traitement audio Windows.

Wrapper mince

Écrivez l’APO personnalisé en tant que wrapper mince autour de l’APO Windows. Cette stratégie convient le mieux aux IHV ou aux oem qui souhaitent :

  • Ajoutez leurs effets personnalisés de la manière la plus simple possible.
  • L’interface utilisateur Windows continue de contrôler les effets.

Les IHV ou les oem qui choisissent l’option Stratégie du wrapper mince doivent toujours passer en revue les objets de traitement audio Windows pour obtenir une compréhension approfondie des effets du système audio personnalisé Windows.

Remarque : Avec la stratégie de wrapper mince, les IHVs ne peuvent pas ajouter d’interface utilisateur pour contrôler leurs effets de système audio personnalisés ajoutés à l’onglet Améliorations windows. Il n’existe qu’un seul onglet Améliorations et il doit rester associé à la page de propriétés pour les API Windows. L’interface utilisateur de l’IHV doit être implémentée d’une autre manière, par exemple une application Panneau de configuration distincte.

Informations de programmation

Cette section décrit les problèmes de programmation généraux qui doivent être résolus pour implémenter des API personnalisées.

Les API d’effets de système audio personnalisés SFX(Stream) et MFX(Mode) présentent les caractéristiques générales suivantes :

  • Ils doivent être inscrits en tant qu’objets serveur com in-process qui peuvent être instanciés à l’aide de CoCreateInstance.
  • Les CLSID sont CLSID_CWMAudioLFXAPO et CLSID_CWMAudioGFXAPOpour les API SFX et MFX, respectivement. Les CLSID sont déclarés dans wmcodecdsp.h et définis dans wmcodecdspuuid.lib.
  • Ils doivent prendre en charge l’agrégation COM. Toutefois, l’agrégation n’étant pas censée être utilisée dans un scénario d’effets de système audio personnalisé, elle ne doit pas poser de problèmes significatifs.

Initialisation

Un APO personnalisé doit initialiser l’APO Window en appelant sa méthode IAudioSystemEffects ::Initialize . Cela est généralement effectué à partir de la méthode Initialize de l’APO personnalisée. Tous les arguments passés à la méthode Initialize de l’APO personnalisée doivent être passés directement à l’initialize de Windows APO. Cela permet à l’APO d’extraire ses paramètres à partir du point de terminaison et des magasins de propriétés Fx dans la structure APOInitSystemEffects. Il est possible que l’APO personnalisée récupère les paramètres et les passe de manière sélective à l’APO, mais il s’agit essentiellement de la stratégie A.

Si l’APO personnalisée remplace une fonctionnalité, il est généralement recommandé de désactiver la fonctionnalité correspondante sur l’APO. Toutefois, la désactivation de la fonctionnalité peut ne pas être strictement nécessaire, selon son fonctionnement. Pour désactiver une fonctionnalité, interrogez l’APO pour son interface IPropertyStore et appelez IPropertyStore ::SetValue. Les propriétés prises en charge par le magasin de propriétés de l’APO sont décrites dans « Propriétés IPropertyStore prises en charge ». Plus loin dans cette rubrique.

Pour obtenir des exemples de communication avec le magasin de propriétés APO des effets du système audio personnalisé Windows, consultez les exemples sur GitHub à l’adresse suivante : https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

État des fonctionnalités d’APO de requête

Si une APO personnalisée remplace simplement une fonctionnalité d’effets audio Windows et n’a pas son propre interface utilisateur de configuration ou magasin de paramètres, il peut être nécessaire de déterminer quelles fonctionnalités sont activées sur l’APO correspondant.

Il existe au moins deux façons d’obtenir ces informations :

  • Option A : en interrogeant directement le magasin de propriétés Fx.

  • Option B : Indirectement, en instanciant l’APO et en utilisant son interface IPropertyStore pour interroger le magasin de propriétés.

Option A

Cette option présente l’avantage qu’elle peut être effectuée sans instancier une APO. En outre, si un APO personnalisé souhaite surveiller le magasin de propriétés Fx, l’option A est le seul moyen de recevoir des notifications de modification de propriété à la volée. Pour obtenir un exemple d’option A, consultez l’exemple « compresser ».

Avec l’option A, l’APO personnalisé interroge le magasin de propriétés de point de terminaison main, et non Fx, pour PKEY_AudioEngine_DeviceFormat. Il utilise ensuite le masque de canal de ce format en tant que PID pour la clé de propriété utilisée pour interroger le magasin de propriétés Fx. Le GUID (fmtid) de la clé de propriété utilisée pour interroger le magasin de propriétés Fx est l’une des valeurs XXX_XXX_KEY_GUID de wmcodecdsp.h. Les noms KEY_GUID correspondent de manière évidente aux noms MFPKEY abordés plus haut dans cette rubrique.

Option B

Cette option présente l’avantage qu’elle peut gérer correctement la possibilité que l’APO Windows ait éventuellement certaines de ses fonctionnalités activées par défaut si la propriété correspondante dans le magasin de propriétés Fx n’existe pas.

Avec l’option B, l’APO personnalisée interroge simplement l’APO pour son interface IPropertyStore et appelle IPropertyStore ::GetValue à l’aide de l’une des clés MFPKEY_XXX qui ont été abordées plus haut dans cette rubrique.

Négociation de format

Lorsque vous implémentez une APO SFX personnalisée qui encapsule l’APO SFX, ne spécifiez APO_FLAG_FRAMESPERSECOND_MUST_MATCH pas dans les propriétés d’inscription de l’APO personnalisée. Cette règle doit être suivie, que l’APO personnalisée puisse ou non modifier le format du canal. Si l’APO SFX personnalisé devait spécifier cet indicateur, cela empêcherait le SFX correspondant d’effectuer le remplissage de haut-parleur, la virtualisation du casque ou l’environnement virtuel.

Une implémentation SFX APO personnalisée doit implémenter ou remplacer IAudioProcessingObject ::IsInputFormatSupported. Il est peu probable que l’implémentation de la classe de base IsInputFormatSupported reflète avec précision l’ensemble des conversions de canal possibles qui ont été implémentées par l’APO SFX personnalisé et l’APO SFX.

La méthode IsInputFormatSupported de l’APO SFX personnalisée doit appeler IsInputFormatSupported de l’APO correspondant. Cela garantit que l’APO SFX gère toutes les conversions de canal qui ne sont pas gérées par l’APO SFX personnalisé. Notez que l’APO SFX peut être mis à jour pour prendre en charge davantage de conversions dans les futures versions de Windows. L’appel de la méthode IsInputFormatSupported de l’APO est un moyen de garantir que l’ensemble de conversions de canal prises en charge par l’APO personnalisée contient entièrement l’ensemble des conversions de canal prises en charge par l’APO SFX.

Ce que l’APO personnalisé doit faire avec la valeur de retour de la méthode IsInputFormatSupported de l’APO SFX dépend des conversions de canal, le cas échéant, que l’APO SFX personnalisé prend en charge.

Si l’APO SFX personnalisé ne prend pas en charge ses propres conversions de canal, sa méthode IsInputFormatSupported peut retourner la valeur qui a été retournée par la méthode IsInputFormatSupported de L’APO SFX directement à l’appelant. Pour obtenir un exemple, consultez les exemples « échanger » et « compresser ».

Si l’APO SFX personnalisé prend en charge ses propres conversions de canal, une valeur de retour négative (y compris S_FALSE) provenant de la méthode IsInputFormatSupported de SFX APO ne se traduit pas nécessairement par une valeur de retour négative pour l’appelant. L’APO SFX personnalisé peut, par exemple, prendre en charge les conversions de canal qui ne sont pas prises en charge par l’APO correspondant. Dans ce cas, l’APO SFX personnalisé doit combiner la valeur de retour de la méthode IsInputFormatSupported de L’APO SFX avec sa propre logique pour déterminer les entrées prises en charge. Notez que la signification optimale de « combiner » dépend du type de conversion de canal qui doit être prioritaire. La meilleure approche dépend de la conception exacte de l’implémentation personnalisée.

La méthode IsOutputFormatSupported sur une APO SFX n’est pas inintéressante, car le format de sortie d’une APO SFX est le format de mixage de l’appareil. Ce format est basé sur des considérations externes et ne peut pas être affecté par un APO SFX ou son format d’entrée. Pour cette raison, les exemples ne tentent pas d’implémenter la logique correcte pour IsOutputFormatSupported.

Les considérations ci-dessus ne s’appliquent pas aux API MFX, car l’APO MFX n’implémente aucune fonctionnalité qui nécessite ou implique la modification du format du canal. Pour cette raison, l’exemple MFX ne fait rien de spécial pour IsInputFormatSupported ou IsOutputFormatSupported. La logique de négociation de format d’une APO MFX personnalisée n’est pas affectée par le fait qu’elle encapsule l’APO MFX.

LockForProcess/UnlockForProcess

La méthode IAudioProcessingObjectConfiguration ::LockForProcess de l’APO personnalisée doit appeler la méthode correspondante sur l’APO. LockForProcess() est un bon endroit pour prendre des décisions quant à l’ordre dans lequel les différentes étapes de traitement doivent se produire. Par exemple, il peut décider d’appliquer le traitement APO personnalisé ou le traitement de l’APO en premier. Les trois exemples fournissent des exemples de cette logique de décision, et les commentaires dans les exemples fournissent un peu d’arrière-plan. Toutefois, il est impossible de fournir des conseils complètement généraux sur ce sujet dans ce document, car cela exigerait une connaissance des fonctionnalités spécifiques de l’APO personnalisée et de la façon dont elles peuvent interagir avec les fonctionnalités des API.

GetLatency

L’implémentation IAudioProcessingObject ::GetLatency de l’APO personnalisée doit appeler GetLatency sur l’APO en cours d’exécution. Si le traitement APO personnalisé entraîne une latence, il doit l’ajouter au résultat retourné par l’APO avant de renvoyer la valeur à l’appelant.

APOProcess

La méthode IAudioProcessingObjectRT ::APOProcess personnalisée doit appeler la méthode APOProcess de l’APO avant, après ou même pendant le traitement. La décision d’appeler APOProcess doit être prise dans LockForProcess, afin que toutes les mémoires tampons intermédiaires nécessaires puissent être allouées. Les API prennent en charge le traitement sur place chaque fois que leurs formats d’entrée et de sortie sont identiques. Dans ce cas, l’apo personnalisée peut passer le même APO_CONNECTION_PROPERTY que la propriété de connexion d’entrée et de sortie pour l’APO Windows. Toutefois, l’apo personnalisée ne doit pas utiliser la propriété de connexion d’entrée de l’APO personnalisée comme propriété de connexion de sortie pour l’APO. En général, les API ne doivent pas modifier leur mémoire tampon d’entrée.

Gestion des erreurs APO

Si une APO retourne une erreur à l’APO personnalisée correspondante, l’APO personnalisée doit agir à partir de ce point comme s’il n’y avait pas d’APO. Les exemples traitent toutes les erreurs APO comme équivalentes à l’échec de la création de l’APO par CoCreateInstance. Si vous le souhaitez, l’apo personnalisée peut limiter l’effet des erreurs de la méthode LockForProcess de l’APO à la session active. En d’autres termes, l’apo personnalisée n’utilise pas l’APO lors des appels suivants à sa méthode APOProcess. Toutefois, l’apo personnalisée peut essayer à nouveau d’utiliser l’APO s’il existe un autre appel LockForProcess ultérieurement, avec des formats différents.

Compilation et liaison

Pour utiliser le CLSID APO et les définitions de clé de propriété, incluez wmcodecdsp.h et créez un lien avec wmcodecdspuuid.lib. Pour plus d’informations, consultez en-tête wmcodecdsp.h.

Exemples APO

Il existe quatre exemples d’effets de système audio. Les exemples APO sont disponibles sur GitHub à l’adresse suivante : https://github.com/Microsoft/Windows-driver-samples/tree/main/audio/sysvad/APO

Instructions générales pour les effets de système audio personnalisés

Voici quelques recommandations que les IHVs doivent suivre lors de l’implémentation d’API d’effets de système audio personnalisées.

  • Tous les effets du système audio doivent fournir des options d’activation/désactivation. Les utilisateurs ne doivent pas être obligés d’utiliser un effet de système audio.
  • Les interactions entre les fonctionnalités de l’APO SFX et MFX doivent être médiées par les API et leur interface utilisateur associée.
  • Les fonctionnalités spécifiées ici en tant que SFX ou MFX peuvent être déplacées entre SFX et MFX dans des implémentations personnalisées. Toutefois, cela doit être fait en montrant que les options d’activation/désactivation doivent exister et que l’accessibilité et la pertinence des options ne doivent pas être compromises.
  • Les implémenteurs doivent se rappeler que le SFX peut avoir des masques de canal d’entrée et de sortie différents. L’APO MFX doit avoir les mêmes masques de canal d’entrée et de sortie.

API fournies par Windows

Pour plus d’informations sur les autres API fournies par Windows, consultez ces rubriques.

Bass Boost

Gestion des basses

Son amélioré pour les ordinateurs portables

DSP de péréquation de l’intensité sonore

Protection à basse fréquence

Correction de salle

Remplissage de l’orateur

Fantôme de l’orateur

Virtual Surround

Son surround virtualisé sur casque

Informations de personnalisation APO spécifiques

Loudness Equalization (SFX APO)

L’égalisation de l’intensité sonore est un traitement compressé (dynamique) piloté par une métrique perceptuelle de l’intensité sonore. Correction de salle (MFX APO)

La correction de salle utilise un profil généré par l’Assistant Étalonnage des salles. Ce profil est stocké en tant qu’objet blob binaire. Le format de l’objet blob n’est pas publié actuellement.

Conversion de canal (APO SFX)

L’apo de conversion de canal gère plusieurs tâches.

Headphone Virtualization

Cet effet est activé si le format de canal du contenu lu (N.x) est 2.0 ou supérieur, où x peut être égal à 0 ou 1. Le masque de sortie doit être stéréo (0x3). Le masque d’entrée est limité à quelques combinaisons prises en charge, qui sont répertoriées dans le tableau ci-dessous

Masques de canal de virtualisation casque

Nom Valeur
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

Cet effet est également appelé codage de la matrice gauche/droite (LTRT) ou de matrice gauche/droite. Il est utilisé si le format de canal du contenu lu (N.x) est 2.0 ou supérieur, où x peut être 0 ou 1. Le repli LTRT est normalement de 4.0 à 2.0. Tout autre format d’entrée est généralement géré en appliquant d’abord N.x au pliage générique 4.0. Toutefois, dans notre implémentation, le repli LTRT est de 5.1 à 2.0 en mode natif. Toute autre entrée est gérée en appliquant d’abord N.x à la version 5.1 de repli générique.

Le masque de canal de sortie doit être 0x3 (stéréo) et le nombre de canaux d’entrée (y compris le caisson de basses s’il est présent) ne doit pas être supérieur à huit.

Remplissage de l’orateur

Cet effet est utilisé lorsque le nombre de canaux d’entrée (N) est inférieur au nombre de canaux de sortie (M). L’effet remplit le canal N.x aux canaux M.x, où x peut être égal à 0 ou 1.

Les masques de canal dans le tableau 4 (en ignorant le canal LFE) sont pris en charge pour le remplissage de l’orateur. Le remplissage de l’orateur prend en charge n’importe quelle combinaison de présence de canal de caissons de basses d’entrée ou de sortie, de sorte que les nombres à gauche ne sont que des exemples. Les configurations réelles peuvent ou non avoir un subwoofer.

Masques de canal de remplissage de l’orateur

Nom Valeur
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

Le remplissage de l’orateur n’est pas pris en charge si l’une des conditions suivantes est vraie :

  • Le masque d’entrée est égal au masque de sortie.
  • La seule différence entre l’entrée et la sortie est que l’on a des canaux côté gauche/droit ; l’autre a des canaux arrière gauche/droit.
  • L’entrée a plus de canaux main que la sortie.
  • Le masque de sortie inclut les haut-parleurs centre gauche/droit, mais pas le masque d’entrée.
  • L’ensemble de canaux dans la sortie, mais pas dans l’entrée, n’inclut pas au moins l’un des canaux suivants : centre avant, arrière gauche/droite ou côté gauche/droite.

Il existe une exception au deuxième élément de la liste. Si la seule différence entre l’entrée et la sortie est que l’un a des canaux côté gauche/droite et que l’autre a des canaux arrière gauche/droit, le remplissage de l’orateur est pris en charge si l’un ou l’autre format contient des canaux qui se situent entre sideLR et backLR dans l’ordre de bits du masque de canal. Il existe trois canaux de ce type :

  • SPEAKER_FRONT_LEFT_OF_CENTER
  • SPEAKER_FRONT_RIGHT_OF_CENTER
  • SPEAKER_BACK_CENTER

Si le masque d’entrée ou de sortie contient l’un de ces trois canaux, le remplissage de l’orateur peut être pris en charge même s’il ne remplit pas la deuxième condition de la liste, mais uniquement si les autres conditions sont remplies. Par exemple, le remplissage de l’orateur de MASK_7_FRONT_BACK vers ou depuis MASK_7_FRONT_SIDE est pris en charge par le remplissage de l’orateur pour cette raison.

Le tableau suivant contient la liste complète des valeurs de canal.

Nom Valeur
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

Les délais sont utilisés pour les canaux dans les configurations de sortie qui sont « en dehors » de la plage frontale dans la configuration d’entrée. À l’inverse, si un haut-parleur dans la configuration de sortie est « entre » certains haut-parleurs de la configuration d’entrée dans le sens avant-arrière, la sortie de ce haut-parleur est générée en mélangeant certains canaux d’entrée de part et d’autre du canal de sortie.

considérations Run-Time lors de la réutilisation des API Windows

Cette section contient des informations supplémentaires que les IMV et les oem peuvent trouver utiles lors de l’implémentation de leurs effets de système audio personnalisés.

Une implémentation APO personnalisée :

  • Utilise CoCreateInstance pour instancier une ou plusieurs instances des API d’effets du système audio personnalisé Windows.
  • Configure chaque instance pour activer l’ensemble de fonctionnalités souhaité.
  • Insère chaque instance dans un emplacement approprié dans le pipeline interne de l’APO personnalisé.

Pourquoi une ou plusieurs instances ?

Pour éviter les interactions indésirables, la plupart des fonctionnalités nécessitent un certain ordre relatif. Étant donné que les API Windows implémentent plusieurs fonctionnalités à l’intérieur d’un seul APO, plusieurs instances de cette APO peuvent être nécessaires pour garantir un classement correct. Par exemple, supposons que trois fonctionnalités activées (A, B et C) doivent être ordonnées ABC. L’implémentation personnalisée gère B, mais délègue A et C à Windows APO. A et C doivent ensuite se trouver dans des instances distinctes de Microsoft APO afin que l’implémentation personnalisée de B puisse se produire entre eux.

Windows implémente la correction de salle dans l’APO MFX, ce qui signifie qu’il s’agit d’un objet COM distinct de l’APO SFX. Une implémentation personnalisée peut choisir de déléguer la correction de salle à l’implémentation Windows, mais de la placer dans une apo SFX personnalisée. L’implémentation SFX personnalisée peut ensuite avoir besoin de déléguer un traitement à l’implémentation APO de Windows SFX et d’autres traitements à l’implémentation de Windows MFX APO.

Gestion des limitations de différentes combinaisons de formats entrée-sortie

De nombreuses fonctionnalités, en particulier la gestion des basses, ne fonctionnent pas dans certains cas. Par exemple, la gestion des basses avant n’est pas définie si la propriété de configuration de l’orateur bass est « AllSmall » ou « AllLarge » et si le format de sortie n’inclut pas de canal de subwoofer ou si l’indicateur NoSub est défini. Il n’est pas toujours possible de détecter l’échec lors de l’appel IPropertyStore ::SetValue . La méthode tente d’activer la fonctionnalité, mais les formats d’entrée et de sortie ne sont pas connus à ce moment-là, car LockForProcess doit se produire après toutes les manipulations de propriété. Cela signifie qu’il est possible d’activer une fonctionnalité, de la voir apparemment réussir, mais que le traitement correspondant n’a pas lieu.

Deux stratégies sont disponibles pour faire face à de telles situations :

  • Étudiez attentivement les sections spécifiques de ce document pour être en mesure de prédire exactement quand une fonctionnalité donnée réussira ou ne réussira pas.
  • Appelez IPropertyStore ::GetValue après l’appel de LockForProcess pour case activée l’état des propriétés importantes.

Quand LockForProcess détermine qu’une fonctionnalité particulière ne peut pas être activée en raison des formats d’entrée et de sortie ou de la valeur d’une autre propriété, LockForProcess met à jour la valeur de la propriété correspondante dans le magasin de propriétés.

Interaction entre le remplissage de l’orateur et la gestion des basses

Lorsque le remplissage du haut-parleur est activé et qu’un caisson de basses est connecté, la gestion des basses avant doit se produire avant le remplissage du haut-parleur pour éviter le filtrage en peigne du signal de basse fréquence par le délai d’entourage du remplissage de l’orateur.

Lorsque le remplissage du haut-parleur est activé et qu’aucun caisson de basses n’est connecté, deux types de gestion des basses avant sont possibles :

  • Si les haut-parleurs avant gauche/droit sont volumineux, la gestion des basses avant achemine la partie basse fréquence des canaux surround et central vers les haut-parleurs avant gauche/droit. La gestion des basses avant doit se faire après le remplissage de l’orateur dans ce cas.
  • Si tous les haut-parleurs sont de petite taille, la gestion des basses avant devient une protection à basse fréquence pour tous les haut-parleurs main.

Cela peut se produire avant ou après le remplissage de l’orateur. Toutefois, pour des raisons de performances, il est préférable d’avoir une gestion des basses avant avant le remplissage de l’orateur.

Windows APO implémente certaines configurations courantes de remplissage du haut-parleur, telles que 2.0 => 5.1, avec un code optimisé spécial qui gère la gestion des basses inversées dans la même étape que le remplissage de l’orateur.

Interaction entre le repli et la gestion des basses

La virtualisation casque prend uniquement en charge la gestion des basses inversées :

  • La gestion des basses avant n’a pas de sens avec la virtualisation du casque.
  • Par souci de simplicité d’implémentation, la protection à basse fréquence et l’amplification des basses ne sont pas prises en charge.

Lorsque l’un des effets de virtualisation du casque, d’encodage surround virtuel ou de remplissage du haut-parleur est activé, la gestion des basses inversées est gérée pendant cette étape. La gestion des basses inversées est toujours contrôlée via la propriété de gestion des basses inverses des API comme s’il s’agissait d’une fonctionnalité distincte. Dans ce cas, la gestion des basses inversées contrôle simplement les coefficients de repli pour le canal d’entrée .1. Un problème ouvert est que la gestion des basses inversées ne peut pas être désactivée lorsque LTRT est activé. Dans ce cas, la gestion des basses inversées utilise un gain de canal de subwoofer non conventionnel.

Les API d’effets du système audio Windows appliquent un traitement mineur (gain et retard) même si aucune fonctionnalité n’est activée. L’objectif de ce traitement est de s’assurer que les paramètres de gain et de retard ne changent pas lorsqu’une fonctionnalité est activée à la volée. La raison en est que le délai est inhérent à l’implémentation de certaines fonctionnalités, et un gain <1 est appliqué par certaines fonctionnalités pour éviter une sortie excessivement élevée dans certaines situations. L’ensemble des fonctionnalités disponibles dépend des formats d’entrée-sortie et de certaines propriétés, tout comme le gain et le retard de normalisation cumulés.

Si les fonctionnalités ne sont pas activées ou désactivées à la volée, le gain de normalisation peut être désactivé en définissant la MFPKEY_CORR_NORMALIZATION_GAIN propriété sur FALSE en appelant IPropertyStore ::SetValue. La propriété peut avoir la valeur TRUE par défaut.

Il n’existe aucun mécanisme permettant de désactiver le délai de normalisation, car il est présumé moins susceptible d’être répréhensible que le gain de normalisation. Si le délai de normalisation est inacceptable, il suffit de contourner l’APO en question.

Voir aussi