Pilotes USB Audio 2.0
À compter de Windows 10 version 1703, un pilote USB Audio 2.0 est fourni avec Windows. Il est conçu pour prendre en charge la classe d’appareils USB Audio 2.0. Le pilote est un miniport de classe de port audio WaveRT.
Le pilote est nommé : usbaudio2.sys et le fichier inf associé est usbaudio2.inf.
Dans le gestionnaire de périphériques, le pilote s’identifiera comme « Périphérique AUDIO USB de classe 2 ». Ce nom est remplacé par une chaîne de produit USB, s’il est disponible.
Le pilote est automatiquement activé lorsqu’un appareil compatible est attaché au système. Toutefois, si un pilote tiers existe sur le système ou le Windows Update, ce pilote sera installé et remplacera le pilote de classe.
Architecture
Le pilote usbaudio2.syss’intègre dans l’architecture plus large de Windows USB Audio, comme indiqué.
Spécifications USB associées
Les spécifications USB suivantes définissent l’audio USB et sont référencées dans cet article.
- USB-2 fait référence à la spécification du bus série universel, révision 2.0
- ADC-2 fait référence à la définition de classe de périphérique USB pour les périphériques audio, version 2.0.
- OGF-2 fait référence à la spécification Des formats de données audio, version 2.0.
L’USB-IF est un groupe d’intérêt spécial qui gère les spécifications, les spécifications de test et les outils officiels de l’USB.
Formats audio
Le pilote prend en charge les formats répertoriés ci-dessous. Un autre paramètre, qui spécifie un autre format défini dans OGF-2, ou un format inconnu, est ignoré.
Formats de type I (OGF-2 2.3.1) :
- Format PCM avec 8..32 bits par échantillon (OGF-2 2.3.1.7.1)
- Format PCM8 (OGF-2 2.3.1.7.2)
- Format IEEE_FLOAT (OGF-2 2.3.1.7.3)
Formats de type III (OGF-2 2.3.3 et A.2.3) :
- IEC61937_AC-3
- IEC61937_MPEG-2_AAC_ADTS
- IEC61937_DTS-I
- IEC61937_DTS-II
- IEC61937_DTS-III
- TYPE_III_WMA
Description des fonctionnalités
Cette section décrit les fonctionnalités du pilote USB Audio 2.0.
Topologie de fonction audio
Le pilote prend en charge tous les types d’entités définis dans ADC-2 3.13.
Chaque entité de terminal doit disposer d’une connexion d’horloge valide dans un matériel USB Audio 2.0 compatible. Le chemin d’horloge peut éventuellement inclure des unités de multiplicateur d’horloge et de sélecteur d’horloge et doit se terminer par une entité source d’horloge.
Le pilote ne prend en charge qu’une seule source d’horloge. Si un appareil implémente plusieurs entités sources d’horloge et un sélecteur d’horloge, le pilote utilise la source d’horloge sélectionnée par défaut et ne modifie pas la position du sélecteur d’horloge.
Une unité de traitement (ADC-2 3.13.9) avec plusieurs broches d’entrée n’est pas prise en charge.
Une unité d’extension (ADC-2 3.13.10) avec plusieurs broches d’entrée n’est pas prise en charge.
Les chemins cycliques dans la topologie ne sont pas autorisés.
Streaming audio
Le pilote prend en charge les types de synchronisation de point de terminaison suivants (USB-2 5.12.4.1) :
- IN et OUT asynchrones
- IN et OUT synchrones
- IN et OUT adaptatifs
Pour le cas out asynchrone, le pilote prend uniquement en charge les commentaires explicites. Un point de terminaison de commentaires doit être implémenté dans l’autre paramètre respectif de l’interface AS. Le pilote ne prend pas en charge les commentaires implicites.
Actuellement, la prise en charge des appareils utilisant une horloge partagée pour plusieurs points de terminaison est limitée.
Pour le cas Adaptive IN, le pilote ne prend pas en charge un point de terminaison de transfert de flux. Si un tel point de terminaison est présent dans l’autre paramètre, il est ignoré. Le pilote gère le flux IN adaptatif de la même façon qu’un flux IN asynchrone.
La taille des paquets isochrone créés par l’appareil doit être dans les limites spécifiées dans OGF-2.0 section 2.3.1.1. Cela signifie que l’écart entre la taille réelle du paquet et la taille nominale ne doit pas dépasser +/- un emplacement audio (emplacement audio = échantillons de nombre de canaux).
Descripteurs
Une fonction audio doit implémenter exactement un descripteur d’interface AudioControl (ADC-2 4.7) et un ou plusieurs descripteurs d’interface AudioStreaming (ADC-2 4.9). Une fonction avec une interface de contrôle audio, mais aucune interface de streaming n’est prise en charge.
Le pilote prend en charge tous les types de descripteurs définis dans ADC-2, section 4. Les sous-sections suivantes fournissent des commentaires sur certains types de descripteurs spécifiques.
Descripteur d’interface AS Class-Specific
Pour plus d’informations sur cette spécification, consultez ADC-2 4.9.2.
Un descripteur d’interface AS doit commencer par un autre paramètre zéro sans point de terminaison (aucune consommation de bande passante) et d’autres paramètres doivent être spécifiés dans l’ordre croissant dans le matériel USB Audio 2.0 compatible.
Un autre paramètre dont le format n’est pas pris en charge par le pilote est ignoré.
Chaque autre paramètre différent de zéro doit spécifier un point de terminaison de données isochrone et éventuellement un point de terminaison de commentaires. Un autre paramètre autre que zéro sans point de terminaison n’est pas pris en charge.
Le champ bTerminalLink doit faire référence à une entité terminale dans la topologie et sa valeur doit être identique dans tous les autres paramètres d’une interface AS.
Le champ bFormatType dans le descripteur d’interface AS doit être identique à bFormatType spécifié dans le descripteur de type format (OGF-2 2.3.1.6).
Pour les formats de type I, un seul bit doit être défini sur un dans le champ bmFormats du descripteur d’interface AS. Sinon, le format sera ignoré par le pilote.
Pour économiser la bande passante du bus, une interface AS peut implémenter plusieurs paramètres alternatifs avec le même format (en termes de bNrChannels et de descripteur de type de format AS), mais des valeurs wMaxPacketSize différentes dans le descripteur de point de terminaison de données isochronous. Pour un taux d’échantillonnage donné, le pilote sélectionne l’autre paramètre avec le plus petit wMaxPacketSize qui peut répondre aux exigences de débit de données.
Descripteur de type format I
Pour plus d’informations sur cette spécification, reportez-vous à OGF-2 2.3.1.6.
Les restrictions suivantes s’appliquent :
| Format | Taille du sous-lot | Résolution de bits |
|---|---|---|
| Format PCM de type I : | 1 <= bSubslotSize <= 4 | 8 <= bBitResolution <= 32 |
| Format PCM8 de type I : | bSubslotSize == 1 | bBitResolution == 8 |
| Type I IEEE_FLOAT format : | bSubslotSize == 4 | bBitResolution == 32 |
| Formats de IEC61937 de type III : | bSubslotSize == 2 | bBitResolution == 16 |
Class-Specific AS descripteur de point de terminaison de données audio isochronous
Pour plus d’informations sur cette spécification, consultez ADC-2 4.10.1.2.
L’indicateur MaxPacketsOnly dans le champ bmAttributes n’est pas pris en charge et sera ignoré.
Les champs bmControls, bLockDelayUnits et wLockDelay sont ignorés.
Demandes de classe et messages de données d’interruption
Le pilote prend en charge un sous-ensemble des demandes de contrôle définies dans ADC-2, section 5.2, et prend en charge les messages de données d’interruption (ADC-2 6.1) pour certains contrôles. Le tableau suivant montre le sous-ensemble implémenté dans le pilote.
| Entité | Control | OBTENIR LA CUR | SET CUR | GET RANGE | INTERROMPRE |
|---|---|---|---|---|---|
| Source d’horloge | Contrôle de fréquence d’échantillonnage | x | x | x | |
| Sélecteur d’horloge | Contrôle du sélecteur d’horloge | x | |||
| Multiplicateur d’horloge | Contrôle numérateur | x | |||
| Contrôle de dénominateur | x | ||||
| Terminal | Contrôle du connecteur | x | x | ||
| Unité de mélangeur | Contrôle du mélangeur | x | x | x | |
| Unité de sélecteur | Contrôle sélecteur | x | x | ||
| Unité de fonctionnalité | Désactiver le contrôle | x | x | x | |
| Contrôle du volume | x | x | x | x | |
| Contrôle automatique des gains | x | x | |||
| Unité d’effet | – | ||||
| Unité de traitement | – | ||||
| Unité d’extension | – |
Des informations supplémentaires sur les contrôles et les demandes sont disponibles dans les sous-sections suivantes.
Entité source d’horloge
Pour plus d’informations sur cette spécification, reportez-vous à ADC-2 5.2.5.1.
Au minimum, une entité source d’horloge doit implémenter des requêtes GET RANGE et GET CUR de contrôle de fréquence d’échantillonnage (ADC-2 5.2.5.1.1) dans le matériel USB Audio 2.0 compatible.
La requête GET RANGE du contrôle de fréquence d’échantillonnage retourne une liste de sous-plages (ADC-2 5.2.1). Chaque sous-plage décrit une fréquence discrète, ou une plage de fréquences. Une fréquence d’échantillonnage discrète doit être exprimée en définissant les champs MIN et MAX sur la fréquence respective et RES sur zéro. Les sous-plages individuelles ne doivent pas se chevaucher. Si une sous-plage chevauche une précédente, elle est ignorée par le pilote.
Une entité source d’horloge qui implémente une seule fréquence fixe n’a pas besoin d’implémenter SET CUR de contrôle de fréquence d’échantillonnage. Elle implémente GET CUR, qui retourne la fréquence fixe, et elle implémente GET RANGE, qui signale une seule fréquence discrète.
Entité sélecteur d’horloge
Pour plus d’informations sur cette spécification, consultez ADC-2 5.2.5.2.
Le pilote USB Audio 2.0 ne prend pas en charge la sélection de l’horloge. Le pilote utilise l’entité source de l’horloge, qui est sélectionnée par défaut et n’émet jamais de requête SET CUR du sélecteur d’horloge. La requête GET CUR du contrôle du sélecteur d’horloge (ADC-2 5.2.5.2.1) doit être implémentée dans le matériel USB Audio 2.0 compatible.
Unité de fonctionnalité
Pour plus d’informations sur cette spécification, consultez ADC-2 5.2.5.7.
Le pilote prend en charge une seule plage de volumes. Si la requête GET RANGE du contrôle de volume retourne plusieurs plages, les plages suivantes sont ignorées.
L’intervalle de volume exprimé par les champs MIN et MAX doit être un multiple entier de la taille d’étape spécifiée dans le champ RES.
Si une unité de fonctionnalité implémente des contrôles à canal unique et un contrôle master pour Mute ou Volume, le pilote utilise les contrôles de canal unique et ignore le contrôle master.
Informations supplémentaires pour les OEM et les IHVs
Les oem et les IHVs doivent tester leurs appareils existants et nouveaux par rapport au pilote intégré fourni.
Aucune personnalisation de partenaire spécifique n’est associée au pilote USB Audio 2.0 intégré.
Cette entrée de fichier INF (fournie dans une mise à jour de Windows Version 1703) est utilisée pour identifier que le pilote intégré est un pilote de périphérique générique.
GenericDriverInstalled,,,,1
Le pilote in-box s’inscrit pour les ID compatibles suivants avec usbaudio2.inf.
USB\Class_01&SubClass_00&Prot_20
USB\Class_01&SubClass_01&Prot_20
USB\Class_01&SubClass_02&Prot_20
USB\Class_01&SubClass_03&Prot_20
Consultez la spécification USB Audio 2.0 pour les types de sous-classe.
Les périphériques AUDIO USB 2.0 avec MIDI (sous-classe 0x03 ci-dessus) énumèrent la fonction MIDI en tant que périphérique multi-fonction distinct avec usbaudio.sys (pilote USB Audio 1.0) chargé.
Le pilote de classe USB Audio 1.0 enregistre cet ID compatible avec wdma_usb.inf.
USB\Class_01
Et a les exclusions suivantes :
USB\Class_01&SubClass_00&Prot_20
USB\Class_01&SubClass_01&Prot_20
USB\Class_01&SubClass_02&Prot_20
USB\Class_01&SubClass_03&Prot_20
Un nombre arbitraire de canaux (supérieur à huit) n’est pas pris en charge en mode partagé en raison d’une limitation de la pile audio Windows.
Pilotes et mises à jour IHV USB Audio 2.0
Pour les pilotes USB Audio 2.0 fournis par IHV tiers, ces pilotes continueront d’être préférés pour leurs appareils par rapport à notre pilote intégré, sauf s’ils mettent à jour leur pilote pour remplacer explicitement ce comportement et utiliser le pilote intégré.
Descriptions du registre Audio Jack
À compter de Windows 10 version 1703, les IMV qui créent des appareils USB Audio Class 2.0 dotés d’une ou plusieurs prises jack ont la possibilité de décrire ces prises au pilote de la classe Audio 2.0 intégrée. Le pilote intégré utilise les informations jack fournies lors de la gestion des KSPROPERTY_JACK_DESCRIPTION pour cet appareil.
Les informations jack sont stockées dans le Registre dans la clé instance de l’appareil (clé HW).
Ce qui suit décrit les paramètres d’informations de la prise audio dans le Registre :
REG_DWORD T<tid>_NrJacks # of the jack on this device
REG_DWORD T<tid>_J<n>_ChannelMapping Channel mask. The value is defined in ksmedia.h. e.g. SPEAKER_FRONT_RIGHT or KSAUDIO_SPEAKER_5POINT1_SURROUND
REG_DWORD T<tid>_J<n>_ConnectorType The enum value is define in EPcxConnectionType.
REG_DWORD T<tid>_J<n>_GeoLocation The enum value is define in EPcxGeoLocation.
REG_DWORD T<tid>_J<n>_GenLocation The enum value is define in EPcxGenLocation.
REG_DWORD T<tid>_J<n>_PortConnection The enum value is define in EPxcPortConnection.
REG_DWORD T<tid>_J<n>_Color The color needs to be represent by RGB like this: 0x00RRGGBB (NOT a COLORREF).
<tid> = ID de terminal (tel que défini dans le descripteur)
<n> = Nombre jack (1 ~ n).
La convention pour <la tid> et <n> est :
- Base 10 (8, 9, 10 plutôt que 8, 9, a)
- Aucun zéro de début
- n est basé sur 1 (le premier jack est jack 1 plutôt que jack 0)
Par exemple :
T1_NrJacks, T1_J2_ChannelMapping, T1_J2_ConnectorType
Pour plus d’informations sur la prise audio, consultez KSJACK_DESCRIPTION structure.
Ces valeurs de Registre peuvent être définies de différentes manières :
En utilisant des INF personnalisées, qui encapsulent l’INF dans la boîte de dialogue afin de définir ces valeurs.
Directement par le périphérique matériel via un descripteur de système d’exploitation Microsoft pour les périphériques USB (voir l’exemple ci-dessous). Pour plus d’informations sur la création de ces descripteurs, consultez Descripteurs de système d’exploitation Microsoft pour les périphériques USB.
Exemple de descripteurs de système d’exploitation Microsoft pour USB
L’exemple suivant descripteurs de système d’exploitation Microsoft pour USB contient le mappage de canal et la couleur d’une prise jack. L’exemple concerne un appareil non composite avec un descripteur de caractéristique unique.
Le fournisseur IHV doit l’étendre pour contenir d’autres informations pour la description de la prise jack.
UCHAR Example2_MSOS20DescriptorSetForUAC2 [0x76] = {
//
// Microsoft OS 2.0 Descriptor Set Header
//
0x0A, 0x00, // wLength - 10 bytes
0x00, 0x00, // MSOS20_SET_HEADER_DESCRIPTOR
0x00, 0x00, 0x0?, 0x06, // dwWindowsVersion – 0x060?0000 for future Windows version
0x76, 0x00, // wTotalLength – 118 bytes // update later
//
// Microsoft OS 2.0 Registry Value Feature Descriptor
//
0x42, 0x00, // bLength - 66 bytes
0x04, 0x00, // wDescriptorType – 5 for Registry Property
0x04, 0x00, // wPropertyDataType - 4 for REG_DWORD
0x34, 0x00, // wPropertyNameLength – 52 bytes
0x54, 0x00, 0x30, 0x00, // Property Name - "T01_J01_ChannelMapping"
0x31, 0x00, 0x5f, 0x00,
0x4a, 0x00, 0x30, 0x00,
0x31, 0x00, 0x5f, 0x00,
0x43, 0x00, 0x68, 0x00,
0x61, 0x00, 0x6e, 0x00,
0x6e, 0x00, 0x65, 0x00,
0x6c, 0x00, 0x4d, 0x00,
0x61, 0x00, 0x70, 0x00,
0x70, 0x00, 0x69, 0x00,
0x6e, 0x00, 0x67, 0x00,
0x00, 0x00
0x04, 0x00, // wPropertyDataLength – 4 bytes
0x02, 0x00, 0x00, 0x00 // PropertyData - SPEAKER_FRONT_RIGHT
//
// Microsoft OS 2.0 Registry Value Feature Descriptor
//
0x2A, 0x00, // bLength - 42 bytes
0x04, 0x00, // wDescriptorType – 5 for Registry Property
0x04, 0x00, // wPropertyDataType - 4 for REG_DWORD
0x1C, 0x00, // wPropertyNameLength – 28 bytes
0x54, 0x00, 0x30, 0x00, // Property Name - "T01_J01_Color"
0x31, 0x00, 0x5f, 0x00,
0x4a, 0x00, 0x30, 0x00,
0x31, 0x00, 0x5f, 0x00,
0x43, 0x00, 0x6f, 0x00,
0x6c, 0x00, 0x6f, 0x00,
0x72, 0x00, 0x00, 0x00,
0x04, 0x00, // wPropertyDataLength – 4 bytes
0x00, 0x00, 0xff, 0x00 // PropertyData - 0xff0000 - RED }
Dépannage
Si le pilote ne démarre pas, le journal des événements système doit être vérifié. Le pilote journalise les événements qui indiquent la raison de l’échec. De même, les journaux audio peuvent être collectés manuellement en suivant les étapes décrites dans l’article du journal web de Matthew van Eerde, Collecte des journaux audio à l’ancienne. Si l’échec peut indiquer un problème de pilote, signalez-le à l’aide du hub de commentaires décrit ci-dessous et incluez les journaux.
Pour plus d’informations sur la lecture des journaux pour le pilote de classe USB Audio 2.0 à l’aide de fichiers TMF supplémentaires, consultez Signaler des problèmes avec les journaux et suggérer des fonctionnalités avec le Hub de commentaires sur le journal web de Matthew van Eerde. Pour plus d’informations générales sur l’utilisation des fichiers TMF, consultez Affichage d’un journal de suivi avec un fichier TMF.
Pour plus d’informations sur l’erreur « Les services audio ne répondent pas » et que le périphérique audio USB ne fonctionne pas dans Windows 10 version 1703, consultez l’article Audio USB non en lecture.
Hub de commentaires
Si vous rencontrez un problème avec ce pilote, collectez les journaux audio, puis suivez les étapes décrites dans Signaler des problèmes, avec des journaux et suggérer des fonctionnalités, avec le Hub de commentaires pour attirer notre attention.
Développement de pilotes
Ce pilote de classe USB Audio 2.0 a été développé par Thesycon et est pris en charge par Microsoft.