Composants audio en mode utilisateur

Les API audio principales servent de base au sous-système audio en mode utilisateur. Les API audio principales sont implémentées en tant que couche mince de composants système en mode utilisateur qui séparent les clients en mode utilisateur des pilotes audio en mode noyau et du matériel audio. Les API audio de niveau supérieur, telles que Media Foundation, accèdent aux appareils audio via les API audio principales. En outre, certaines applications audio communiquent directement avec les API audio principales.

Les API audio principales prennent en charge la notion conviviale d’un appareil de point de terminaison audio. Un appareil de point de terminaison audio est une abstraction logicielle qui représente un appareil physique que l’utilisateur manipule directement. Des exemples d’appareils de point de terminaison audio sont des haut-parleurs, des casques et des microphones. Pour plus d’informations, consultez Appareils de point de terminaison audio.

Le diagramme suivant montre les API audio principales et leur relation avec les autres composants audio en mode utilisateur.

Par souci de simplicité, le diagramme précédent montre uniquement un chemin de données de rendu audio vers l’appareil de point de terminaison. Le diagramme n’affiche pas de chemin de données de capture audio. Les API audio principales incluent l’API MMDevice, WASAPI, l’API DeviceTopology et l’API EndpointVolume, qui sont implémentées dans les modules système en mode utilisateur Audioses.dll et Mmdevapi.dll.

Les API audio principales fournissent une base pour les API de niveau supérieur, telles que Media Foundation, qui communiquent avec les API audio principales via son composant de convertisseur audio de streaming (SAR).

Un client de WASAPI transmet des données à un appareil de point de terminaison via une mémoire tampon de point de terminaison. Les composants logiciels et matériels système gèrent le déplacement des données de la mémoire tampon du point de terminaison vers l’appareil de point de terminaison d’une manière largement transparente pour le client. En outre, pour un appareil de point de terminaison qui se connecte à une carte audio avec détection de présence de jack, le client peut créer une mémoire tampon de point de terminaison uniquement pour un appareil de point de terminaison physiquement présent. Pour plus d’informations sur la détection de présence de jack, consultez Appareils de point de terminaison audio.

Le diagramme précédent montre deux types de mémoire tampon de point de terminaison. Si un client de WASAPI ouvre un flux en mode partagé partage, le client écrit des données audio dans la mémoire tampon du point de terminaison et le moteur audio Windows lit les données de la mémoire tampon. Dans ce mode, le client partage le matériel audio avec d’autres applications s’exécutant dans d’autres processus. Le moteur audio combine les flux de ces applications et lit la combinaison résultante via le matériel. Le moteur audio est un composant système en mode utilisateur (Audiodg.dll) qui effectue toutes ses opérations de traitement de flux dans les logiciels. En revanche, si un client ouvre un flux en mode exclusif, le client a un accès exclusif au matériel audio. En règle générale, seuls un petit nombre d’applications « audio pro » ou RTC nécessitent un mode exclusif. Bien que le diagramme montre à la fois les flux en mode partagé et en mode exclusif, seul l’un de ces deux flux (et sa mémoire tampon de point de terminaison correspondante) existe, selon que le client ouvre le flux en mode partagé ou en mode exclusif.

En mode exclusif, le client peut choisir d’ouvrir le flux dans n’importe quel format audio pris en charge par l’appareil de point de terminaison. En mode partagé, le client doit ouvrir le flux au format mix actuellement utilisé par le moteur audio (ou un format similaire au format mix). Les flux d’entrée du moteur audio et la combinaison de sorties du moteur sont tous au format suivant.

En mode faible latence, disponible pour les flux en mode partagé, le moteur audio s’exécute en mode pull, dans lequel il y a une réduction significative de la latence. Cela est utile pour les applications de communication qui nécessitent une faible latence de flux audio pour accélérer la diffusion en continu.

Les applications qui gèrent des flux audio à faible latence peuvent utiliser le service MMCSS (Multimedia Class Scheduler Service) pour augmenter la priorité des threads d’application qui accèdent aux mémoires tampons de point de terminaison. MMCSS permet aux applications audio de s’exécuter à priorité élevée sans refuser les ressources processeur à des applications de priorité inférieure. MMCSS affecte une priorité à un thread en fonction de son nom de tâche. Par exemple, les noms de tâches « Audio » et « Pro Audio » sont pris en charge pour les threads qui gèrent les flux audio. Par défaut, la priorité d’un thread « Pro Audio » est supérieure à celle d’un thread « Audio ». Pour plus d’informations sur MMCSS, consultez la documentation Windows SDK.

Les API audio principales prennent en charge les formats de flux PCM et non PCM. Toutefois, le moteur audio peut combiner uniquement des flux PCM. Ainsi, seuls les flux en mode exclusif peuvent avoir des formats non PCM. Pour plus d’informations, consultez Formats d’appareil.

Le moteur audio s’exécute dans son propre processus protégé, qui est distinct du processus dans lequel l’application s’exécute. Pour prendre en charge un flux en mode partagé, le service audio Windows (la zone intitulée « Service audio » dans le diagramme précédent) alloue une mémoire tampon de point de terminaison interprocesseur accessible à la fois à l’application et au moteur audio. Pour le mode exclusif, la mémoire tampon de point de terminaison réside dans la mémoire accessible à la fois à l’application et au matériel audio.

Le service audio Windows est le module qui implémente Windows stratégie audio. La stratégie audio est un ensemble de règles internes que le système applique aux interactions entre les flux audio provenant de plusieurs applications qui partagent et concurrencent l’utilisation du même matériel audio. Le service audio Windows implémente la stratégie audio en définissant les paramètres de contrôle du moteur audio. Les tâches du service audio sont les suivantes :

• Effectuez le suivi des périphériques audio auxquels l’utilisateur ajoute ou supprime du système.
• Surveillance des rôles attribués aux périphériques audio dans le système.
• Gestion des flux audio à partir de groupes de tâches qui produisent des classes similaires de contenu audio (console, multimédia et communications).
• Contrôle du niveau de volume du flux de sortie combiné (« submix ») pour chacun des différents types de contenu audio.
• Informez le moteur audio sur les éléments de traitement dans les chemins de données des flux audio.

Dans certaines versions de Windows, le service audio Windows est désactivé par défaut et doit être activé explicitement avant que le système puisse lire l’audio.

Dans l’exemple présenté dans le diagramme précédent, l’appareil de point de terminaison est un ensemble de haut-parleurs connectés à la carte audio. L’application cliente écrit des données audio dans la mémoire tampon du point de terminaison, et le moteur audio gère les détails du transport des données de la mémoire tampon vers l’appareil de point de terminaison.

La zone intitulée « Pilote audio » dans le diagramme précédent peut être une combinaison de composants de pilotes fournis par le système et fournis par le fournisseur. Dans le cas d’une carte audio sur un bus PCI ou PCI Express, le système fournit le pilote système de classe de port (Portcls.sys), qui implémente un ensemble de pilotes de port pour les différentes fonctions audio de la carte, et le fournisseur de matériel fournit un pilote d’adaptateur qui implémente un ensemble de pilotes miniport pour gérer les opérations spécifiques aux périphériques pour les pilotes de port. Dans le cas d’un contrôleur audio haute définition et d’un codec sur un bus PCI ou PCI Express, le système fournit le pilote de l’adaptateur (Hdaudio.sys) et aucun pilote fourni par le fournisseur n’est nécessaire. Dans le cas d’une carte audio sur un bus USB, le système fournit le pilote système de classe AVStream (Ks.sys) ainsi que le pilote audio USB (Usbaudio.sys) ; là encore, aucun pilote fourni par le fournisseur n’est nécessaire.

Par souci de simplicité, le diagramme précédent montre uniquement les flux de rendu. Toutefois, les API audio principales prennent également en charge les flux de capture. En mode partagé, plusieurs clients peuvent partager le flux capturé à partir d’un périphérique matériel audio. En mode exclusif, un client a un accès exclusif au flux capturé à partir de l’appareil.

Rubriques connexes

Guide de programmation