Avvio del dispositivo HFP
Questo articolo illustra il processo quando un dispositivo HFP (Hands-Free Profile) Bluetooth arriva nel sistema audio.
Per ogni dispositivo HFP associato che arriva nel sistema audio, il driver HFP di Windows registra un'interfaccia del dispositivo nella classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Il driver audio usa le notifiche dell'interfaccia del dispositivo per rimanere informati di tutte le istanze delle interfacce GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Il driver audio chiama IoRegisterPlugPlayNotification dall'interno della routine driver AVStrMiniDevicePostStart (o da una routine Portcls equivalente) per registrare un callback per individuare i dispositivi HFP attualmente installati e ricevere una notifica dei nuovi dispositivi HFP.
Quando il driver audio chiama IoRegisterPlugPlayNotification, la chiamata viene effettuata usando i parametri seguenti:
- EventCategory è impostato su EventCategoryDeviceInterfaceChange.
- EventCategoryFlags è in genere impostato su PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES per ricevere notifiche immediate delle interfacce esistenti. Tuttavia, alcune progettazioni di driver audio alternativi potrebbero trovare interfacce esistenti tramite altri mezzi.
- EventCategoryData è impostato su GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
- DriverObject è impostato su DriverObject del driver audio.
- CallbackRoutine è impostato su una routine nel driver audio che riceverà le notifiche.
Le sezioni seguenti illustrano le attività che il driver audio può eseguire per ogni istanza registrata di un dispositivo HFP associato.
Gestione delle istanze dell'interfaccia
Per ogni istanza di interfaccia registrata nella classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, il driver audio deve usare il protocollo seguente per la comunicazione:
- Quando Windows chiama la routine di callback del driver audio registrata quando il driver audio denominato IoRegisterPlugPlayNotification, Windows passa un collegamento simbolico per l'interfaccia HFP, usando DEVICE_INTERFACE_CHANGE_NOTIFICATION. SymbolicLinkName.
- Quando il driver audio chiama IoGetDeviceObjectPointer, il driver usa il collegamento simbolico per ottenere HFP FileObject e DeviceObject per il dispositivo HFP.
- Quando il driver audio invia IOCTLs al driver HFP, il driver usa HFP FileObject e DeviceObject per il dispositivo HFP.
Recupero di informazioni statiche
Il driver audio può recuperare informazioni statiche dal driver HFP. Ad esempio, il driver HFP può specificare ksnodetype, l'ID contenitore e il nome descrittivo del dispositivo HFP associato. Il driver audio può usare queste informazioni per creare e inizializzare un filtro KS o filtri che rappresentano il dispositivo HFP associato. Il driver audio usa IOCTL_BTHHFP_DEVICE_GET_DESCRIPTOR per ottenere queste informazioni.
Il driver audio può anche recuperare l'indirizzo Bluetooth del dispositivo HFP associato. Ogni dispositivo HFP associato ha un indirizzo Bluetooth univoco, che può essere utile come stringa di identificatore univoco. Per altre informazioni, vedere Ottenere l'indirizzo Bluetooth del dispositivo HF.
Creazione, inizializzazione del contesto di factory di filtro specifico dell'audio
Per creare e inizializzare un contesto di factory di filtro specifico per l'audio, il driver audio deve archiviare HFP DeviceObject e HFP FileObject nel contesto della factory del filtro e quindi inizializzare il campo IsConnected su false.
Creazione della factory di filtro KS
Per ogni istanza del dispositivo nella classe di interfaccia GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, il driver audio crea e abilita una o più factory di filtro.
Se il driver audio è un driver AVStream, il driver audio chiama KsCreateFilterFactory per aggiungere la nuova factory di filtro e KsFilterFactorySetDeviceClassesState per abilitare la factory. Se il driver audio è un driver PortCls, crea e abilita indirettamente le factory di filtro KS chiamando PcRegisterSubdevice. Per molte progettazioni di driver audio PortCls, sono presenti due sotto-dispositivi registrati per un determinato dispositivo HFP associato.
Ogni factory di filtro (o, per driver audio PortCls, ogni coppia di factory di filtri) rappresenta la funzionalità audio di un singolo dispositivo HFP associato. Il driver audio crea factory di filtro separate per ogni dispositivo HFP associato rappresentato da istanze univoche di interfacce GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Per ogni dispositivo HFP associato, il driver audio deve usare stringhe univoche per il parametro RefString di KsCreateFilterFactory o il parametro Name di PcRegisterSubdevice. Lo sviluppatore di driver potrebbe trovare utile usare la stringa di indirizzo Bluetooth del dispositivo HFP abbinata come stringa univoca. Per informazioni su come recuperare la stringa univoca, vedere Ottenere l'indirizzo Bluetooth del dispositivo HF .
Si noti che non esiste un numero massimo specifico di dispositivi HFP associati, quindi il driver audio deve evitare limitazioni specifiche per il hardcoded. Al contrario, il driver audio deve gestire correttamente l'arrivo dinamico e la rimozione di più interfacce GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
Come pratica, tuttavia, un driver PortCls deve specificare un numero massimo di sotto-dispositivi quando chiama PcAddAdapterDevice. PcAddAdapterDevice pre-alloca memoria aggiuntiva per ogni potenziale sotto-dispositivo. Lo sviluppatore di driver audio deve selezionare un numero sufficientemente elevato per ospitare molti dispositivi abbinati, ma allo stesso tempo selezionare un numero che non comporta uno spreco di risorse. Ad esempio, il supporto di solo due dispositivi HFP potrebbe essere inadeguato e il supporto di duemila causerebbe certamente risorse sovraestese. Tuttavia, è probabile che il supporto di sedici sia ragionevole.
Se in fase di esecuzione il driver audio riceve una notifica di un'altra interfaccia GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, ma ha già registrato il numero massimo di sotto-dispositivi, il driver audio può richiamare un algoritmo per scegliere un dispositivo HFP associato i cui sotto-dispositivi può annullare la registrazione per rendere disponibile il nuovo dispositivo HFP. Ad esempio, il driver audio potrebbe tenere traccia del dispositivo HFP con la connessione meno recente. Mentre un driver audio più semplice ma forse meno intuitivo potrebbe semplicemente ignorare l'interfaccia aggiuntiva GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS dopo aver raggiunto il massimo.
Invio dello stato di connessione get IOCTL
Il driver audio invia il get connection status IOCTL per ottenere informazioni su eventuali modifiche apportate nella connessione.
Invio dello stato del volume get IOCTL
Il driver audio invia il get volume status IOCTL per ottenere informazioni sulle modifiche apportate al livello di volume che si sono verificate nello stato del volume del visore VR.