Déchargement A2DP en mode bande latérale audio (Audio Sideband A2DP Offload)

Cette rubrique décrit le déchargement A2DP en mode bande latérale audio, disponible à partir de Windows 11, build 10.0.22000 pour Bluetooth.

L’objectif principal du déchargement A2DP en mode bande latérale audio est de réduire la consommation d’énergie, par exemple lors de la lecture de musique.

Ce document suppose une certaine familiarité avec la solution bande latérale HF existante. Veuillez consulter la section contournement Bluetooth pour les pilotes audio et les spécifications A2DP Bluetooth référencées dans la section voir aussi de cette rubrique.

Conception de l’architecture bande latérale (sideband)

Le déchargement A2DP en mode bande latérale audio s’appuie sur des conceptions éprouvées existantes pour réduire la consommation d’énergie lors de la lecture de contenu audio linéaire via des haut-parleurs intégrés ou des écouteurs analogiques connectés. En bref, ces conceptions transfèrent de grandes quantités de données audio (de l’ordre d’une seconde) dans un DSP audio via un pilote audio spécifique au fournisseur. Les processeurs principaux et la plupart des autres circuits entrent dans un état de faible consommation d’énergie tandis que le DSP audio diffuse les données audio transférées via les haut-parleurs intégrés. Lorsque les données audio sont presque épuisées, le DSP génère une interruption vers le pilote audio, qui signale au système d’exploitation de transférer davantage de données audio via le pilote audio vers le DSP.

Les composants en gris clair dans le schéma suivant sont fournis par l’IHV.

Le déchargement A2DP en mode bande latérale audio s’appuie également sur une conception commune pour le chemin audio Bluetooth SCO, où le même DSP audio est connecté directement au contrôleur Bluetooth.

Cette connexion est souvent une interface I2S ou PCM, mais peut également être un bus plus riche et complexe tel que SLIMbus. Microsoft fait référence à cette architecture comme sideband audio, reflétant le fait que les transferts audio se font dans le contrôleur Bluetooth (ou autre) via un chemin alternatif plutôt que via l’interface normale du contrôleur (le « HCI »). Dans ce cas, le pilote audio transfère les données audio du système d’exploitation au DSP audio, le DSP audio transfère les données via la connexion sideband au contrôleur de bus matériel, et le contrôleur transmet les données audio au dispositif connecté. (Pour l’audio bidirectionnel, la direction inverse se produit également.) Bien que davantage de composants soient impliqués, cela peut présenter des avantages par rapport à l’interface normale du contrôleur. Dans certains cas d’utilisation (principalement les appels cellulaires), tout le chemin du signal audio de bout en bout est géré par le firmware, déchargé des processeurs principaux. Cela peut également fournir une meilleure interface pour le transfert de données audio en temps réel/isochrones vers et depuis le logiciel hôte. Pour cette connexion sideband, Microsoft définit un DDI sideband utilisé par le pilote audio pour prendre en charge les points de terminaison audio ayant cette conception physique.

Composants

Pilote audio IHV (pilote DSP audio)

Ce pilote contrôle les points de terminaison audio intégrés, l’audio cellulaire, et le sideband/offload HFP/SCO. Cette fonctionnalité nécessite que le pilote prenne également en charge le déchargement A2DP. Les responsabilités du pilote sont similaires à celles du HFP/SCO.

Pilote de transport Bluetooth IHV et contrôleur

Le déchargement A2DP n’est défini dans aucune norme Bluetooth SIG. Cette fonctionnalité améliore et ajoute des commandes HCI Bluetooth définies par Microsoft. Pour prendre en charge cette fonctionnalité, le contrôleur Bluetooth IHV ou un pilote IHV doit prendre en charge ces commandes.

Pilote de profil A2DP

Ce pilote est fourni par Windows. Ses fonctions sont décrites ci-dessous.

• Implémente les spécifications A2DP et AVDTP
• Expose des instances d’interface de périphérique PnP (l’interface bande latérale A2DP) pour que le pilote audio IHV découvre, ouvre et envoie des requêtes
• Prend en charge les requêtes IOCTL sideband définies dans ce document
• Envoie des commandes HCI Bluetooth définies par Microsoft pour le déchargement A2DP

Exigence du pilote audio IHV (pilote DSP audio)

Si un pilote audio sur un système est configuré pour le streaming sideband A2DP, il doit publier une interface de périphérique avec une classe GUID définie sur GUID_SIDEBANDAUDIO_A2DP_SUPPORT_INTERFACE {2BC51EE4-07AF-49CF-B04B-FB3F1C26AADC}. Cette interface de périphérique doit être présente au plus tard lors du démarrage PnP du pilote audio.

Structures de données sideband

Notez que certaines structures de données et constantes utilisées par le pilote audio sont définies dans l’en-tête sidebandaudio.h.

Les structures de données suivantes sont utilisées pour le sideband A2DP offload.

Descripteur de périphérique - SIDEBANDAUDIO_DEVICE_DESCRIPTOR

Le périphérique connecté peut être un périphérique composite contenant plusieurs points de terminaison audio (haut-parleur, microphone, etc.). Le pilote audio peut itérer pour chaque point de terminaison et obtenir plus de détails pour construire des filtres KS pour chaque point de terminaison.

Descripteur de point de terminaison - SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR

Le SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR est défini comme suit.

Descripteur de point de terminaison - SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR - Capacités

Les capacités sont définies comme suit.

SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR2

La bande latérale A2DP utilise une version mise à jour de la structure existante SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR pour fournir plus d’informations nécessaires au système audio Windows pour l’identification du point de terminaison - SIDEBANDAUDIO_ENDPOINT_DESCRIPTOR2.

// Number of device properties that shall be added to the audio filter factory interface.
ULONG                                   FilterInterfacePropertyCount;
DEVPROPERTY*                            FilterInterfaceProperties;

Le pilote audio obtient cette structure de données en utilisant la nouvelle requête IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR2. Lorsque la requête s’achève, le pilote audio ajoute ces propriétés de périphérique à son interface de filtre audio Topology.

Paramètres d’interface audio

Le choix et la conception du transport audio entre le périphérique audio et le contrôleur Bluetooth sont spécifiques au fournisseur. Ce transport audio est souvent une interface I2S ou PCM, mais peut également être un bus plus riche et complexe tel que SLIMbus ou potentiellement SoundWire. La conception de cette fonctionnalité ne place aucune exigence spécifique sur le transport audio. Cependant, si le codec Bluetooth est implémenté dans le DSP audio, alors le contrôleur Bluetooth doit être capable d’extraire les trames encodées des données transmises sur le transport audio pour empaqueter ces trames en paquets médias AVDTP pour la transmission.

La configuration (le cas échéant) du transport audio est considérée comme une tâche spécifique au fournisseur. Cela est facilité par les paramètres d’interface audio spécifiques au fournisseur passés entre les composants dans cette fonctionnalité. Les paramètres spécifiques au fournisseur sont définis couramment par le fournisseur du pilote audio et le fournisseur du contrôleur Bluetooth et/ou du pilote de transport. Les paramètres sont utilisés par le périphérique audio et le contrôleur Bluetooth pour configurer le transport audio entre le DSP audio et le contrôleur Bluetooth.

Par exemple, ces données peuvent inclure un ID de transport s’il existe plusieurs connexions physiques ou logiques, la configuration de l’utilisation des signaux d’une interface PCM, ou le format des données audio sur le transport.

Le pilote audio définit et obtient les paramètres d’interface audio spécifiques au fournisseur en utilisant des SIOPs, qui identifient les données en utilisant un GUID et un entier. Cependant, pour maintenir un ensemble de commandes HCI Bluetooth plus naturel, les commandes HCI définies par Microsoft passent les paramètres d’interface audio spécifiques au fournisseur en utilisant la structure suivante.

Paramètre d’interface audio

Un ID fournisseur est défini dans les numéros assignés Bluetooth : https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers.

Le pilote A2DP effectue une conversion directe entre les SIOPs fournisseur, qui sont une structure de données plus naturelle pour le pilote audio, et un paramètre d’interface audio qui est plus naturel pour le HCI Bluetooth. Le GUID SIOP fournisseur est construit à partir d’un GUID de base plus un ID fournisseur Bluetooth de 4 caractères. Seul l’ID fournisseur (et non l’ensemble du GUID) passe sur le HCI Bluetooth.

L'GUID de base est SIDEBANDAUDIO_PARAMS_SET_A2DP.

SIOPs A2DP définis par Microsoft

Microsoft définit deux SIOPs pour l’A2DP qui fournissent des informations sur les codecs. Les fournisseurs peuvent définir des SIOPs supplémentaires pour prendre en charge leur implémentation.

Codecs (codecs-SIOP)

Le pilote audio exprime sa liste de codecs A2DP pris en charge (le cas échéant) en utilisant ce SIOP. Les champs SIDEBANDAUDIO_IO_PARAM_HEADER pour ce SIOP sont définis comme suit.

Les données qui suivent cet en-tête sont une séquence de structures de capacités de codec (de taille variable) comme décrit dans les informations sur les capacités de codec ci-dessus.

Pour le reste de cette rubrique, ce paramètre est appelé le codecs-SIOP.

Codec configuré (configured-codec-SIOP)

Le pilote audio peut récupérer le codec A2DP actuellement configuré en utilisant ce SIOP. Les champs SIDEBANDAUDIO_IO_PARAM_HEADER pour ce SIOP sont définis comme suit.

Les données qui suivent cet en-tête sont une structure de capacité de codec unique (de taille variable) comme décrit dans les informations sur les capacités de codec ci-dessus.

Ce SIOP est modifiable, ce qui signifie que le pilote audio doit utiliser la requête IOCTL_SBAUD_GET_SIOP_UPDATE pour se tenir informé des changements dans le codec configuré.

Pour le reste de cette rubrique, ce paramètre est appelé le configured-codec-SIOP.

Mode de latence du codec actif (codec-latency-mode-SIOP)

Le pilote audio peut récupérer le mode de latence actif du codec A2DP actuellement configuré en utilisant ce SIOP. Les champs SIDEBANDAUDIO_IO_PARAM_HEADER pour ce SIOP sont définis comme suit.

Les données qui suivent cet en-tête sont un octet unique interprété comme un entier 8 bits non signé. La valeur SIDEBANDAUDIO_CODEC_MODE_HIGH_QUALITY indique que le codec actuellement configuré fonctionne en mode haute qualité, tandis que la valeur SIDEBANDAUDIO_CODEC_MODE_LOW_LATENCY indique que le codec fonctionne en mode faible latence. Ce SIOP est modifiable, ce qui signifie que le pilote audio doit utiliser la requête IOCTL_SBAUD_GET_SIOP_UPDATE pour se tenir informé des changements dans le mode de latence.

Actuellement, ce SIOP est uniquement utilisé lorsque le codec aptX Adaptive est actif. Pour plus d’informations sur aptX, voir Qualcomm aptX Adaptive Audio.

Pour le reste de cette rubrique, ce paramètre est appelé le codec-latency-mode-SIOP.

Taille MTU du codec L2CAP (mtu-size-SIOP)

Le pilote audio peut récupérer la taille actuelle du MTU L2CAP (en octets) en utilisant ce SIOP. Les champs SIDEBANDAUDIO_IO_PARAM_HEADER pour ce SIOP sont définis comme suit.

Les données qui suivent cet en-tête sont de 2 octets, interprétées comme un entier 16 bits non signé. Ce SIOP est modifiable, ce qui signifie que le pilote audio doit utiliser la requête IOCTL_SBAUD_GET_SIOP_UPDATE pour se tenir informé des changements de la taille du MTU.

Actuellement, ce SIOP est uniquement utilisé lorsque le codec aptX Adaptive est actif. Pour plus d’informations sur aptX, voir Qualcomm aptX Adaptive Audio.

Pour le reste de cette rubrique, ce paramètre est appelé le mtu-size-SIOP.

Utilisation des SIOPs définis par le fournisseur

Le pilote audio peut définir des SIOPs définis par le fournisseur.

SIOPs fournisseurs définis après l’ouverture de l’interface sideband et avant IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR

Le pilote A2DP enregistre les valeurs du SIOP dans une collection de SIOPs de configuration système du fournisseur. Le pilote A2DP envoie cette collection au contrôleur Bluetooth (en utilisant HCI_VS_MSFT_Avdtp_Capabilities_Configuration) lors du traitement de IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR2. Les paramètres d’interface audio retournés par le contrôleur Bluetooth sont également stockés dans la collection de SIOPs de configuration système du fournisseur. Le pilote audio peut obtenir ces valeurs à tout moment après la complétion de l’IOCTL.

SIOPs fournisseurs définis après IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR2

Le pilote A2DP échoue pour tous les SIOPs envoyés par le pilote audio après IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR2.

SIOPs fournisseurs définis après IOCTL_SBAUD_GET_ENDPOINT_DESCRIPTOR et avant IOCTL_SBAUD_STREAM_OPEN

Le pilote A2DP enregistre les valeurs du SIOP dans une collection de SIOPs de configuration de flux du fournisseur. Le pilote A2DP envoie cette collection au contrôleur Bluetooth (en utilisant HCI_VS_MSFT_Avdtp_Open) lors du traitement de IOCTL_SBAUD_STREAM_OPEN. Les paramètres d’interface audio retournés par le contrôleur Bluetooth sont également stockés dans la collection de SIOPs de configuration de flux du fournisseur. Le pilote audio peut obtenir ces valeurs à tout moment après la complétion de l’IOCTL.

Le pilote A2DP efface la collection de SIOPs de configuration de flux du fournisseur lors du traitement de IOCTL_SBAUD_STREAM_CLOSE. (Il n’efface pas la collection de SIOPs de configuration système.)

Interface sideband A2DP

L’A2DP sideband utilise les requêtes IOCTL_SBAUD_* génériques. Voir l’en-tête sidebandaudio.h pour une liste complète des IOCTLs. Cette section fournit des informations spécifiques à l’A2DP.

Classe d’interface PnP

La classe d’interface est GUID_DEVINTERFACE_A2DP_SIDEBAND_AUDIO pour l’audio Bluetooth A2DP en mode bande latérale.

IOCTLs utilisés pour les transitions d’état des pins KS

Le pilote audio envoie ces requêtes sur certaines transitions d’état des pins KS.

• À la première transition au-dessus de KSSTATE_STOP (normalement à KSSTATE_ACQUIRE), envoyez IOCTL_SBAUD_STREAM_OPEN.
• Lors de la transition vers KSSTATE_RUN, envoyez IOCTL_SBAUD_STREAM_START.
• Lors de la transition en dessous de KSSTATE_RUN, envoyez IOCTL_SBAUD_STREAM_SUSPEND.
• Lors de la fermeture de la pin KS, envoyez IOCTL_SBAUD_STREAM_CLOSE.

Extensions HCI Bluetooth définies par Microsoft pour le déchargement A2DP

Consultez Extensions HCI Bluetooth définies par Microsoft pour les extensions actuellement définies.

HCI_VS_MSFT_Read_Supported_Features

Le déchargement A2DP en mode bande latérale audio améliore la commande HCI_VS_MSFT_Read_Supported_Features en définissant un autre bit dans le paramètre de retour Supported_features pour indiquer la prise en charge des commandes AVDTP offload. Lorsque ce bit est retourné, les commandes restantes de cette section doivent être prises en charge.

Pour une description de la commande et des paramètres de retour, reportez-vous à HCI_VS_MSFT_Read_Supported_Features.

Pour les valeurs de Supported_features (8 octets), consultez également HCI_VS_MSFT_Read_Supported_Features. Une valeur supplémentaire est utilisée pour indiquer que le contrôleur prend en charge l’AVDTP offload et les commandes HCI_VS_MSFT_Avdtp_* décrites dans Événements HCI Bluetooth AVDTP définis par Microsoft.

Extensions HCI Bluetooth définies par Microsoft relatives à l’audio

L’interface hôte-contrôleur Bluetooth (HCI) spécifie toutes les interactions entre un hôte et un contrôleur radio Bluetooth. Les spécifications Bluetooth permettent des commandes et événements HCI définis par le fournisseur pour permettre une interaction non standardisée entre les hôtes et les contrôleurs. Microsoft définit des commandes et événements HCI spécifiques au fournisseur qui sont consommés par Windows. Les commandes HCI définies par Microsoft suivantes sont utilisées pour le déchargement en mode bande latérale audio.

Les commandes HCI AVDTP suivantes sont décrites dans la rubrique Bluetooth - Événements HCI Bluetooth AVDTP définis par Microsoft.

HCI_VS_MSFT_Avdtp_Capabilities_Configuration

Valeur de l’opcode de sous-commande : 7

Configure l’interface de transport audio et renvoie les capacités des codecs du contrôleur Bluetooth, qui est une liste de blocs d’informations sur les codecs. Chaque bloc d’informations sur les codecs décrit un codec pris en charge. Pour plus d’informations, veuillez consulter HCI_VS_MSFT_Avdtp_Capabilities_Configuration.

HCI_VS_MSFT_Avdtp_Open

Valeur de l’opcode de sous-commande : 8

Alloue et configure les ressources d’AVDTP offload dans le contrôleur. Pour plus d’informations, consultez HCI_VS_MSFT_Avdtp__Open.

HCI_VS_MSFT_Avdtp_Start

Valeur de l’opcode de sous-commande : 9

Cette commande commence la diffusion audio depuis le transport audio vers les paquets médias AVDTP transmis. Pour plus d’informations, consultez HCI_VS_MSFT_Avdtp_Start.

HCI_VS_MSFT_Avdtp_Suspend

Valeur de l’opcode de sous-commande : 0xA

Arrête l’activité de streaming initiée par HCI_VS_MSFT_Avdtp_Start. Pour plus d’informations, consultez HCI_VS_MSFT_Avdtp_Suspend.

HCI_VS_MSFT_Avdtp_Close

Valeur de l’opcode de sous-commande : 0xB

Libère les ressources d’AVDTP offload allouées par HCI_VS_MSFT_Avdtp_Open. Pour plus d’informations, consultez HCI_VS_MSFT_Avdtp_Close.

Codecs Bluetooth dans le DSP audio ou le contrôleur Bluetooth

L’implémentation prend en charge les codecs Bluetooth hébergés dans le DSP audio et/ou le contrôleur Bluetooth. Le codecs-SIOP fournit un mécanisme permettant au pilote audio d’indiquer une liste de codecs pris en charge. De même, la commande HCI_VS_MS_Avdtp_Capabilities_Configuration permet au contrôleur Bluetooth de renvoyer une liste de codecs pris en charge. Notez qu’au moins l’un des deux, le pilote A2DP et le contrôleur Bluetooth, doit renvoyer une liste de codecs pris en charge.

Le pilote A2DP ne peut pas se croiser ou fusionner de manière fiable les listes de codecs A2DP pris en charge par le pilote audio et le contrôleur Bluetooth. Si les deux renvoient des codecs A2DP pris en charge, Windows utilise uniquement la liste renvoyée par le pilote de transport Bluetooth.

Si la solution IHV nécessite l’intersection ou la fusion des capacités liées aux codecs du DSP audio et des capacités du contrôleur Bluetooth, alors le pilote audio peut indiquer ses capacités via soit le codecs-SIOP (si la représentation standard est suffisante) soit un SIOP fournisseur. Le pilote A2DP transmet les SIOPs au contrôleur Bluetooth, qui peut ensuite croiser les capacités et renvoyer l’ensemble résultant de codecs pris en charge à partir de HCI_VS_MSFT_Avdtp_Capabilities_Configuration.

Voir aussi

Extensions HCI Bluetooth définies par Microsoft

Contournement Bluetooth pour les pilotes audio

Directives de gestion de contrôle de l’alimentation pour le pilote de bus de transport Bluetooth

A2DP 1.3.1 (spécification Bluetooth)

AVDTP 1.3 (spécification Bluetooth)