Connexion d’appareil HFP
Cet article explique comment le système audio détermine et gère les informations de connexion status d’un appareil de profil mains libres (HFP) Bluetooth.
Le pilote audio doit prendre en charge KSPROPERTY_JACK_DESCRIPTION et gérer un champ IsConnected dans le contexte de fabrique de filtre. Le pilote utilise cette valeur lors de la gestion de la propriété KSPROPERTY_JACK_DESCRIPTION .
Lorsque IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE se termine correctement, le pilote audio met à jour IsConnected avec le nouveau status de connexion. Si le status a changé, le pilote audio déclenche l’événement KSEVENT_PINCAPS_JACKINFOCHANGE, ce qui entraîne la réévaluation de l’état de la connexion par le système audio. Le pilote audio appelle ensuite une autre instance de IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE pour recevoir la modification status suivante. Si une demande de modification de status antérieure est toujours en attente, ce deuxième appel échoue et le pilote audio ne met pas à jour son status de connexion et n’effectue pas une autre demande d’informations de modification status.
Comme indiqué dans Considérations relatives à la diffusion en continu du noyau, le pilote audio doit prendre en charge KSPROPERTY_ONESHOT_RECONNECT et KSPROPERTY_ONESHOT_DISCONNECT. Les gestionnaires de ces propriétés doivent envoyer des IOCTL REQUESTCONNECT et REQUESTDISCONNECT, respectivement, au pilote HFP. Ces IOCTL se terminent rapidement, et le pilote audio doit être prêt à répondre aux résultats retournés.
Cet article traite également d’autres facteurs liés à la connexion du périphérique audio Bluetooth que le développeur du pilote audio doit connaître.
Canal de flux
Le canal de flux représente l’allocation de bande passante par le pilote audio sur les ondes. Pour la plupart, il s’agit du canal SCO. Toutefois, certains détails de la gestion du canal SCO status sont entièrement gérés dans le pilote HFP. Cela inclut par exemple les déconnexions à distance qui peuvent être dues à des scénarios d’appel où le HF lance un transfert audio vers le groupe de disponibilité (avec le PC jouant le rôle du groupe de disponibilité dans ce cas).
États d’épingle du filtre audio
Le pilote audio implémente des gestionnaires d’état de broche KS pour deux broches KS. Le canal de flux SCO est requis pour que l’une de ces broches transfère des données par voie aérienne. Lorsque l’une de ces broches passe à KSSTATE_ACQUIRE, le pilote audio ouvre le canal en envoyant IOCTL_BTHHFP_STREAM_OPEN au pilote HFP. Cet appel asynchrone peut prendre plusieurs secondes. Le pilote audio n’a pas besoin d’implémenter son propre mécanisme de délai d’expiration et doit attendre que l’IOCTL se termine avant de terminer la transition vers KSSTATE_ACQUIRE.
Lorsque les deux broches KS passent à KSSTATE_STOP, le pilote audio envoie IOCTL_BTHHFP_STREAM_CLOSE au pilote HFP, ce qui se termine rapidement.
Pour déterminer quand envoyer IOCTL_BTHHFP_STREAM_OPEN et IOCTL_BTHHFP_STREAM_CLOSE, le pilote audio peut utiliser un mécanisme de comptage de références simple pour suivre le nombre de broches qui nécessitent le canal de flux SCO. Le pilote audio ouvre et ferme le canal de flux SCO lorsque le nombre de références passe de 0 à 1.
Sur IOCTL_BTHHFP_STREAM_OPEN, le pilote HFP demande un canal SCO, s’il n’est pas déjà ouvert, et termine la demande avec les résultats de la requête SCO. Sur IOCTL_BTHHFP_STREAM_CLOSE, le pilote HFP demande une déconnexion du canal SCO, le cas échéant.
Connexion et déconnexion SCO à distance
Lors d’une déconnexion SCO distante, si le canal de flux est fermé, le pilote HFP ne fait rien. Si le canal de flux est ouvert, le pilote HFP démarre un minuteur de reconnexion. Lorsque le minuteur expire, si SCO est toujours déconnecté et que le canal de flux est toujours ouvert, le pilote demande un canal SCO. Notez qu’aucun transfert de données audio sur les ondes pendant la déconnexion de SCO, il y aura donc un écart dans l’audio pendant cette période. Si la requête SCO échoue, le pilote HFP signale un canal de flux status le changement vers le pilote audio en effectuant les IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE d’appel. Cela devrait être rare, car la déconnexion SCO distante est normalement associée à l’appareil HF qui demande le transfert de l’audio d’appel vers la passerelle audio. Le pilote audio doit considérer qu’il s’agit d’une condition d’erreur de flux intermédiaire.
Cette procédure laisse le temps à une application VoIP de recevoir un rappel de transfert audio à partir de l’API CallButtons et de libérer proprement ses ressources audio sur le point de terminaison HFP, au lieu de provoquer des erreurs de diffusion en continu.
Sur une connexion SCO distante, si le canal de flux est ouvert, le pilote accepte simplement la connexion. Si le canal de flux est fermé, le pilote HFP accepte la connexion et démarre un minuteur de déconnexion. Lorsque le minuteur de déconnexion expire, si SCO est toujours connecté et que le canal de flux est toujours fermé, le pilote interrompt la connexion SCO.
Cette procédure laisse le temps à une application VoIP de recevoir un rappel de transfert audio de l’API CallButtons et d’établir des ressources audio sur le point de terminaison HFP, sans rejeter ou fermer prématurément la connexion SCO.