Démarrage de l’appareil HFP
Cet article explique le processus lors de l’arrivée d’un appareil de profil mains libres Bluetooth dans le système audio.
Pour chaque appareil HFP couplé qui arrive dans le système audio, le pilote Windows HFP enregistre une interface d’appareil dans la classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Le pilote audio utilise les notifications d’interface de périphérique pour rester informé de toutes les instances des interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Le pilote audio appelle IoRegisterPlugPlayNotification à partir de sa routine de pilote AVStrMiniDevicePostStart (ou d’une routine Portcls équivalente) pour inscrire un rappel afin de découvrir les appareils HFP actuellement installés et d’être averti des nouveaux appareils HFP.
Lorsque le pilote audio appelle IoRegisterPlugPlayNotification, l’appel est effectué à l’aide des paramètres suivants :
- EventCategory est défini sur EventCategoryDeviceInterfaceChange.
- EventCategoryFlags est généralement défini sur PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES pour recevoir des notifications immédiates des interfaces existantes. Toutefois, certaines autres conceptions de pilotes audio peuvent trouver des interfaces existantes par d’autres moyens.
- EventCategoryData est défini sur GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
- DriverObject est défini sur DriverObject du pilote audio.
- CallbackRoutine est défini sur une routine dans le pilote audio qui recevra les notifications.
Les sections suivantes décrivent les tâches que le pilote audio peut effectuer pour chaque instance inscrit d’un appareil HFP jumelé.
Gestion des instances d’interface
Pour chaque interface instance inscrite dans la classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, le pilote audio doit utiliser le protocole suivant pour la communication :
- Lorsque Windows appelle la routine de rappel du pilote audio inscrite lorsque le pilote audio appelé IoRegisterPlugPlayNotification, Windows transmet un lien symbolique pour l’interface HFP, à l’aide de DEVICE_INTERFACE_CHANGE_NOTIFICATION. SymbolicLinkName.
- Lorsque le pilote audio appelle IoGetDeviceObjectPointer, le pilote utilise le lien symbolique pour obtenir L’objet FileObject HFP et l’objet DeviceObject pour l’appareil HFP.
- Lorsque le pilote audio envoie des IOCTL au pilote HFP, celui-ci utilise l’objet FileObject HFP et l’objet DeviceObject pour l’appareil HFP.
Récupération d’informations statiques
Le pilote audio peut récupérer des informations statiques à partir du pilote HFP. Par exemple, le pilote HFP peut fournir le ksnodetype, l’ID de conteneur et le nom convivial du périphérique HFP jumelé. Le pilote audio peut utiliser ces informations pour créer et initialiser un ou plusieurs filtres KS représentant le périphérique HFP jumelé. Le pilote audio utilise IOCTL_BTHHFP_DEVICE_GET_DESCRIPTOR pour obtenir ces informations.
Le pilote audio peut également récupérer l’adresse Bluetooth du périphérique HFP jumelé. Chaque appareil HFP jumelé a une adresse Bluetooth unique, qui peut être utile en tant que chaîne d’identificateur unique. Pour plus d’informations, consultez Obtention de l’adresse Bluetooth d’un appareil HF.
Création, initialisation d’un contexte de fabrique de filtres spécifique à l’audio
Pour créer et initialiser un contexte de fabrique de filtres spécifique à l’audio, le pilote audio doit stocker HFP DeviceObject et HFP FileObject dans le contexte de fabrique de filtre, puis initialiser le champ IsConnected sur false.
Création de la fabrique de filtre KS
Pour chaque appareil instance dans la classe d’interface GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, le pilote audio crée et active une ou plusieurs fabriques de filtres.
Si le pilote audio est un pilote AVStream, le pilote audio appelle KsCreateFilterFactory pour ajouter la nouvelle fabrique de filtre et KsFilterFactorySetDeviceClassesState pour activer l’usine. Si le pilote audio est un pilote PortCls, il crée et active indirectement les fabriques de filtre KS en appelant PcRegisterSubdevice. Pour de nombreuses conceptions de pilotes audio PortCls, il existe deux sous-appareils inscrits pour un périphérique HFP jumelé donné.
Chaque fabrique de filtre (ou, pour les pilotes audio PortCls, chaque paire de fabriques de filtres) représente la fonctionnalité audio d’un seul appareil HFP jumelé. Le pilote audio crée des fabriques de filtres distinctes pour chaque appareil HFP jumelé représenté par des instances uniques d’interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Pour chaque périphérique HFP couplé, le pilote audio doit utiliser des chaînes uniques pour le paramètre RefString de KsCreateFilterFactory ou le paramètre Name de PcRegisterSubdevice. Le développeur de pilotes peut trouver utile d’utiliser la chaîne d’adresse Bluetooth de l’appareil HFP jumelé comme chaîne unique. Pour plus d’informations sur la façon de récupérer la chaîne unique, consultez Obtention de l’adresse Bluetooth de l’appareil HF .
Notez qu’il n’existe pas de nombre maximal spécifique d’appareils HFP associés possibles. Le pilote audio doit donc éviter de coder en dur des limitations spécifiques. Au lieu de cela, le pilote audio doit gérer correctement l’arrivée dynamique et la suppression de plusieurs interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
Toutefois, dans la pratique, un pilote PortCls doit spécifier un nombre maximal de sous-appareils lorsqu’il appelle PcAddAdapterDevice. PcAddAdapterDevice pré-alloue de la mémoire supplémentaire pour chaque sous-appareil potentiel. Le développeur de pilotes audio doit sélectionner un nombre suffisamment élevé pour prendre en charge de nombreux appareils jumelés, mais en même temps sélectionner un nombre qui n’entraîne pas de gaspillage de ressources. Par exemple, la prise en charge de deux appareils HFP uniquement peut être inadéquate, et la prise en charge de deux milliers entraînerait certainement un dépassement des ressources. Toutefois, il est probable que la prise en charge de seize personnes soit raisonnable.
Si, au moment de l’exécution, le pilote audio est averti d’une autre interface GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, mais qu’il a déjà inscrit son nombre maximal de sous-appareils, le pilote audio peut appeler un algorithme pour choisir un appareil HFP jumelé dont il peut annuler l’inscription pour faire de la place pour le nouveau périphérique HFP. Par exemple, le pilote audio peut effectuer le suivi du périphérique HFP avec la connexion la plus ancienne. Alors qu’un pilote audio plus simple, mais peut-être moins convivial, pourrait simplement ignorer l’interface GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS supplémentaire après avoir atteint son maximum.
Envoi de la connexion get status IOCTL
Le pilote audio envoie la connexion get status IOCTL pour obtenir des informations sur les modifications apportées à la connexion.
Envoi du volume get status IOCTL
Le pilote audio envoie le volume get status IOCTL pour obtenir des informations sur les changements de niveau de volume qui se sont produits dans le status de volume du casque.