traitement audio Hardware-Offloaded
Le traitement audio déchargé du matériel permet d’effectuer les tâches de traitement audio main en dehors du processeur main de l’ordinateur.
Le traitement audio peut être très gourmand en ressources informatiques. Ainsi, dans de nombreux scénarios, il peut être utile de permettre à un processeur dédié de s’occuper des tâches de traitement telles que, par exemple, la combinaison et l’application d’effets.
Lorsque vous implémentez un pilote pour l’audio déchargé, vous développez un pilote capable de traiter les flux audio déchargés et d’exposer cette capacité au système audio Windows.
Les rubriques suivantes de cette section traitent du développement de pilotes, de l’impact de l’application et d’autres problèmes que vous devez connaître lorsque vous développez un pilote audio pour une carte audio qui implémente un moteur audio matériel pour gérer les flux audio déchargés.
Implémentation du pilote audio déchargé par le matériel
Interfaces d’assistance pour le traitement audio déchargé
Rapport de problèmes pour l’audio déchargé
Pour plus d’informations sur les API déchargées, consultez Effets APO déchargés du matériel
Vue d’ensemble de l’architecture de traitement audio Hardware-Offloaded
Le moteur audio logiciel
Le diagramme suivant montre le moteur audio logiciel Windows.
Les flux audio arrivent dans le moteur audio logiciel à partir de la couche DE L’API de session audio Windows (WASAPI) et éventuellement via une API de niveau supérieur comme Media Foundation. Dans les effets de flux du moteur audio logiciel (SFX), peuvent être appliqués par flux avant que les flux distincts ne soient mélangés, puis transmis via n’importe quel effet de point de terminaison disponible (EFX) et envoyé au matériel de rendu et aux haut-parleurs.
Le moteur audio matériel
Le moteur audio matériel est implémenté dans l’adaptateur audio et reflète largement les fonctionnalités du moteur audio logiciel. Bien que Windows prenne en charge le traitement audio déchargé du matériel, le pilote audio d’une carte audio donnée est chargé d’exposer les fonctionnalités sous-jacentes du matériel audio, à l’aide de la topologie présentée dans le diagramme suivant.
Le moteur audio matériel doit accepter un flux de processus hôte unique et jusqu’à n flux déchargés. Ces flux déchargés sont acheminés directement à partir de la couche application pour être traités dans le matériel. En d’autres termes, les flux déchargés ne sont pas transmis via le moteur audio logiciel. Le diagramme montre une implémentation qui a été conçue pour gérer jusqu’à trois flux déchargés. Le flux de processus hôte est la sortie finale du mélangeur logiciel de tous les flux qui ont été traités dans le moteur audio logiciel. Chaque moteur audio matériel doit également contenir un mixer matériel.
Pour maintenir la parité avec le moteur audio logiciel et l’interface WASAPI, il est nécessaire que le moteur audio matériel fournisse le flux de sortie audio final à la pile audio sous la forme d’un flux de bouclage. Cela est particulièrement critique pour les applications et les scénarios qui s’appuient sur l’annulation d’écho acoustique, ce qui nécessite une connaissance du flux de sortie final pour annuler les échos et empêcher les commentaires.
Pour implémenter un chemin d’accès pour un flux de bouclage, le pilote audio est chargé d’exposer une broche de bouclage. Cette broche retourne les données audio de la sortie finale du moteur audio, si les données sont encodées au format PCM. Sinon, le résultat post-mixage (mais précodage) est retourné. Cela signifie que dans le cas de données audio traitées avec un efX matériel qui encode dans un format non PCM, le flux de bouclage est pris directement après le mélangeur matériel, avant la phase EFX dans le moteur audio matériel. Pour plus d’informations sur la topologie de filtre KS qui représente le moteur audio matériel, consultez Implémentation du pilote audio déchargé matériel.
Architecture audio intégrée
Le diagramme suivant montre une vue d’ensemble de l’architecture résultante lorsqu’un moteur audio matériel fonctionne avec le moteur audio logiciel Windows.
Dans un scénario où le pilote audio a indiqué sa prise en charge du traitement audio déchargé, les n premiers flux (dans ce cas, trois) initialisés sont acheminés directement de la couche WASAPI vers le moteur audio matériel, en contournant le moteur audio logiciel. Tous les nouveaux flux audio ultérieurs au n pris en charge par le moteur audio matériel seront acheminés via le moteur audio logiciel pour traitement. Le flux résultant du moteur audio logiciel est ensuite envoyé au moteur audio matériel en tant que flux de processus hôte. Le flux de processus hôte est mélangé avec les n premiers flux, le traitement EFX est appliqué et le flux résultant est ensuite envoyé aux haut-parleurs.
Topologie de filtre KS
Dans Windows 8 et les systèmes d’exploitation ultérieurs, un moteur audio matériel intégré a été pris en charge pour traiter les flux audio. Lorsque vous développez un tel adaptateur audio, le pilote audio associé doit exposer ce fait au système audio en mode utilisateur d’une manière spécifique, afin que le système audio puisse découvrir, utiliser et exposer correctement les fonctionnalités de cet adaptateur et de son pilote.
Pour permettre aux pilotes audio d’exposer les fonctionnalités matérielles de ces nouvelles cartes audio, Windows 8 introduit une topologie de filtre KS que le pilote doit utiliser :
Comme indiqué dans la figure précédente, une topologie de filtre KS représente les chemins de données via le matériel, ainsi que les fonctions disponibles sur ces chemins. Dans le cas d’une carte audio qui peut traiter l’audio déchargé, il existe les entrées et sorties suivantes (appelées broches) sur le filtre KS :
Une broche processus hôte. Cela représente l’entrée dans le filtre KS à partir du moteur audio logiciel.
Une broche de bouclage. Cela représente une sortie du moteur audio matériel vers la couche DE L’API de session audio Windows (WASAPI).
Nombre de broches audio déchargées. Bien que la figure n’affiche qu’une seule broche de ce type, un IHV est libre d’implémenter n’importe quel nombre (n) de broches.
Le service réel dans le système audio en mode utilisateur qui « mène » à la découverte de l’adaptateur audio et de son pilote est l’AudioEndpointBuilder. Le service AudioEndpointBuilder surveille la classe KSCATEGORY_AUDIO pour les arrivées et les suppressions d’interface d’appareil. Lorsqu’un pilote de périphérique audio inscrit une nouvelle instance de la classe d’interface de périphérique KSCATEGORY_AUDIO, une notification d’arrivée de l’interface de périphérique est déclenchée. Le service AudioEndpointBuilder détecte la notification d’arrivée de l’interface d’appareil et utilise un algorithme pour examiner la topologie des périphériques audio dans le système afin qu’il puisse prendre les mesures appropriées.
Lorsque vous développez votre pilote audio pour prendre en charge un adaptateur capable de traiter l’audio déchargé, votre pilote doit utiliser le point de terminaison audio KSNODETYPE_AUDIO_ENGINE pour exposer les fonctionnalités du moteur audio matériel. Pour plus d’informations sur le processus de découverte de point de terminaison audio, consultez Algorithme du générateur de points de terminaison audio.
Considérations relatives à l’interface utilisateur
Vous avez développé votre pilote audio pour contrôler les fonctionnalités matérielles sous-jacentes d’un adaptateur audio capable de traiter l’audio déchargé. Cela signifie que votre pilote a les meilleures connaissances sur la façon de contrôler les fonctionnalités de l’adaptateur. Vous devez donc développer une interface utilisateur qui expose les fonctionnalités de l’adaptateur à l’utilisateur final sous la forme d’options qu’il peut sélectionner, activer et/ou désactiver.
Toutefois, si vous disposez déjà d’une interface utilisateur utilisée pour contrôler les objets de traitement audio (APO) que vous avez développés, cette interface utilisateur peut être étendue pour fonctionner avec votre nouvelle carte audio. Dans ce cas, vos extensions à l’interface utilisateur fournissent un contrôle logiciel pour les API et un contrôle matériel pour l’adaptateur.
Impact sur l’application
Les fonctionnalités décrites pour ce nouveau type de carte audio et son pilote associé peuvent être utilisées par les applications UWP via WASAPI, Media Foundation, Media Engine ou les balises audio> HTML 5<. Notez que Wave et DSound ne peuvent pas être utilisés, car ils ne sont pas disponibles pour les applications UWP. Notez également que les applications de bureau ne peuvent pas utiliser les fonctionnalités de déchargement des cartes audio qui prennent en charge l’audio déchargé par le matériel. Ces applications peuvent toujours restituer l’audio, mais uniquement via la broche hôte qui utilise le moteur audio logiciel.
Si une application UWP diffuse du contenu multimédia et utilise Media Foundation, Media Engine ou les balises audio> HTML 5<, l’application est automatiquement activée pour le déchargement matériel tant que la catégorie audio appropriée a été définie pour le flux. L’adhésion au déchargement du matériel est effectuée par flux.
Les applications UWP qui utilisent WASAPI ou les communications en streaming doivent explicitement accepter le déchargement matériel.