Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Le traitement audio déchargé sur le matériel permet d’effectuer les principales tâches de traitement audio en dehors du processeur principal de l’ordinateur.
Le traitement audio peut être très gourmand en calcul. Ainsi, dans de nombreux scénarios, il peut être utile de permettre à un processeur dédié de prendre en charge les tâches de traitement telles que, par exemple, le mélange 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 décrivent le développement de pilotes, 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 géré par le matériel
Interfaces d'aide pour le traitement audio délégué
Rapport de glitch pour l’audio déchargé
Pour plus d’informations sur les APO déchargées, consultez les effets APO déchargés matériels
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 WASAPI (Audio Session API) Windows, et éventuellement via une API de niveau supérieur, comme Media Foundation. Dans le logiciel des effets de flux du moteur audio (SFX), les effets peuvent être appliqués sur une base par flux avant que les flux distincts ne soient mélangés, puis passés à travers les éventuels effets de point de terminaison disponibles (EFX) et envoyés au matériel de rendu et aux haut-parleurs.
Moteur audio matériel
Le moteur audio matériel est implémenté dans la carte audio et reflète en grande partie les fonctionnalités du moteur audio logiciel. Et bien que Windows prenne en charge le traitement audio déchargé par le 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 illustré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 routés directement à partir de la couche d'application pour être traités dans le matériel. En d'autres termes, les flux déchargés ne passeront pas par le moteur audio logiciel. Le diagramme montre une implémentation conçue pour gérer jusqu’à trois flux déchargés. Le flux de processus hôte est la sortie finale du mixeur logiciel de tous les flux qui ont été traités dans le moteur audio logiciel. Chaque moteur audio matériel doit également intégrer un mélangeur 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 forme de flux de retour. Cela est particulièrement essentiel 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 responsable de l’exposition d’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é-encodage) est renvoyé. 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 du 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 matériel déchargé.
Architecture audio intégrée
Le diagramme suivant présente 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 premiers flux n (dans ce cas, trois) qui sont initialisés seront acheminés directement de la couche WASAPI vers le moteur audio matériel, en contournant le moteur audio logiciel. Tous les nouveaux flux audio qui suivent le n pris en charge par le moteur audio matériel sont routé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é aux premiers flux n, le traitement EFX est appliqué, et le flux résultant est ensuite envoyé aux haut-parleurs.
Topologie de filtre KS
Dans les systèmes d’exploitation Windows 8 et ultérieurs, la prise en charge a été ajoutée pour un moteur audio matériel intégré permettant de traiter les flux audio. Lorsque vous développez une telle carte audio, le pilote audio associé doit exposer ce fait au système audio en mode utilisateur de 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 a introduit une topologie de filtre KS que le pilote doit utiliser :
Comme illustré dans la figure précédente, une topologie de filtre KS représente les chemins de données via le matériel et montre également 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 du 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 WASAPI (Audio Session API) Windows.
Nombre de broches audio déchargées. Bien que la figure ne montre 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 du système audio en mode utilisateur qui « mène » à la découverte de l’adaptateur audio et de son pilote est audioEndpointBuilder. Le service AudioEndpointBuilder surveille la classe KSCATEGORY_AUDIO pour les arrivées et suppressions de l’interface d’appareil. Lorsqu’un pilote de périphérique audio inscrit une nouvelle instance de la classe d’interface d’appareil 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 de l’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 points de terminaison audio, consultez l’algorithme 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’une carte audio capable de traiter l’audio déchargé. Cela signifie que votre pilote a la meilleure connaissance de 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 (API) 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 le contrôle matériel de l’adaptateur.
Impact de 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 reproduire l’audio, mais uniquement par le biais de la broche hôte qui fait appel au 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 choisie pour le déchargement matériel tant que la catégorie audio appropriée a été définie pour le flux. Le fait d’opter pour le déchargement matériel est effectué par flux.
Les applications UWP qui utilisent WASAPI ou des communications en streaming doivent explicitement opter pour le déchargement matériel.