HFP-Geräteverbindung
In diesem Artikel wird erläutert, wie das Audiosystem die Verbindung status Informationen für ein HFP-Gerät (Bluetooth Hands-Free Profile) bestimmt und verarbeitet.
Der Audiotreiber muss KSPROPERTY_JACK_DESCRIPTION und ein IsConnected-Feld im Kontext der Filterfactory unterstützen und verwalten. Der Treiber verwendet diesen Wert bei der Verarbeitung der eigenschaft KSPROPERTY_JACK_DESCRIPTION .
Wenn IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE erfolgreich abgeschlossen wurde, aktualisiert der Audiotreiber IsConnected mit der neuen Verbindungs-status. Wenn sich die status geändert hat, löst der Audiotreiber das KSEVENT_PINCAPS_JACKINFOCHANGE-Ereignis aus, sodass das Audiosystem den Verbindungsstatus neu auswertet. Der Audiotreiber ruft dann eine weitere instance von IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE auf, um die nächste status Änderung zu empfangen. Wenn eine frühere status Änderungsanforderung noch aussteht, schlägt dieser zweite Aufruf fehl, und der Audiotreiber aktualisiert seine Verbindung nicht status und stellt keine weitere Anforderung für status Änderungsinformationen.
Wie unter Überlegungen zum Kernelstreaming erläutert, muss der Audiotreiber KSPROPERTY_ONESHOT_RECONNECT und KSPROPERTY_ONESHOT_DISCONNECT unterstützen. Die Handler für diese Eigenschaften müssen REQUESTCONNECT- bzw. REQUESTDISCONNECT-IOCTLs an den HFP-Treiber senden. Diese IOCTLs werden schnell abgeschlossen, und der Audiotreiber muss bereit sein, um auf die zurückgegebenen Ergebnisse zu reagieren.
In diesem Artikel werden auch andere Verbindungsfaktoren für Bluetooth-Audiogeräte behandelt, die dem Entwickler von Audiotreibern bewusst sein müssen.
Streamkanal
Der Streamkanal stellt die Zuordnung der Over-the-Air-Bandbreite durch den Audiotreiber dar. Dies ist größtenteils der SCO-Kanal. Einige Details zur Verwaltung des SCO-Kanals status werden jedoch vollständig innerhalb des HFP-Treibers verarbeitet. Dies umfasst z. B. Remote-Trennungen, die auf Aufrufszenarien zurückzuführen sein können, in denen der HF eine Audioübertragung an die Ag initiiert (wobei der PC in diesem Fall die Rolle des AG übernimmt).
Audiofilter-Pinzustände
Der Audiotreiber implementiert KS-Pinzustandshandler für zwei KS-Pins. Der SCO-Streamkanal ist für einen dieser Pins erforderlich, um Daten über die Luft zu übertragen. Wenn einer dieser Pins auf KSSTATE_ACQUIRE übergeht, öffnet der Audiotreiber den Kanal, indem er IOCTL_BTHHFP_STREAM_OPEN an den HFP-Treiber sendet. Der Abschluss dieses asynchronen Aufrufs kann einige Sekunden dauern. Der Audiotreiber muss keinen eigenen Timeoutmechanismus implementieren und sollte warten, bis die IOCTL abgeschlossen ist, bevor der Übergang zu KSSTATE_ACQUIRE abgeschlossen ist.
Wenn beide KS-Pins zu KSSTATE_STOP wechseln, sendet der Audiotreiber IOCTL_BTHHFP_STREAM_CLOSE an den HFP-Treiber, der schnell abgeschlossen wird.
Um zu bestimmen, wann IOCTL_BTHHFP_STREAM_OPEN und IOCTL_BTHHFP_STREAM_CLOSE gesendet werden soll, kann der Audiotreiber einen einfachen Verweiszählmechanismus verwenden, um die Anzahl der Pins nachzuverfolgen, die den SCO-Streamkanal erfordern. Der Audiotreiber würde den SCO-Streamkanal öffnen und schließen, wenn sich die Referenzanzahl von 0 auf 1 ändert.
Auf IOCTL_BTHHFP_STREAM_OPEN fordert der HFP-Treiber einen SCO-Kanal an, sofern dieser noch nicht geöffnet ist, und schließt die Anforderung mit den Ergebnissen der SCO-Anforderung ab. Auf IOCTL_BTHHFP_STREAM_CLOSE fordert der HFP-Treiber eine SCO-Kanalverbindung an, sofern eine geöffnet ist.
Remote-SCO-Verbindung herstellen und trennen
Wenn der Streamkanal bei einer Remote-SCO-Verbindung geschlossen ist, macht der HFP-Treiber nichts. Wenn der Streamkanal geöffnet wird, startet der HFP-Treiber einen Timer für die erneute Verbindung. Wenn der Timer abläuft, wenn SCO weiterhin getrennt ist und der Streamkanal weiterhin geöffnet ist, fordert der Treiber einen SCO-Kanal an. Beachten Sie, dass keine Audiodatenübertragungen über die Luft erfolgen, während SCO getrennt ist, sodass es in diesem Zeitraum zu einer Audiolücke kommt. Wenn die SCO-Anforderung fehlschlägt, signalisiert der HFP-Treiber einen Streamkanal, status an den Audiotreiber ändern, indem er alle Aufrufe IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE abschließt. Dies sollte selten sein, da die Remote-SCO-Verbindung normalerweise mit dem HF-Gerät verbunden ist, das die Übertragung von Anrufaudio an das Audiogateway anfordert. Der Audiotreiber sollte dies als Mid-Stream-Fehlerbedingung betrachten.
Dieses Verfahren ermöglicht es einer VoIP-Anwendung, einen Audioübertragungsrückruf von der CallButtons-API zu empfangen und ihre Audioressourcen auf dem HFP-Endpunkt sauber freizugeben, anstatt Streamingfehler zu verursachen.
Wenn der Streamkanal bei einer SCO-Remoteverbindung geöffnet ist, akzeptiert der Treiber einfach die Verbindung. Wenn der Streamkanal geschlossen ist, akzeptiert der HFP-Treiber die Verbindung und startet einen Trenntimer. Wenn der Zeitgeber für die Trennung abläuft und SCO weiterhin verbunden ist und der Streamkanal weiterhin geschlossen ist, unterbricht der Treiber die SCO-Verbindung.
Dieses Verfahren ermöglicht es einer VoIP-Anwendung, einen Audioübertragungsrückruf von der CallButtons-API zu empfangen und Audioressourcen auf dem HFP-Endpunkt einzurichten, ohne die SCO-Verbindung vorzeitig abzulehnen oder zu schließen.