Vue d’ensemble des extensions de classe audio ACX
Cette rubrique fournit un résumé de haut niveau des extensions de classe audio ACX.
Le cadre ACX est construit au-dessus du cadre des pilotes Windows
Pour permettre aux pilotes audio d'être plus fiables et d'offrir la meilleure expérience possible aux utilisateurs de PC, l'extension de classe audio (ACX) est désormais disponible. ACX définit une extension de classe du Windows Driver Framework (WDF) pour le domaine audio. Pour plus d’informations sur WDF, veuillez consulter la section Présentation de Framework Objects. De nombreux concepts WDF, tels que les cibles WDF IO, sont disponibles dans ACX. Pour plus d’informations sur les cibles IO WDF, veuillez consulter la section Présentation des cibles d’E/S.
ACX est construit en utilisant le Kernel Mode Driver Framework (KMDF) et non le User Mode Driver Framework (UMDF) afin d'éviter toute latence associée au passage multiple du mode utilisateur au mode noyau pendant la lecture en continu. Les pilotes audio de Portcls, le modèle actuel, sont des pilotes WDM, basés sur le mode noyau.
L'utilisation du cadre ACX facilite la création de pilotes audio fonctionnels "prêts à l'emploi". Par exemple, ACX prend en charge la complétion par défaut de la plupart de ses paramètres. Il est ainsi plus facile pour le pilote d'utiliser les paramètres corrects, tout en permettant la personnalisation.
Le cadre ACX expose les concepts audio sous forme d'objets WDF avec lesquels le pilote peut interagir (flux, format, etc.). Cela permet une expérience de programmation cohérente et une plus grande communauté de développeurs de pilotes audio.
Objectifs de l'ACX
Les extensions de classe audio (ACX) ont les objectifs suivants.
- Simplifier les efforts et le savoir-faire nécessaires au développement de pilotes audio autonomes simples.
- Réduire la quantité de code qu'un tiers doit développer. La réduction du nombre de lignes de code diminue la maintenance et facilite le débogage.
- Permettre aux clients existants en mode utilisateur supérieur (services et applications) de fonctionner tels quels.
- Simplifier la gestion power-pnp des pilotes de la pile audio.
- Pas d'impact sur les performances globales, c'est-à-dire pas de latence supplémentaire/perceptible.
- Simplifier l'effort requis pour développer des pilotes audio multi-piles.
- Permet au pilote tiers de spécifier le mécanisme de verrouillage à utiliser lors de la diffusion en continu.
- Utilise la solution d'isolation du déploiement des composants de Microsoft, qui rend les modules des pilotes/APO autonomes et réutilisables.
Architecture de ACX
Ce diagramme illustre l'architecture ACX avec les applications existantes en mode utilisateur et les objets ACX en mode noyau et le matériel audio en bas de la pile. En plus des objets ACX, le développeur du pilote a accès aux objets WDF dont il peut tirer parti dans le code de son pilote, par exemple pour la gestion de l'alimentation.
Coexistence de l'ACX avec les pilotes audio existants
ACX est conçu pour coexister avec les pilotes audio existants, afin de permettre une migration souple vers les nouveaux pilotes ACX.
- La compatibilité binaire des pilotes de miniport audio existants et inchangés (basés sur WDM) est maintenue par les pilotes de classe Windows existants.
- Seul le streaming basé sur WaveRT est actuellement pris en charge par ACX.
- Les anciens PortCls/Ks et les nouvelles piles ACX fonctionnent côte à côte. L'utilisation d'ACX n'oblige pas les tiers à porter leurs pilotes audio actuels sur le nouveau modèle. Comme le modèle offre de nombreux avantages, les tiers peuvent volontairement choisir de l'utiliser pour leurs futurs développements audio.
Définitions courantes de l'ACX
Circuit - Un composant pilote représentant un chemin audio partiel ou complet. Le circuit représente un point de terminaison existant et ses capacités.
Stream - Composant pilote créé pour représenter un flux audio, créé par un circuit. Le flux est composé d'une liste d'éléments créés sur la base des éléments du circuit parent.
Circuit de flux - circuit d'une architecture multi-pile (chemin audio partiel) qui est directement interfacé avec un service de diffusion en continu en mode utilisateur supérieur.
Circuit de base - Le circuit dans une architecture multi-pile (chemin audio partiel) qui donne l'identité de l'appareil de point de terminaison audio.
Élément - Sous-composant d'un circuit ou d'un flux, représentant une capacité audio du matériel sous-jacent. Il peut s'agir d'un élément de volume, de sourdine ou de prise, ou d'un élément de module sur un circuit DSP, etc.
Chemin audio de terminaison - Un seul ou un groupe d'objets Circuit connectés ensemble pour représenter un seul point de terminaison audio. Les objets Circuit doivent provenir de différentes piles d'appareils appartenant au même pilote ou à des pilotes différents.
Résumé des objets ACX
Pour un résumé des objets ACX de base, voir Résumé des objets ACX.
Exemple de pilote ACX
Un exemple simple de pilote ACX est disponible à la visualisation et au téléchargement sur GitHub dans la branche develop - https://github.com/microsoft/Windows-driver-samples/tree/main/audio/Acx/Samples.
Driver Verifier
L'utilisation de driver verifier est encouragée pour tous les pilotes Windows, y compris les pilotes ACX. Utilisez driver verifier pour remonter à la surface des erreurs latentes, diminuer la consommation d'énergie et augmenter la fiabilité de votre pilote. Pour plus d’informations, consultez Type de débogage.
Pilote ACX Multi-stack standardisé pour les communications croisées
Il est courant que le chemin audio passe par plusieurs composants matériels gérés par différentes piles de pilotes afin de créer une expérience audio complète. Il est typique pour un système d'avoir le DSP, le CODEC et la fonctionnalité AMP implémentés par différents fournisseurs de technologie audio.
Dans une architecture multi-piles sans norme bien définie, chaque fournisseur est obligé de définir sa propre interface et son propre protocole de communication. L'objectif d'ACX est de faciliter le développement de pilotes audio multi-piles en prenant en charge la synchronisation entre ces piles et en fournissant un modèle simple et réutilisable pour que les pilotes communiquent entre eux.
Pour plus d'informations, consultez la section ACX multi stack cross driver communications.
Documentation de référence de l’ACX
Pour plus d'informations sur la documentation de référence ACX au niveau de l'en-tête, consultez la documentation de référence ACX.
Voir aussi
Documentation de référence de l’ACX
Informations sur la version de l'ACX
Journalisation et débogage ACX
Cibles ACX et synchronisation des pilotes
IRP de paquet de requête d’E/S ACX