Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird erläutert, wie das Audiosystem Verbindungsstatusinformationen für ein Bluetooth-Freisprechprofilgerät (HFP) bestimmt und verarbeitet.
Der Audiotreiber muss KSPROPERTY_JACK_DESCRIPTION unterstützen und ein IsConnected-Feld im Filterfactorykontext verwalten. Der Treiber verwendet diesen Wert beim Behandeln der KSPROPERTY_JACK_DESCRIPTION-Eigenschaft .
Wenn IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE erfolgreich abgeschlossen ist, aktualisiert der Audiotreiber IsConnected mit dem neuen Verbindungsstatus. Wenn sich der Status geändert hat, löst der Audiotreiber das KSEVENT_PINCAPS_JACKINFOCHANGE-Ereignis aus, wodurch das Audiosystem den Verbindungsstatus neu bewertet. Der Audiotreiber ruft dann eine andere Instanz von IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE auf, um die nächste Statusänderung zu erhalten. Wenn eine frühere Statusänderungsanforderung noch aussteht, schlägt dieser zweite Aufruf fehl, und der Audiotreiber aktualisiert den Verbindungsstatus nicht und stellt keine weitere Anforderung für Statusänderungsinformationen vor.
Wie in Den Ü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, auf die zurückgegebenen Ergebnisse zu reagieren.
In diesem Artikel werden auch andere Verbindungsfaktoren für Bluetooth-Audiogeräte behandelt, die vom Entwickler des Audiotreibers beachtet werden müssen.
Streamkanal
Der Streaming-Kanal repräsentiert die Zuordnung der Funkbandbreite des Audiotreibers. In den meisten Fällen ist dies der SCO-Kanal. Einige Details zur Verwaltung des SCO-Kanalstatus werden jedoch vollständig innerhalb des HFP-Treibers behandelt. Dazu gehören beispielsweise Ferntrennungen, die auf Anrufszenarien zurückzuführen sein können, bei denen die HF eine Audioübertragung an die AG initiiert (wobei der PC in diesem Fall die Rolle der AG spielt).
Audiofilter-Pinstatus
Der Audiotreiber implementiert KS-Pin-Zustandshandler für zwei KS-Pins. Der SCO-Streamkanal ist für einen dieser Pins erforderlich, um Daten über die Luft zu übertragen. Wenn eine dieser Pins zu KSSTATE_ACQUIRE wechselt, öffnet der Audiotreiber den Kanal, indem IOCTL_BTHHFP_STREAM_OPEN an den HFP-Treiber gesendet wird. Dieser asynchrone Aufruf kann mehrere 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, was schnell abgeschlossen wird.
Um festzustellen, wann IOCTL_BTHHFP_STREAM_OPEN und IOCTL_BTHHFP_STREAM_CLOSE gesendet werden sollen, 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 zu 1 ändert.
Auf IOCTL_BTHHFP_STREAM_OPEN fordert der HFP-Treiber einen SCO-Kanal an, wenn er noch nicht geöffnet ist, und schließt die Anforderung mit den Ergebnissen der SCO-Anforderung ab. Bei IOCTL_BTHHFP_STREAM_CLOSE fordert der HFP-Treiber eine Trennung des SCO-Kanals an, wenn einer geöffnet ist.
Remote-SCO-Verbindung herstellen und trennen
Bei einer Remote-SCO-Trennung führt der HFP-Treiber nichts aus, wenn der Datenstromkanal geschlossen ist. Wenn der Streamkanal geöffnet wird, startet der HFP-Treiber einen erneuten Verbindungstimer. Wenn der Zeitgeber abläuft und die SCO-Verbindung noch getrennt ist und der Datenstromkanal noch geöffnet ist, beantragt der Treiber einen SCO-Kanal. Beachten Sie, dass keine Audiodaten über die Luft übertragen werden, während SCO getrennt ist, sodass in diesem Zeitraum eine Audiolücke entsteht. Wenn die SCO-Anforderung fehlschlägt, signalisiert der HFP-Treiber eine Änderung des Streamkanalstatus an den Audiotreiber, indem er alle aufrufenden IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE abschließt. Dies sollte selten sein, da die Trennung der Remote-SCO-Verbindung normalerweise mit dem HF-Gerät assoziiert ist, das die Übertragung von Anrufaudio an das Audio-Gateway 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 seine Audioressourcen auf dem HFP-Endpunkt sauber freizugeben, anstatt Streamingfehler zu verursachen.
Wenn der Datenstromkanal geöffnet ist, akzeptiert der Treiber bei einer Remote-SCO-Verbindung einfach die Verbindung. Wenn der Datenstromkanal geschlossen ist, akzeptiert der HFP-Treiber die Verbindung und startet einen Disconnect-Timer. Wenn der Zeitgeber für die Trennung abläuft, wenn SCO noch verbunden ist und der Datenstromkanal noch geschlossen ist, bricht der Treiber die SCO-Verbindung auf.
Mit diesem Verfahren kann eine VoIP-Anwendung einen Audioübertragungsrückruf von der CallButtons-API empfangen und Audioressourcen auf dem HFP-Endpunkt einrichten, ohne die SCO-Verbindung vorzeitig abzulehnen oder zu schließen.