Bluetooth Low Energy (LE) Audio

Cet article fournit une vue d’ensemble de Bluetooth LE Audio introduit dans Windows 11 version 22H2 (KB5026446).

Présentation

Bluetooth LE Audio permet la diffusion d'audio unicast ou broadcast vers des appareils Bluetooth LE via un transport isochrone. Depuis la version 5.3 de la spécification de base Bluetooth, il n’existe aucune interface de contrôleur hôte définie standard (HCI) pour que les plateformes hôtes envoient et reçoivent des données isochrones vers et depuis le contrôleur Bluetooth. Ce document définit le chemin d’accès audio spécifique du fournisseur Bluetooth Windows (VSAP) pour permettre aux plateformes d’utiliser des solutions spécifiques au fournisseur pour activer le streaming audio Bluetooth LE. L’interface logicielle VSAP utilise des extensions de classe audio Windows (ACX) et d’autres propriétés d’interface définies dans ce document.

Terminologie et prérequis

Outre les termes définis dans ce tableau, ce document fait également référence aux termes définis par les extensions de classe audio Windows.

Cet article part du principe que les termes définis précédemment et les commandes HCI suivantes sont définies dans la spécification Bluetooth Core :

• Commandes du contrôleur local
  • HCI_Read_Local_Supported_Codecs (v2)
  • HCI_Lire_Capacités_Prises_en_Charge_Codec_Local
  • HCI_LE_Setup_ISO_Data_Path
  • HCI_LE_Remove_ISO_Data_Path
  • HCI_Configure_Data_Path
• Commandes de diffusion en continu unicast
  • HCI_LE_Set_CIG_Parameters
  • HCI_LE_Create_CIS
  • HCI_LE_Remove_CIG
• Commandes de diffusion en continu
  • HCI_LE_Create_BIG
  • HCI_LE_Terminate_BIG
  • HCI_LE_BIG_Create_Sync
  • HCI_LE_BIG_Terminate_Sync
  • HCI_LE_Set_Periodic_Advertising_Parameters
  • HCI_LE_Set_Periodic_Advertising_Data
  • HCI_LE_Set_Periodic_Advertising_Enable
  • HCI_LE_Periodic_Advertising_Create_Sync
  • HCI_LE_Periodic_Advertising_Create_Sync_Cancel
  • HCI_LE_Periodic_Advertising_Terminate_Sync
  • HCI_LE_Set_Periodic_Advertising_Receive_Enable
  • HCI_LE_Periodic_Advertising_Report
  • HCI_LE_BIGInfo_Advertising_Report
  • HCI_LE_Read_Periodic_Advertiser_List_Size
  • HCI_LE_Add_Device_To_Periodic_Advertiser_List
  • HCI_LE_Remove_Device_From_Periodic_Advertiser_List
  • HCI_LE_Clear_Periodic_Advertiser_List
  • HCI_LE_Periodic_Advertising_Set_Info_Transfer
  • HCI_LE_Periodic_Advertising_Sync_Transfer
  • HCI_LE_Set_Default_Periodic_Advertising_Sync_Transfer_Parameters
  • HCI_LE_Set_Periodic_Advertising_Sync_Transfer_Parameters

Bluetooth LE Audio VSAP nécessite que les pilotes audio utilisent l’infrastructure ACX. L’adoption d’ACX pour Bluetooth LE Audio offre plusieurs avantages, tels que :

• Prend en charge le modèle de pilote audio préféré pour Windows à l’avenir.
• Utilise la prise en charge native d’ACX pour les solutions audio multi stack sans nécessiter de DDI dédié entre les pilotes.
• Ne nécessite pas de pilotes audio IHV pour relayer les requêtes du système audio vers la pile Bluetooth. Au lieu de cela, ACX peut envoyer des requêtes directement à la couche Bluetooth via le circuit de gestion des profils.

Architecture

Définitions

Les composants suivants sont impliqués dans les différentes variantes d’architecture VSAP.

Cadre ACX Windows

Ce composant permet la prise en charge d’un point de terminaison audio multi stack. Pour Bluetooth LE Audio, les composants logiciels qui composent un point de terminaison audio sont la pile de pilotes audio spécifique du fournisseur et le profil Audio Windows Bluetooth LE.

Pile de pilotes audio propre au fournisseur

Ce composant spécifique au fournisseur est chargé d’envoyer et de recevoir des données Audio Bluetooth LE vers et depuis un contrôleur Bluetooth via une interface audio définie par le fournisseur. Il se compose au minimum d’un pilote de streaming ACX pour gérer les données audio entrantes et sortantes. D’autres pilotes ACX peuvent être inclus s’ils sont nécessaires dans les parties du point de terminaison audio ACX multi circuit. Ce composant est également appelé pilote de streaming ACX IHV dans ce document.

Profil audio Bluetooth LE de Windows

Ce composant contient l’implémentation du profil audio de base (BAP), du profil de contrôle de volume et du profil de contrôle du microphone. Il est chargé de créer le contrôle ACXCIRCUIT pour chaque appareil Bluetooth LE Audio ou ensemble d’appareils jumelés à Windows. Il signale également des formats audio à partir de l’appareil distant et du contrôleur Bluetooth, et gère l’état des canaux et groupes isochrones.

Pile de protocoles Bluetooth Windows

Ce composant fournit une interface pour permettre au profil audio Windows Bluetooth LE d’interroger les fonctionnalités de codec prises en charge à partir du contrôleur Bluetooth local et de gérer l’état des canaux et groupes isochrones.

Codec LC3

Ce sous-composant traduit entre l’audio LC3 compressé et l’audio PCM compressé. Il doit prendre en charge les fonctionnalités d’encodage et de décodage. Le codec LC3 peut être implémenté dans le logiciel dans le cadre de la pile VSAP (Driver) spécifique du fournisseur. Il peut également être implémenté dans le matériel dans le cadre du contrôleur DSP audio ou Bluetooth. Le diagramme mentionne LC3 par nom, car il s’agit du codec standard pris en charge par bluetooth SIG. Les codecs futurs et les codecs spécifiques du fournisseur pris en charge par Windows peuvent également être incorporés dans l’architecture de manière similaire.

Variantes d’architecture

L’architecture VSAP Bluetooth LE Audio prend en charge différentes variantes pour la diffusion en continu.

1. Streaming audio Bluetooth LE en sous-bande sans transfert d’audio
2. Streaming audio Bluetooth LE en bande latérale avec transfert de la charge audio
3. Audio Bluetooth LE en bande spécifique au fournisseur

Dans les diagrammes suivants, les composants ombrés sont fournis par l’IHV et les composants non éthérés sont fournis par le système d’exploitation.

Architecture Audio Bluetooth LE de bande latérale sans déchargement audio

Une architecture de bande latérale utilise une interface audio spécifique au fournisseur pour permettre à la pile des pilotes audio d’envoyer et de recevoir des données audio au contrôleur Bluetooth. Ce chemin de données est distinct du chemin de données HCI utilisé pour d’autres données Bluetooth, telles que la signalisation des messages entre le client monodiffusion et le serveur de monodiffusion distant. Le diagramme suivant modélise une architecture de bande latérale où le codec LC3 est hébergé dans le contrôleur Bluetooth. Il est également possible d'héberger le codec LC3 au sein de la pile de pilotes audio spécifique au fournisseur pour l'encodage et le décodage logiciel. Dans ce cas, l’audio envoyé au contrôleur Bluetooth serait mis en forme en tant que trames audio LC3 au lieu de l’audio PCM.

Le schéma suivant montre une architecture Bluetooth LE Audio avec un codec LC3 dans le contrôleur Bluetooth.

Le diagramme suivant montre une architecture Bluetooth LE Audio avec un codec LC3 dans la pile du pilote audio.

Architecture Audio Bluetooth LE de bande latérale avec déchargement audio

Une architecture de bande latérale avec déchargement audio inclut un composant matériel DSP audio pour fournir une solution de streaming Audio Bluetooth LE avec des avantages d’économie d’énergie. Les diagrammes suivants illustrent une architecture possible avec le codec LC3 dans le contrôleur Bluetooth et le codec dans le DSP audio.

Le diagramme suivant montre un dispositif audio Bluetooth LE en bande latérale avec une architecture de déchargement audio, comprenant un codec LC3 dans le contrôleur Bluetooth.

Le diagramme suivant montre un Bluetooth LE Audio à bande latérale avec une architecture de déchargement pour l'audio utilisant un codec LC3 dans le DSP audio.

Architecture audio Bluetooth LE spécifique au fournisseur en bande

L’architecture inband VSAP permet à un pipeline personnalisé d’envoyer et de recevoir des données Audio Bluetooth LE depuis la pile de pilotes audio spécifique du fournisseur vers l'HCI du contrôleur Bluetooth. Cette architecture comprend un nouveau composant, le « composant de fusion ISO IHV ». Ce composant est chargé de gérer le contrôle de flux pour les données ISO. Il doit également partager le contrôle de flux de commande HCI avec la pile Windows Bluetooth Core s’il doit envoyer des commandes HCI.

Le diagramme suivant montre une architecture audio Bluetooth LE spécifique d’un fournisseur.

Conception détaillée

Configuration requise pour le format audio

KSAUDIO_PACKETSIZE_CONSTRAINTS2

Les pilotes audio ACX IHV sont nécessaires pour prendre en charge la propriété KSAUDIO_PACKETSIZE_CONSTRAINTS2. La prise en charge de cette propriété réduit le temps entre l’ajout d’un appareil audio Bluetooth LE à windows et l’appareil audio devenant disponible pour la diffusion en continu.

Durées de trames audio

Les profils Bluetooth LE Audio permettent aux implémentations de prendre en charge le streaming audio avec des durées d’images de 7,5 millisecondes ou 10 millisecondes. Windows nécessite des codecs fournis par les IHD pour prendre en charge les deux durées d’images. Cette exigence garantit l’interopérabilité avec les appareils accessoires Bluetooth LE Audio et la coexistence de qualité avec d’autres appareils Bluetooth LE connectés au système.

Définitions du mode de traitement des signaux

Bluetooth LE Audio prend en charge un large éventail de formats de streaming pour prendre en charge différents scénarios utilisateur. Les spécifications BAP et TMAP définissent des formats obligatoires pris en charge pour la certification. Windows applique les modes de traitement de signal audio pour mettre en corrélation le format à utiliser avec le scénario que le système exécute. Les pilotes audio qui prennent en charge Bluetooth LE Audio doivent indiquer la prise en charge des modes et formats de traitement des signaux dans le tableau suivant. En outre, Bluetooth LE Audio ne prend pas en charge le mode de traitement du signal brut. Par conséquent, les pilotes audio ne publient aucun format pris en charge pour ce mode.

Formats audio de rendu unicast et modes de traitement des signaux

Bluetooth LE Audio nécessite que les formats audio de rendu monodiffusion soient déclarés pour les modes de traitement de signal suivants :

• Par défaut (AUDIO_SIGNALPROCESSINGMODE_DEFAULT)
  • Ce mode est utilisé pour les scénarios de rendu unidirectionnels, tels que la lecture musicale, les notifications et l’audio du jeu vidéo.
• Communications (AUDIO_SIGNALPROCESSINGMODE_COMMUNICATIONS)
  • Ce mode est utilisé pour les scénarios bidirectionnels, tels que les appels vocaux.

Les tableaux suivants sont des listes de formats symétriques pour chaque cas d’usage et mode de traitement des signaux. La prise en charge du format asymétrique est définie dans la chaîne stéréo super large bande pour les scénarios vocaux.

Les formats audio sont classés du plus au moins préférés.

Sons système, lecture de musique et audio de jeu vidéo lorsqu’il est connecté à un appareil stéréo ou à un ensemble coordonné d’appareils

Mode de traitement du signal : par défaut

Sons système, lecture musicale et audio de jeu vidéo lorsqu’il est connecté à un seul membre d’un ensemble coordonné (écouteur unique ou aide auditive)

Mode de traitement du signal : par défaut

Afficher l’enregistreur vocal, les appels VOIP ou l’audio de jeu vidéo avec conversation vocale

Mode de traitement des signaux : Communications

Formats audio de capture monodiffusion et modes de traitement des signaux

Bluetooth LE Audio nécessite que les formats audio de capture monodiffusion soient déclarés pour le mode de traitement du signal par défaut (AUDIO_SIGNALPROCESSINGMODE_DEFAULT). La liste des formats de capture pris en charge se trouve dans le tableau suivant.

Les formats audio sont classés du plus au moins préférés.

Capturer l’enregistreur vocal, les appels VOIP ou l’audio de jeu vidéo avec conversation vocale

Mode de traitement du signal : par défaut

Modes de traitement du signal audio de diffusion

L’audio Windows Bluetooth LE nécessite que les formats audio de source de diffusion (render) soient déclarés pour le mode de traitement du signal par défaut (AUDIO_SIGNALPROCESSINGMODE_DEFAULT).

Windows Bluetooth LE Audio nécessite que les formats audio du récepteur de diffusion (capture) soient déclarés pour le mode de traitement du signal Par défaut (AUDIO_SIGNALPROCESSINGMODE_DEFAULT).

La liste complète suivante des formats pris en charge requis est identique pour les deux rôles.

Flux de diffusion stéréo pour les sons système, la lecture de musique et l’audio de jeu vidéo

Mode de traitement du signal : par défaut

Flux de diffusion mono pour les sons système, la lecture de musique et l’audio de jeu vidéo

Mode de traitement du signal : par défaut

Configurations et topologies de flux définies

Configurations de rendu unicast uniquement

Configuration de profil audio de base 1

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge les flux mono. L’appareil unique peut être un appareil autonome ou un membre connecté unique d’un ensemble coordonné.

Configuration de profil audio de base 4

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge les flux stéréo. L’appareil audio est capable de traiter deux canaux audio sur un seul CIS.

Configuration de profil audio de base 6(i)

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge les flux stéréo. L’appareil audio ne peut traiter qu’un seul canal audio sur chacun des deux CIS

Configuration de profil audio de base 6(ii)

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un ensemble coordonné d’appareils audio. L’ensemble est capable de traiter deux canaux audio avec chaque membre traitant un seul canal.

Configurations bidirectionnelles unidiffusion

Les configurations bidirectionnelles sont utilisées lorsque le profil Bluetooth LE Audio détecte qu’une application a l’intention de créer à la fois une capture et un flux de rendu sur un appareil distant ou un ensemble d’appareils. Les applications contrôlent la capture et le rendu des flux séparément. Par conséquent, les pilotes audio IHV et les contrôleurs Bluetooth autorisent le flux audio sur une direction unique d’un CIS bidirectionnel après l’approvisionnement. Ce provisionnement utilise les commandes HCI Configure Data Path et LE Setup ISO Data Path.

Configuration de profil audio de base 3

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio avec un flux mono bidirectionnel établi sur un seul CIS.

Configuration de profil audio de base 8(i)

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge les flux de rendu stéréo et les flux de capture mono. L’appareil est capable de traiter un canal audio sur un seul CIS pour une direction donnée.

Configuration de profil audio de base 8(ii)

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un ensemble coordonné d’appareils audio. Chaque membre défini reçoit un canal de rendu audio. Un seul membre du groupe dispose d'un flux de capture établi. Le membre défini avec le flux de capture est le premier membre défini qui se connecte au PC qui prend également en charge les flux de capture.

Configurations de capture unidiffusion uniquement

Configuration de profil audio de base 2

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge les flux de capture mono.

Configuration de profil audio de base 9(i)

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un seul appareil audio qui prend en charge l’envoi de données audio stéréo. L’appareil est capable d’encodage d’un canal audio sur un seul CIS.

Configuration de profil audio de base 9(ii)

Le PC est connecté à un seul appareil audio qui prend en charge les flux de capture mono.

La configuration audio suivante est définie dans le tableau 4.1 de la spécification Bluetooth BAP

Le PC est connecté à un ensemble d’appareils audio. Chaque membre défini envoie un canal d’audio au PC.

Si l’appareil distant ou l’ensemble d’appareils prend en charge l’audio bidirectionnel, la configuration d’un flux de capture uniquement est la même que pour le flux bidirectionnel. Cette configuration permet de passer de scénarios de capture uniquement à des scénarios bidirectionnels sans avoir à recréer les flux.

Configurations de la source de diffusion

Configuration de profil audio de base 12

La configuration audio suivante est définie dans le tableau 4.2 de la spécification Bluetooth BAP

Le PC diffuse un canal d’audio mono.

Configuration de profil audio de base 13

La configuration audio suivante est définie dans le tableau 4.2 de la spécification Bluetooth BAP

Le PC diffuse de l’audio stéréo avec chaque canal transmettant sur sa propre BIS.

Structures de données

Propriétés de l’interface audio Bluetooth LE définie par Microsoft

Propriétés de création de flux

Les propriétés suivantes sont partagées entre la pile de pilotes audio spécifique au fournisseur et le profil audio Bluetooth LE via les DDISACXOBJECTBAG. Ces propriétés informent les décisions relatives à la création et à la configuration du point de terminaison de flux, comme indiqué dans le scénario de création de flux .

BluetoothLEAudio_CodecCapabilities

Le pilote audio définit cette propriété pour indiquer la prise en charge des fonctionnalités de streaming audio prises en charge dans le pilote audio ou le DSP audio. La valeur de propriété est définie à l’aide de la DDI AcxObjectBagAddBlob et le format de la valeur est identique à un enregistrement PAC tel que défini dans la SPÉCIFICATION PACS.

Le profil Audio Windows Bluetooth LE lit la propriété pour déterminer les configurations de codec possibles et la composition de flux à utiliser.

Les valeurs de champ sont définies dans les tables 3.2 et 3.4 de la spécification PACS.

Bluetooth_DatapathID

Le pilote audio définit cette propriété pour indiquer l’ID de chemin d’accès aux données utilisé comme paramètre pour les commandes HCI_LE_Setup_ISO_Data_Path et HCI_Configure_Data_Path. La valeur de propriété est définie à l’aide de l’acxObjectBagAddUI8 DDI.

Le profil Bluetooth LE Audio lit et utilise cette propriété comme paramètre dans les commandes HCI_Configure_Data_Path et HCI_LE_Setup_ISO_Data_Path. Cet ID est appliqué pour tous les flux isochrones créés pour ACXSTREAM associé au conteneur d’objets. Pour affecter un ID de chemin de données différent pour chaque connexion de flux, utilisez KSPROPERTY_BtLeAudio_DATAPATH_ID dans vos pilotes audio.

Si le pilote audio ne définit pas cette propriété, le système d’exploitation utilise la valeur 1 comme paramètre pour les commandes HCI.

Bluetooth_Configuration du chemin de données

Le pilote audio définit cette propriété pour fournir aux fournisseurs des configurations spécifiques au contrôleur Bluetooth via la commande HCI_Configure_Data_Path. Il ne doit pas dépasser 255 octets, ce qui est la charge utile la plus importante qu’un contrôleur Bluetooth accepte pour une commande HCI. La valeur de propriété est définie à l'aide de AcxObjectBagAddBlob DDI. Cette configuration s’applique à tous les ID de chemin de données définis par le pilote audio. Pour affecter une configuration de chemin de données différente pour chaque ID de chemin d’accès aux données, utilisez KSPROPERTY_BtLeAudio_DATAPATH_CONFIG dans vos pilotes audio.

Bluetooth_RequiresHciTransportInD0ForStreaming

Le pilote audio définit cette propriété pour indiquer que le contrôleur Bluetooth ne passe pas à un état d’alimentation faible pendant qu’un flux audio est actif. La valeur de propriété est définie à l’aide de l’acxObjectBagAddUI8 DDI.

BluetoothLEAudio_CodecConfiguration

Cette propriété doit être définie par le profil Audio Bluetooth LE à l’aide de LDI AcxObjectBagAddBlob une fois la configuration du codec configurée avec un périphérique audio. La structure de la valeur est la suivante :

Les valeurs de champ sont dérivées du tableau 4.3 de la spécification du service de contrôle de flux audio Bluetooth.

La pile de pilotes audio spécifique au fournisseur doit lire cette propriété si le codec LC3 se trouve dans le pilote de streaming ACX ou le DSP audio.

BluetoothLEAudio_StreamConnectionHandles

Cette propriété doit être définie par le profil audio Bluetooth LE pour informer le pilote audio de la liste des handles BIS ou CIS créés pour un BIG ou CIG. L’ordre des handles correspond à l’ordre retourné par le contrôleur Bluetooth à la commande HCI LE_Set_CIG_Parameters ou à l’événement HCI LE_Create_BIG_Complete. La structure de la valeur est la suivante :

Propriétés bluetooth LE Audio KS

Les propriétés KS permettent au pilote audio ACX IHV de définir ou de mettre à jour les paramètres de flux audio une fois le flux créé. Ce scénario est utile pour que les pilotes audio définissent les paramètres de configuration en fonction des propriétés définies par le circuit de profil Bluetooth dans la procédure de création de flux.

Définitions

#define STATIC_KSPROPSETID_BtLeAudio\
    0x1159b79, 0xea6, 0x4923, 0x80, 0xf5, 0x32, 0x58, 0xd1, 0xfd, 0x91, 0x56
DEFINE_GUIDSTRUCT("01159B79-0EA6-4923-80F5-3258D1FD9156", KSPROPSETID_BtLeAudio);
#define KSPROPSETID_BtLeAudio DEFINE_GUIDNAMED(KSPROPSETID_BtLeAudio)

typedef enum {
    KSPROPERTY_BtLeAudio_DATAPATH_ID,
    KSPROPERTY_BtLeAudio_DATAPATH_CONFIG,
} ksproperty_btleaudio;

KSPROPERTY_BtLeAudio_DATAPATH_ID

Ce KSProperty permet aux pilotes audio ACX IHV de définir ou de mettre à jour la valeur définie par Bluetooth_DatapathID après l’appel du rappel de flux de création. Cette propriété permet également aux pilotes audio IHV d’attribuer un ID de chemin de données différent pour chaque entrée de configuration de codec dans BluetoothLEAudio_CodecConfiguration. La valeur de cette propriété doit être définie sur une valeur d’octet unique pour représenter l’ID de chemin d’accès aux données utilisé pour toutes les configurations de codec, ou n octets, où n est égal à la valeur nombre de configuration définie dans la propriété BluetoothLEAudio_CodecConfiguration. Si la valeur contient plusieurs ID de chemin d’accès aux données, l’ordre des ID doit être utilisé pour la configuration du codec, comme indiqué dans la propriété BluetoothLEAudio_CodecConfiguration.

KSPROPERTY_BtLeAudio_DATAPATH_CONFIG

Ce KSProperty permet aux pilotes audio ACX IHV de définir ou de mettre à jour la configuration du chemin de données tel que défini dans Bluetooth_DatapathConfiguration. Le KSProperty doit être envoyé par le pilote audio au profil Bluetooth avant l’appel du rappel de flux audio de démarrage. Cette propriété peut être utilisée pour définir une configuration unique pour tous les chemins de données dans une direction unique ou pour définir une configuration de chemin de données spécifique pour chaque entrée de configuration de codec définie dans BluetoothLEAudio_CodecConfiguration. Si la valeur contient plusieurs configurations de chemin d’accès aux données, l’ordre des configurations doit être utilisé pour l’entrée de configuration de codec comme trié dans la propriété BluetoothLEAudio_CodecConfiguration. Le nombre de configurations de codec doit être égal au nombre d’ID de chemin de données définis par KSPROPERTY_BtLeAudio_DATAPATH_ID ou Bluetooth_DatapathID.

Interfaces

ID de liaison de modèle de point de terminaison audio

Utilisé par l'usine de circuits ACX du pilote audio pour savoir quand un circuit ACX pour un appareil Bluetooth jumelé est créé.

Les ID de composant suivants sont utilisés pour créer des circuits Audio Bluetooth LE :

// {5C52FDB5-722A-4AB7-A342-70163B7E9B5C}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_RENDER_COMPONENT_ID,
0x5c52fdb5, 0x722a, 0x4ab7, 0xa3, 0x42, 0x70, 0x16, 0x3b, 0x7e, 0x9b, 0x5c);

// {1DFF2EE3-AE89-441C-BDE3-24F885C55DF8}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_CAPTURE_COMPONENT_ID,
0x1dff2ee3, 0xae89, 0x441c, 0xbd, 0xe3, 0x24, 0xf8, 0x85, 0xc5, 0x5d, 0xf8);

Interface de support Bluetooth LE Audio

Utilisé par la pile de pilotes audio pour indiquer qu’il est disponible pour la diffusion en continu de l’audio Bluetooth LE. Le service audio Bluetooth de Windows surveille cette interface et attend qu'elle soit prête avant d'activer la prise en charge de Bluetooth LE Audio.

Les ID d’interface suivants sont utilisés pour publier l’interface de prise en charge Bluetooth LE Audio :

// {BA02FA1B-0FD0-4A0F-A748-4FAE2E2D2F67}
DEFINE_GUID(GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
0xba02fa1b, 0x0fd0, 0x4a0f, 0xa7, 0x48, 0x4f, 0xae, 0x2e, 0x2d, 0x2f, 0x67);

Séquences courantes

Les séquences suivantes sont exécutées pour les scénarios audio monodiffusion et de diffusion DE L.

Initialisation du pilote audio

Lorsque le pilote IHV ACX Streaming est chargé et qu’il détermine qu’il prend en charge le streaming audio Bluetooth LE, il affiche la prise en charge de la technologie en créant un objet ACXFACTORYCIRCUIT et en inscrivant les liaisons de modèle Bluetooth avec ACX en utilisant les ID définis dans ID de liaison de modèle de point de terminaison audio.

Séquences audio monodiffusion

Création d’un point de terminaison

1. Lorsqu’un appareil LE Audio est associé au système, le profil audio Bluetooth LE :

   1. Consulte les fonctionnalités audio publiées de l’appareil distant.
   2. Découvre les fonctionnalités prises en charge par le contrôleur en envoyant les commandes HCI_Read_Local_Support_Codecs [v2] et HCI_Read_Local_Supported_Codec_Capabilities.
   3. Crée un ACXCIRCUIT avec les formats pris en charge définis en fonction des fonctionnalités de codec prises en charge par le contrôleur Bluetooth et l’appareil audio distant. Si le contrôleur ne prend pas en charge les codecs, car la prise en charge du codec se trouve dans le DSP audio ou le pilote audio, les formats pris en charge sont définis sur les formats pris en charge par le périphérique audio distant.

2. Après que l’ACXCIRCUIT est créé, ACX demande au fabricant de circuits ACX du pilote de streaming ACX IHV de créer un ACXCIRCUIT pour le traitement de flux.

3. Lorsqu’une demande de création d’un circuit est reçue, le pilote de streaming ACX IHV :

   1. Crée des objets ACXCIRCUIT, ACXPIN, ACXOBJECTBAG et ACXSTREAMBRIDGE.
   2. Si le codec LC3 ou spécifique au fournisseur est hébergé dans le pilote audio ou le DSP, alors le pilote de streaming ACX IHV définit la propriété BluetoothLEAudio_CodecCapabilities sur ACXOBJECTBAG.
   3. Le pilote de streaming ACX IHV peut définir Bluetooth_DatapathID ou Bluetooth_DatapathConfiguration sur ACXOBJECTBAG s’il est connu pour l’instant.

4. Une fois les deux circuits créés, ACX appelle le rappel EvtAcxPinConnected sur la broche de pont du pilote ACX IHV.

5. Quand il s’agit du rappel EvtAcxPinConnected est appelé, le pilote de streaming ACX IHV :

   1. Récupère la broche de pont du circuit de profil avec les APIs AcxTarget... pour récupérer les formats pris en charge par le circuit de profil.
   2. Parcourt la liste des éléments ACXDATAFORMAT définis par le circuit de profil. Si le codec audio Bluetooth est hébergé dans le pilote audio ou le DSP audio, le pilote audio IHV met à jour ses fichiers ACXDATAFORMATavec les formats pris en charge par le codec et le circuit de profil. Sinon, tous les formats sont copiés dans le pin hôte du pilote de streaming ACX IHV.
   3. Définit la liste de format mise à jour sur la broche de pont si un moteur audio est créé pour décharger le streaming.

6. Une fois les formats mis à jour, ACX active les deux interfaces et un point de terminaison audio est créé.

   

Création de flux

1. Lorsqu’une application demande de créer un flux audio, ACX appelle les rappels EvtCircuitCreateStream inscrits pour chaque circuit, en commençant par le pilote de streaming ACX IHV.

2. Quand son rappel EvtCircuitCreateStream est appelé, le pilote de streaming ACX IHV :

   1. Définit ou met à jour les propriétés Bluetooth_DatapathId et Bluetooth_DataPathConfiguration sur ACXOBJECTBAG attachées à ACXSTREAMBRIDGE.
   2. Crée un ACXSTREAM avec des rappels définis pour les transitions d’état de flux et le traitement de flux RT
   3. Crée un élément de moteur audio sur le flux si le pipeline audio prend en charge le déchargement de streaming.
   4. Ajoute ACXSTREAM à sa passerelle de flux. Cela déclenche, dans le profil Audio Bluetooth LE, le rappel EvtCircuitCreateStream.

3. Quand son rappel EvtAcxCircuitCreateStream est appelé, le profil Audio Bluetooth LE :

   1. Enregistre les propriétés localement à partir de l’ACXOBJECTBAG défini par le pilote de streaming ACX IHV pour les rappels de transition de flux futurs.
   2. Effectue l’opération de codec de configuration telle que définie dans la spécification BAP. Les paramètres de l’opération sont dérivés de l’ACXDATAFORMAT spécifié dans le rappel EvtAcxCircuitCreateStream et les autres paramètres de flux dans ACXOBJECTBAG ou les fonctionnalités de codec prises en charge par le contrôleur Bluetooth.
   3. Alloue des ressources de flux en envoyant la commande Paramètres CIG set HCI LE.
   4. Définit la propriété BluetoothLEAudio_StreamConnectionHandles avec la liste des handles de connexion CIS retournés par le contrôleur Bluetooth.
   5. Définit la propriété BluetoothLEAudio_CodecConfiguration sur ACXOBJECTBAG avec la valeur utilisée pour configurer les périphériques audio distants.

4. Si le pilote de streaming ACX IHV doit mettre à jour son ID de chemin de données ou sa configuration de chemin d’accès aux données en fonction des valeurs du conteneur d’objets définies par le profil, il peut appeler les opérations de jeu KSPROPERTY pour mettre à jour la valeur stockée par le circuit de profil.

   1. Crée un ACXSTREAM avec des rappels définis pour les transitions d’état de flux.

   

Transitions d’état de flux

ACX détermine l’ordre de circuit des transitions d’état de flux en fonction du flux audio et indique si l’état passe à un état plus actif ou moins actif.

• Pour les flux de rendu passant d’un état moins actif à un état plus actif, le circuit de profil reçoit d’abord l’événement, suivi du circuit de streaming.
• Pour les flux de rendu qui passent d’un état plus actif à un état moins actif, le circuit de streaming reçoit d’abord l’événement, suivi par le circuit de profil. 
• Pour les flux de capture passant d’un état moins actif à un état plus actif, le circuit de streaming reçoit d’abord l’événement, suivi du circuit de profil. 
• Pour les flux de capture allant d'un état plus actif à un état moins actif, le circuit de profil recevra l'événement en premier, suivi du circuit de flux.

Préparer le flux de diffusion

Lorsque son rappel EvtAcxStreamPrepareHardware est appelé, le profil Audio Bluetooth LE envoie l’opération QoS de configuration ASCS pour synchroniser les paramètres avec l’appareil distant si nécessaire. Il est possible que l’opération qoS de configuration ASCS soit déjà terminée lorsque le rappel a été appelé pour l’autre direction d’un flux bidirectionnel.

Lorsque sa fonction de rappel EvtAcxStreamPrepareHardware est invoquée, le pilote de streaming ACX IHV alloue les ressources de streaming nécessaires et initialise le pipeline audio pour être dans l'état acquis.

Démarrer le streaming

Quand sa fonction de rappel EvtAcxStreamRun est invoquée, le profil Audio Bluetooth LE :

1. Applique tous les arguments de configuration du pilote de streaming ACX, comme décrit ci-dessous, à l’aide de la commande HCI_Configure_Data_Path s’ils ont changé. La pile Windows Bluetooth Core met en cache la mémoire tampon Vendor_Specific_Config pour chaque paire Data_Path_Direction et Data_Path_ID. La commande HCI_Configure_Data_Path est envoyée uniquement lorsque le Vendor_Specific_Config change pour une paire Data_Path_Direction et Data_Path_ID.
   1. Data_Path_Direction est audioDirection du rappel de circuit de diffusion en continu qui émet le rappel EvtAcxStreamRun.
   2. Le Data_Path_ID est rempli avec la valeur la plus récemment attribuée à partir de l’une des sources suivantes :
      1. Bluetooth_DatapathID sur ACXOBJECTBAG attaché à ACXSTREAMBRIDGE passé au profil audio Windows Bluetooth LE pendant le rappel EvtCircuitCreateStream.
      2. Données de KSPROPERTY_BtLeAudio_DATAPATH_ID.
   3. Les données Vendor_Specific_Config sont remplies avec la valeur la plus récemment affectée à partir de l’une des sources suivantes :
      1. Bluetooth_DatapathConfiguration sur acXOBJECTBAG attaché à ACXSTREAMBRIDGE passé au circuit windows Bluetooth LE Audio Profile pendant le rappel EvtCircuitCreateStream.
      2. Données de KSPROPERTY_BtLeAudio_DATAPATH_CONFIG.
2. Envoie l’opération ASCS Enable aux appareils distants.
3. Crée des CIS s’ils ne sont pas déjà créés à l’aide de la commande HCI_LE_Create_CIS.
4. Si le chemin d’accès aux données n’est pas déjà configuré, le profil audio Bluetooth LE :
   1. Établit les chemins de données ISO à l’aide de la commande HCI_LE_Setup_ISO_Data_Path
      1. Si le pilote de streaming ACX IHV définit la propriété BluetoothLEAudio_CodecCapabilities, la valeur du champ Codec_ID dans HCI_LE_Setup_ISO_Data_Path doit être définie sur transparente (0x3) comme défini dans les numéros attribués Bluetooth. Sinon, la valeur doit être identique à l’ID de codec utilisé dans l’opération de codec de configuration dans la procédure de création de flux.
5. Si le flux audio est un flux de capture, le profil audio Bluetooth LE effectue l’opération prête pour le récepteur BAP.

Lorsque son rappel EvtAcxStreamRun est appelé, le pilote de streaming ACX IHV démarre le traitement des données audio entrantes à partir du système audio Windows (rendu) ou du contrôleur Bluetooth (capture).

Suspendre le flux

Lorsque le rappel EvtAcxStreamPause est invoqué, le profil Audio Bluetooth LE :

1. Exécute la procédure de désactivation du flux unicast BAP.
2. Supprime le chemin des données ISO à l’aide de la commande HCI_LE_Remove_ISO_Data_Path.
3. Exécute la procédure de préparation pour le récepteur ASCS si le flux audio est un flux de capture en unicast.
4. Déconnectez les services CIS s’il n’existe aucun autre flux en cours d’utilisation pour ce CIS.

Lorsque son rappel EvtAcxStreamPause est appelé, le pilote de streaming ACX IHV interrompt son pipeline de traitement audio.

Flux de publication

Quand son rappel EvtAcxStreamReleaseHardware est appelé, le profil audio Bluetooth LE :

1. Envoie l’opération de mise en production ASCS à l’appareil Bluetooth LE Audio distant
2. Supprime le CIG si tous les CIS sont déconnectés.

Lorsque sa fonction de rappel EvtAcxStreamReleaseHardware est invoquée, le pilote de streaming ACX de l'IHV libère ses ressources de pipeline audio.

Déconnexion du point de terminaison

Le profil Audio Windows Bluetooth LE met à jour l’état de connexion d’un point de terminaison si l’appareil de monodiffusion distant n’a pas de connexion LE-ACL au PC ou signale via ses contextes audio disponibles PACS qu’il n’est pas disponible pour la diffusion en continu. Lorsque le point de terminaison est déconnecté, le service audio Windows invalide tous les flux actifs vers le point de terminaison. Cela entraîne la suspension du flux et les séquences de reprise.

Volume et muet

Le circuit de streaming ACX IHV ne doit inclure que des éléments de volume et de désactivation si le pilote de diffusion en continu nécessite un moteur audio. Lorsque vous utilisez un moteur audio, les indicateurs de configuration doivent être définis comme suit :

ACX_AUDIOENGINE_CONFIG audioEngineCfg;
ACX_AUDIOENGINE_CONFIG_INIT(&audioEngineCfg);
…

audioEngineCfg.Flags |= AcxAudioEngineConfigVolumeSecondary; // Use this control only if endpoint doesn't have one.

audioEngineCfg.MuteElement = muteElement;

audioEngineCfg.Flags |= AcxAudioEngineConfigMuteSecondary; // Use this control only if endpoint doesn't have one.

audioEngineCfg.PeakMeterElement = peakmeterElement;

audioEngineCfg.Flags |= AcxAudioEngineConfigPeakMeterSecondary; // Use this control only if endpoint doesn't have one.

Cela est nécessaire afin de permettre aux points de terminaison Bluetooth LE Audio d’utiliser les profils de contrôle de volume et de microphone définis par Bluetooth SIG pour les changements de volume et la désactivation des points de terminaison audio monodiffusion.

Si l’appareil Audio LE Bluetooth distant ne prend pas en charge les services de contrôle de volume ou de microphone, ou si le point de terminaison est créé pour la diffusion audio, le volume et les éléments du moteur audio doivent servir de solution de repli pour gérer les demandes de modification du système audio. Le système audio Windows gère les modifications du volume et du mode silencieux. S’il n’existe aucun moteur audio et que l’appareil distant ne prend pas en charge le volume, ou que les services de microphone ou le point de terminaison audio sont destinés à la diffusion audio.

Suppression du point de terminaison

Un point de terminaison audio Bluetooth LE est supprimé du système lorsque le circuit de profil ou le circuit de streaming est détruit. Le circuit de profil peut être supprimé lorsque le jumelage de l’appareil monodiffusion distant est supprimé de Windows ou que la radio Bluetooth est désactivée.

1. Lorsque le profil audio Windows Bluetooth LE supprime son circuit, ACX désactive ses interfaces de point de terminaison pour signaler au service audio Windows que le point de terminaison doit être supprimé.
2. Lorsque les interfaces sont désactivées, le service audio Windows invalide tous les flux actifs vers le point de terminaison audio Bluetooth LE, cette opération entraîne l’appel des rappels de flux et de mise en production sur le circuit de streaming.
3. Pour terminer la suppression du point de terminaison, ACX invalide le circuit du pilote de streaming ACX IHV, ce qui entraîne l'appel de la fonction de nettoyage du circuit par le WDF.
4. Lorsque son rappel de nettoyage est appelé, le pilote de streaming ACX IHV libère son circuit.

Coexistence audio Bluetooth LE et classique

Windows doit s’assurer que seul l’audio classique ou LE est actif pour un appareil audio Bluetooth jumelé qui prend en charge les deux technologies. Si l’audio LE est actif, les DDIs de bande latérale pour A2DP et HFP pour l’appareil distant sont désactivées et le circuit de profil est créé pour le point de terminaison audio LE. Si l’audio classique est actif, les DDIS de bande latérale pour A2DP et HFP pour l’appareil distant sont activées et le circuit de profil n’est pas créé pour le point de terminaison audio LE.

Gestion de l’alimentation

Bluetooth LE Audio n’a pas de configuration ou de flux de gestion de l’alimentation en dehors de ce qui est déjà défini par WDF.

Stéréo à bande large pour les scénarios vocaux

L’expérience audio Bluetooth d’aujourd’hui est pratique, mais présente des limitations, en particulier par rapport aux expériences audio câblées. Une limitation clé, avec des conséquences sur l’utilisateur, est la chute de l’audio mono chaque fois que le microphone est actif. Cela bloque les expériences telles que l’audio spatial dans Teams et d’autres applications VoIP de travailler, et elle dégrade fortement les expériences de jeu impliquant la conversation vocale.

Bluetooth LE Audio ferme l’écart avec une fidélité audio améliorée et une latence réduite en ajoutant la prise en charge de la lecture stéréo pendant l’utilisation du microphone.

Paires de format de rendu/capture

Une solution IHV publie sa prise en charge du rendu stéréo avec la capture mono en fournissant une liste de paires de formats de rendu/capture, chacune se compose d’un format de rendu stéréo et d’un format de capture mono qui peut être utilisé simultanément pour la diffusion en continu bidirectionnelle. Un format de rendu stéréo (ou de capture mono) est défini comme une paire d’un Sampling_Frequency (par exemple, 16/24/32/48 kHz) et un Audio_Channel_Count (par exemple, 1/2 ch) associé à un codec audio spécifique, qui n’est pas limité à LC3.

Par exemple, supposons qu’une solution IHV prend en charge le rendu stéréo de 16kHz avec une capture mono de 16kHz et un rendu stéréo de 48kHz avec une capture mono de 24 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 0000 0000 00 Les paires de format de rendu/capture correspondantes ressemblent à ceci :

^{Tableau 3 : Exemples de paires de format de rendu/capture}

Étant donné qu’un membre d’ensemble coordonné peut joindre ou disjoindre à tout moment, une solution IHV doit prendre en charge le rendu mono avec la capture mono à la même fréquence d’échantillonnage respective pour chaque entrée dans les paires de format. Cela signifie que, étant donné l’exemple du tableau 3, toutes les paires de format ci-dessous doivent également être implicitement prises en charge même si elles ne sont pas déclarées explicitement :

^{Tableau 4 : Paires de format de rendu/capture implicites pour le tableau 3}

La principale différence entre le tableau 3 et le tableau 4 est que le Audio_Channel_Count pour chaque format de rendu dans ce dernier est défini sur un (pour « rendu mono ») ; tout reste le même.

Paires de format de rendu/capture obligatoires

Le tableau 5 définit la liste des formats audio que toutes les solutions IHV prennent en charge :

^{Tableau 5 Paires de format de rendu/capture obligatoires}

Publication des fonctionnalités

Selon que le contrôleur Bluetooth prend en charge le codec audio impliqué (par défaut, LC3), une solution IHV publie la liste des paires de format de rendu/capture qu’elle prend en charge de différentes manières. Plus précisément :

• Si le codec se trouve dans le contrôleur Bluetooth, le contrôleur et le pilote de streaming ACX IHV publient les listes de paires de formats indépendamment. Si les deux listes ne sont pas en désaccord les unes avec les autres, Windows se croise et conserve les parties communes.

• Si le codec n’est pas dans le contrôleur Bluetooth (par exemple, il se trouve dans le DSP audio), seul le pilote de streaming ACX IHV est requis pour publier la liste des paires de formats. Contrôleur Bluetooth

Étant donné que le Codec_Capability[i] dans la réponse d’un HCI_Read_Local_Supported_Codec_Capabilities ne prend pas en charge les métadonnées, le contrôleur Bluetooth est requis pour prendre en charge une famille d’ID de codec spécifiques à Microsoft (voir le tableau 7) de sorte que Windows puisse interroger davantage de fonctionnalités de codec, par exemple la liste des paires de format de rendu/capture, qui ne peuvent pas être facilement transmises via l’interface HCI existante.

^{TABLEAU 7 ID de codec spécifique à Microsoft}

Les étendues de ces ID de codec spécifiques à Microsoft sont limitées à :

• HCI_Read_Local_Supported_Codecs [v2]
• HCI_Lire_Capacités_Prises_en_Charge_Codec_Local

Par contrat, Windows n’utilise pas ces ID de codec spécifiques à Microsoft pour d’autres types de commandes HCI.

HCI_Read_Local_Supported_Codecs [v2]

Le contrôleur doit publier sa prise en charge de l’ID de codec spécifique à Microsoft via Vendor_Specific_Codec_ID et Vendor_Specific_Codec_Transport :

^{Table 8 HCI_Read_Local_Supported_Codec [v2] valeur de réponse}

HCI_Lire_Capacités_Prises_en_Charge_Codec_Local

Pour rechercher toutes les fonctionnalités de codec spécifiques à Windows, notamment la liste des paires de format de rendu/capture, Windows appelle HCI_Read_Local_Supported_Codec_Capabilities avec les arguments suivants :

^{Tableau 9 HCI_Read_Local_Supported_Codec_Capabilities arguments de commande}

Lors de la réception d’une telle commande, le contrôleur retourne toutes les fonctionnalités spécifiques à Windows pour le codec spécifié par l’ID de codec défini par le fournisseur. Par exemple, si l’ID de codec défini par le fournisseur est défini sur 0x0006, le contrôleur retourne toutes les fonctionnalités liées à LC3 requises par Windows.

La réponse de la commande conserve la même structure de niveau supérieur que celle définie par la spécification Bluetooth Core :

^{Tableau 10 HCI_Read_Local_Supported_Codec_Capabilities structure de réponse}

Toutefois, la charge utile de Codec_Capability[i] diffère de celle définie par le SIG et est adaptée à Windows.

Actuellement, la seule fonctionnalité de codec définie par Windows est Bidirectional_Multichannel_Streaming, qui est décrite ci-dessous.

Bidirectional_Multichannel_Streaming

En publiant Bidirectional_Multichannel_Streaming, le contrôleur affirme qu’il prend en charge le rendu simultané du canal m avec la capture n-canal où m ≥ 1, n ≥ 1 et m + n> 2. (Le rendu stéréo avec capture mono est effectivement un Bidirectional_Multichannel_Streaming avec m = 2 et n = 1.)

Ce tableau décrit le format de Bidirectional_Multichannel_Streaming :

^{Tableau 11 format Bidirectional_Multichannel_Streaming (longueur maximale : 11 octets)}

Channel_Counts

Le choix du nombre de bits pour le rendu/la capture est arbitraire : cinq bits sont alloués pour le rendu (pour couvrir tous les emplacements audio définis par SIG) et trois bits pour la capture (pour réduire la taille de charge utile HCI).

Par exemple, le Channel_Counts pour le tableau 3 est de 0b0000'0001, car le nombre de canaux de rendu/capture, par exemple, m et n, sont respectivement 2 et 1 :

^{Tableau 12 Channel_Counts pour le tableau 3}

Par conception, toutes les fonctionnalités avec la même paire d’ID de codec spécifique à Microsoft et Channel_Counts doivent être regroupées et représentées par un enregistrement Bidirectional_Multichannel_Streaming unique.

Render_Sampling_Frequencies

Le champ Render_Sampling_Frequencies spécifie toutes les fréquences de rendu qui peuvent être utilisées dans le contexte de la structure de Bidirectional_Multichannel_Streaming associée.

Par exemple, le Render_Sampling_Frequencies pour le tableau 3 est 0b000'1001, ce qui signifie que 16kHz et 48kHz peuvent être utilisés comme fréquence d’échantillonnage pour le rendu à deux canaux :

^{Tableau 13 Render_Sampling_Frequencies pour le tableau 3}

Capture_Sampling_Frequencies_List[i]

Pour chaque bit « un » dans Render_Sampling_Frequencies, à partir du moins significatif à celui le plus significatif, le contrôleur doit fournir un masque de bits unique (Capture_Sampling_Frequencies_List[i]) spécifiant toutes les fréquences de capture compatibles avec la fréquence représentée par ce bit de rendu. Le contrôleur ne doit pas fournir un masque de bits Capture_Sampling_Frequencies pour un bit « zéro » dans Render_Sampling_Frequencies.

Par exemple, les masques de capture pour le tableau 3 ressemblent à ceci :

// The order matters!
{
    // Capture_Sampling_Frequencies_List[0] for 16kHz dual-channel rendering.
    0b0000'0001, // 16 kHz single-channel capture

    // Do not create a dummy Capture_Sampling_Frequencies_List entry, for example, 0b0000'0000,
    // for 24kHz dual-channel rendering, which is not supported at all.

    // Do not create a dummy Capture_Sampling_Frequencies_List entry, for example, 0b0000'0000,
    // for 32kHz dual-channel rendering, which is not supported at all.

    // Capture_Sampling_Frequencies_List[1] for 48kHz dual-channel rendering.
    0b0000'0110 // Either 24 or 32 kHz single-channel capture
}

Plus précisément :

^{Tableau 14 Exemple de création d’un Capture_Sampling_Frequencies_List[i] pour un Render_Sampling_Frequencies}

Pilote de streaming ACX IHV

Pour prendre en charge le rendu stéréo avec la capture mono, un pilote de streaming ACX IHV définit la propriété de l’appareil, BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities, qui représente les paires de format de rendu/capture décrites dans la version 3.11.2, sur une instance de la classe d’interface d’appareil, GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE.

La propriété doit être rendue disponible immédiatement après la création de l’instance de classe d’interface d’appareil et la valeur de la propriété reste constante tout au long de la durée de vie de l’instance de classe d’interface d’appareil.

La clé de propriété de BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities est définie comme suit :

DEFINE_DEVPROPKEY(DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
    0xd27ba3a4, 0x1bfe, 0x4374, 0x88, 0x7d, 0xe8, 0xb3, 0xa6, 0xac, 0xe, 0xe9, 2); // DEVPROP_TYPE_BINARY (BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY[])

Le type de valeur de propriété associé à la clé, DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities, est défini comme suit :

typedef struct _BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY
{
    BTH_LE_AUDIO_CODEC_ID CodecId;
    BOOL IsCodecPresent;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT RenderChannelCount;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT CaptureChannelCount;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY RenderSamplingFrequencies;
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY CaptureSamplingFrequenciesList[
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_BIT_LENGTH
    ];
} BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY;

Where:

typedef struct _BTH_LE_AUDIO_CODEC_ID
{
    UINT8 CodingFormat;
    UINT16 CompanyId;
    UINT16 VendorCodecId;
} BTH_LE_AUDIO_CODEC_ID;

typedef UINT8 BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CHANNEL_COUNT;

typedef enum _BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY :
    UINT8 // Bit flags
{
    // 16 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ = 0x1,

    // 24 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ = 0x2,

    // 32 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ = 0x4,

    // 48 kHz
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ = 0x8,

    // A dummy value for indicating a sampling frequency is "not applicable" in the
    // respective context.
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_NONE = 0,

    // All valid sampling frequencies combined.
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_ALL =
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ |
        BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ,
} BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY;

DEFINE_ENUM_FLAG_OPERATORS(BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY);

#define BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_BIT_LENGTH \
    (sizeof(BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY) * 8)

La structure BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY suit des règles similaires, comme décrit dans Bidirectional_Multichannel_Streaming, sauf que :

• Le pilote de streaming ACX est requis pour définir un indicateur supplémentaire, IsCodecPresent, pour indiquer si le codec d’intérêt fait partie conceptuelle du pilote de streaming ACX. Par exemple, si le codec se trouve dans le DSP audio, IsCodecPresent doit être défini sur TRUE. Si le codec se trouve dans le contrôleur Bluetooth, l’indicateur doit être défini sur FALSE.

• Pour le rendu de canal m avec la capture n-channel, les valeurs de RenderChannelCount et CaptureChannelCount sont m et n, respectivement. En d’autres termes, RenderChannelCount et CaptureChannelCount indiquent le nombre réel de canaux de rendu et de capture.

• Compte tenu d’un index, i, il existe un mappage un-à-un entre le i-ième bit le moins significatif de RenderSamplingFrequencies et l’i-ième entrée de CaptureSamplingFrequenciesList. Si le i-ième bit de RenderSamplingFrequencies est égal à zéro, définissez CaptureSamplingFrequenciesList[i] sur zéro.

L’exemple de code suivant montre comment créer l’interface de l’appareil GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE et définir la propriété de l’interface d’appareil BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities :

PAGED_CODE_SEG
NTSTATUS
AdvertiseBluetoothLEAudioSupport(
    WDFDEVICE Device
    )
{
    // Create a device interface with the class,
    // GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE, for the specified WDF device.
    DECLARE_CONST_UNICODE_STRING(
        bluetoothLEAudioSupportInterface, L"BluetoothLEAudioSupport");
    RETURN_NTSTATUS_IF_FAILED(WdfDeviceCreateDeviceInterface(
        Device,
        &GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
        (PUNICODE_STRING)&bluetoothLEAudioSupportInterface));

#pragma region associate BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities with GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE.
    // Advertise bidirectional multichannel streaming support by setting the device
    // interface property, 
    // BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
    // to the newly created device interface.

    // See Table 7 "Microsoft-specific codec ID" in Microsoft Bluetooth LE Audio
    // IHV Specification for reference.
    constexpr BTH_LE_AUDIO_CODEC_ID microsoftLC3CodecId
    {
        0xff, // Vendor-specific
        0x6,  // Microsoft
        0x6,  // LC3
    };

    constexpr BTH_LE_AUDIO_CODEC_ID microsoftCVSDCodecId
    {
        0xff, // Vendor-specific
        0x6,  // Microsoft
        0x2,  // CVSD
    };

    // For readability purpose only
    constexpr auto SamplingFrequency_None = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_NONE;
    constexpr auto SamplingFrequency_16000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_16000HZ;
    constexpr auto SamplingFrequency_24000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_24000HZ;
    constexpr auto SamplingFrequency_32000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_32000HZ;
    constexpr auto SamplingFrequency_48000Hz = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_48000HZ;
    constexpr auto SamplingFrequency_All = BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_SAMPLING_FREQUENCY_ALL;

    // Bidirectional multichannel streaming capabilities
    BTH_LE_AUDIO_BIDIRECTIONAL_MULTICHANNEL_STREAMING_CAPABILITY capabilities[]
    {
        // List of formats supported for 2-channel render with 1-channel capture using
        // the LC3 codec:
        //
        //      Render           Capture
        //   (Freq, #Chan)    (Freq, #Chan)
        //   =============    =============
        //    (16kHz, 2) <---> (16kHz, 1)
        //    ----------       ----------
        //    (24kHz, 2) <---> (16kHz, 1)
        //    (24kHz, 2) <---> (24kHz, 1)
        //    ----------       ----------
        //    (32kHz, 2) <---> (16kHz, 1)
        //    (32kHz, 2) <---> (24kHz, 1)
        //    (32kHz, 2) <---> (32kHz, 1)
        //    ----------       ----------
        //    (48kHz, 2) <---> (16kHz, 1)
        //    (48kHz, 2) <---> (24kHz, 1)
        //    (48kHz, 2) <---> (32kHz, 1)
        //    (48kHz, 2) <---> (48kHz, 1)
        //
        {
            // CodecId
            microsoftLC3CodecId,
            // IsCodecPresent,
            FALSE, // The LC3 codec is in the Bluetooth Controller.
            // RenderChannelCount
            2,
            // CaptureChannelCount
            1,
            // RenderSamplingFrequencies
            SamplingFrequency_All,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 16kHz, 2-channel render
            SamplingFrequency_16000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 24kHz, 2-channel render
            SamplingFrequency_16000Hz | SamplingFrequency_24000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 32kHz, 2-channel render
            SamplingFrequency_16000Hz |
                SamplingFrequency_24000Hz |
                SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 1-channel capture sampling
            // frequencies compatible with 48kHz, 2-channel render
            SamplingFrequency_All,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
        },
        // List of formats supported for 4-channel render with 2-channel capture using
        // the CVSD codec:
        //
        //      Render           Capture
        //   (Freq, #Chan)    (Freq, #Chan)
        //   =============    =============
        //    (16kHz, 4) <---> (16kHz, 2)
        //    ----------       ----------
        //    (32kHz, 4) <---> (16kHz, 2)
        //    (32kHz, 4) <---> (32kHz, 2)
        //
        {
            // CodecId
            microsoftCVSDCodecId,
            // IsCodecPresent,
            TRUE, // The CVSD codec is in the audio DSP.
            // RenderChannelCount
            4,
            // CaptureChannelCount
            2,
            // RenderSamplingFrequencies
            SamplingFrequency_16000Hz | SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 16kHz, 4-channel render
            SamplingFrequency_16000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 24kHz, 4-channel render
            SamplingFrequency_None, // N/A
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 32kHz, 4-channel render
            SamplingFrequency_16000Hz | SamplingFrequency_32000Hz,
            // CaptureSamplingFrequencies: List of 2-channel capture sampling
            // frequencies compatible with 48kHz, 4-channel render
            SamplingFrequency_None, // N/A
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
            // CaptureSamplingFrequencies: RFU
            SamplingFrequency_None,
        }
    };

    // Call IoSetDeviceInterfacePropertyData to associate the capabilities associated
    // with the DEVPKEY.
    WDFSTRING wdfSymbolicLinkName;
    RETURN_NTSTATUS_IF_FAILED(WdfStringCreate(
        nullptr, WDF_NO_OBJECT_ATTRIBUTES, &wdfSymbolicLinkName));
    auto deleteWdfStringOnExt = scope_exit([wdfSymbolicLinkName]() -> void
    {
        WdfObjectDelete(wdfSymbolicLinkName);
    });

    RETURN_NTSTATUS_IF_FAILED(WdfDeviceRetrieveDeviceInterfaceString(
        Device,
        &GUID_BLUETOOTH_LEAUDIO_SUPPORT_INTERFACE,
        &bluetoothLEAudioSupportInterface,
        wdfSymbolicLinkName));
    
    UNICODE_STRING symbolicLinkName;
    WdfStringGetUnicodeString(wdfSymbolicLinkName, &symbolicLinkName);

    RETURN_NTSTATUS_IF_FAILED(IoSetDeviceInterfacePropertyData(
        &symbolicLinkName,
        &DEVPKEY_BluetoothLEAudioBidirectionalMultichannelStreamingCapabilities,
        LOCALE_NEUTRAL,
        PLUGPLAY_PROPERTY_PERSISTENT,
        DEVPROP_TYPE_BINARY,
        sizeof(capabilities), capabilities));
#pragma endregion

    return STATUS_SUCCESS;
}

Articles connexes

• Extensions de classe audio ACX
• Spécification du profil audio bluetooth de base
• Spécification Bluetooth Core 5.3
• Service de spécification des capacités audio Bluetooth publiées
• Spécification du service de contrôle de flux audio Bluetooth
• Numéros attribués Bluetooth
• Directives de contournement Bluetooth HFP pour les pilotes audio
• Bluetooth HFP contourner le streaming audio