Vue d’ensemble des extensions de classe audio ACX

Article
05/03/2024

Cette rubrique fournit un résumé de haut niveau des extensions de classe audio ACX.

L’infrastructure ACX est basée sur l’infrastructure du pilote Windows

Pour permettre aux pilotes audio d’être plus fiables et d’offrir la meilleure expérience possible pour les utilisateurs de PC, audio class eXtension (ACXtension) est désormais disponible en préversion anticipée. ACX définit une nouvelle extension de classe WDF (Windows Driver Framework) pour le domaine audio. Pour plus d’informations sur WDF, consultez Présentation des objets Framework. De nombreux concepts WDF, tels que les cibles d’E/S WDF, sont disponibles dans ACX. Pour plus d’informations sur les cibles d’E/S WDF, consultez Présentation des cibles d’E/S.

ACX est créé à l’aide de l’infrastructure kmDF (Kernel Mode Driver Framework) et non de l’infrastructure de pilote en mode utilisateur (UMDF) pour éviter toute latence associée au basculement de tâche plusieurs fois entre l’utilisateur et le mode noyau lors de la diffusion en continu. Les pilotes audio de liste de ports, le modèle hérité actuel, sont wdM, les pilotes basés sur le mode noyau.

L’utilisation de l’infrastructure ACX facilite la création de pilotes audio de travail « prêtes à l’emploi ». Par exemple, ACX prend en charge la saisie semi-automatique par défaut pour la plupart de ses paramètres. Cela facilite l’utilisation du paramètre correct par le pilote, mais permet toujours la personnalisation.

L’infrastructure ACX expose des concepts audio en tant qu’objets WDF avec lesquels le pilote peut interagir (flux, format, etc.). Cela permet une expérience de programmation cohérente et permet à une plus grande communauté de développeurs de pilotes audio.

Remarque

Les en-têtes et bibliothèques ACX ne sont pas inclus dans la version WDK 10.0.22621.2428 (publiée le 24 octobre 2023), mais sont disponibles dans les versions précédentes, ainsi que les dernières versions (25000) Insider Preview de wdK. Pour plus d’informations sur les préversions de WDK, consultez Installation des versions préliminaires du Kit de pilotes Windows (WDK).

Objectifs ACX

Les extensions de classe audio (ACX) ont les objectifs suivants.

Simplifiez l’effort et le savoir-faire requis pour développer des pilotes audio autonomes simples.
Réduisez la quantité de code qu’un tiers doit développer. Moins de lignes de code diminuent la maintenance et facilitent le débogage.
Permet aux clients en mode utilisateur supérieur (services et applications) existants d’être exécutés comme c’est le cas.
Simplifiez la gestion de power-pnp des pilotes de pile audio.
Aucun impact sur les performances globales, c’est-à-dire aucune latence supplémentaire/notable.
Simplifiez l’effort nécessaire pour développer multi-pile pilotes audio.
Autoriser le pilote tiers à spécifier le mécanisme de verrouillage à utiliser lors de la diffusion en continu.
Utilise la solution d’isolation du déploiement de composants Microsoft qui rend les modules pilotes/API autonomes et réutilisables.

Architecture ACX

Ce diagramme illustre l’architecture ACX montrant les applications en mode utilisateur et les objets ACX existants en mode noyau et matériel audio en bas de la pile. Outre les objets ACX, le développeur du pilote a accès aux objets WDF pour tirer parti de son code de pilote, par exemple pour la gestion de l’alimentation.

Diagramme illustrant l’architecture ACX, montrant le mode utilisateur et noyau avec des objets WDF et ACX en mode noyau et du matériel audio en bas de la pile.

Coexistence ACX avec des pilotes audio existants

ACX est conçu pour coexister avec les pilotes audio existants afin de permettre une migration flexible vers de nouveaux pilotes ACX.

La compatibilité binaire des pilotes de miniport audio (basés sur WDM) inchangés est maintenue par les pilotes de classe Windows hérités existants.
Seul le streaming basé sur WaveRT est actuellement pris en charge par ACX.
Les listes de contrôle d’accès héritées/Ks et les nouvelles piles ACX s’exécutent côte à côte. L’utilisation d’ACX ne force pas les tiers à porter leurs pilotes audio actuels vers le nouveau modèle. Comme le modèle offre de nombreux avantages, les 3ème parties peuvent choisir volontairement de l’utiliser pour leur développement audio futur.

Définitions courantes ACX

Circuit : composant de pilote représentant un chemin audio partiel ou complet. Le circuit représente un point de terminaison existant et ses fonctionnalités.

Stream : composant de pilote créé pour représenter un flux audio, créé par un circuit. Le flux est composé d’une liste d’éléments créés en fonction des éléments du circuit parent.

Circuit de flux : le circuit dans une architecture multi-pile (chemin audio partiel) qui interface directement avec le service de streaming en mode utilisateur supérieur.

Circuit principal : 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 fonctionnalité audio du matériel de soulignement. Il peut s’agir d’un élément Volume, Mute ou Jack, ou d’un élément Module sur un circuit DSP, etc.

Chemin audio du point de terminaison : un seul ou un groupe d’objets circuit connectés ensemble pour représenter un point de terminaison audio unique. Les objets Circuit doivent provenir de différentes piles d’appareils appartenant aux mêmes pilotes ou différents.

Résumé des objets ACX

Pour obtenir un résumé des objets ACX de base, consultez Résumé des objets ACX.

Exemple de pilote ACX

Un simple exemple de pilote ACX est disponible pour afficher et télécharger sur GitHub dans la branche de développement - https://github.com/microsoft/Windows-driver-samples/tree/develop/audio/Acx/Samples.

Driver Verifier

L’utilisation du vérificateur de pilotes est encouragée pour tous les pilotes Windows, y compris les pilotes ACX. Utilisez le vérificateur de pilote pour faire apparaître des erreurs latentes, réduire la consommation d’énergie et augmenter la fiabilité de votre pilote. Pour plus d’informations, consultez Type de débogage.

Communications croisées standardisées par le pilote MULTI-pile ACX

Il est courant que le chemin audio passe par plusieurs composants matériels gérés par différentes piles de pilotes pour créer une expérience audio complète. Il est courant qu’un système dispose des fonctionnalités DSP, CODEC et AMP implémentées par différents fournisseurs de technologies audio.

Dans une architecture multi-pile sans norme bien définie, chaque fournisseur est obligé de définir son propre protocole d’interface et de communication propriétaire. Il s’agit d’un objectif d’ACX pour faciliter le développement de pilotes audio multi-pile en prenant possession de la synchronisation entre ces piles et en fournissant un modèle simple réutilisable pour les pilotes communiquer entre eux.

Pour plus d’informations, consultez communications entre pilotes multi stack ACX.