Connessione del dispositivo HFP
Questo articolo illustra come il sistema audio determina e gestisce le informazioni sullo stato della connessione per un dispositivo HFP (Bluetooth hands-free profile).
Il driver audio deve supportare KSPROPERTY_JACK_DESCRIPTION e mantenere un campo IsConnected nel contesto della factory di filtro. Il driver usa questo valore durante la gestione della proprietà KSPROPERTY_JACK_DESCRIPTION .
Quando IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE viene completato correttamente, il driver audio aggiorna IsConnected con il nuovo stato di connessione. Se lo stato è cambiato, il driver audio genera l'evento KSEVENT_PINCAPS_JACKINFOCHANGE , causando la rivalutazione dello stato di connessione del sistema audio. Il driver audio chiama quindi un'altra istanza di IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE per ricevere la modifica dello stato successivo. Se una richiesta di modifica dello stato precedente è ancora in sospeso, questa seconda chiamata ha esito negativo e il driver audio non aggiorna lo stato della connessione e non effettua un'altra richiesta di modifica dello stato.
Come illustrato nelle considerazioni sul flusso kernel, il driver audio deve supportare KSPROPERTY_ONESHOT_RECONNECT e KSPROPERTY_ONESHOT_DISCONNECT. I gestori per queste proprietà devono inviare rispettivamente REQUESTCONNECT e REQUESTDISCONNECT IOCTLs al driver HFP. Questi IOCTLs vengono completati rapidamente e il driver audio deve essere pronto per rispondere ai risultati restituiti.
Questo articolo illustra anche altri fattori correlati alla connessione del dispositivo audio Bluetooth a cui deve essere a conoscenza lo sviluppatore di driver audio.
Canale di flusso
Il canale di flusso rappresenta l'allocazione del driver audio della larghezza di banda over-the-air. Per la maggior parte, questo è il canale SCO. Tuttavia, alcuni dei dettagli della gestione dello stato del canale SCO vengono gestiti interamente all'interno del driver HFP. Ciò include ad esempio le disconnesse remote che possono essere dovute a scenari di chiamata in cui l'HF avvia un trasferimento audio al gruppo di disponibilità (con il PC che gioca il ruolo del gruppo di disponibilità in questo caso).
Stati del pin del filtro audio
Il driver audio implementa i gestori dello stato del pin KS per due pin KS. Il canale di flusso sco è necessario per uno di questi pin per trasferire i dati sull'aria. Quando uno di questi pin passa a KSSTATE_ACQUIRE, il driver audio apre il canale inviando IOCTL_BTHHFP_STREAM_OPEN al driver HFP. Questa chiamata asincrona può richiedere diversi secondi per completare. Il driver audio non deve implementare il proprio meccanismo di timeout e deve attendere il completamento dell'IOCTL prima di completare la transizione alla KSSTATE_ACQUIRE.
Quando entrambi i pin KS passano a KSSTATE_STOP, il driver audio invia IOCTL_BTHHFP_STREAM_CLOSE al driver HFP, che viene completato rapidamente.
Per determinare quando inviare IOCTL_BTHHFP_STREAM_OPEN e IOCTL_BTHHFP_STREAM_CLOSE, il driver audio può usare un semplice meccanismo di conteggio dei riferimenti per tenere traccia del numero di pin che richiedono il canale di flusso SCO. Il driver audio aprire e chiudere il canale di flusso sco quando il conteggio dei riferimenti cambia da 0 a 1.
In IOCTL_BTHHFP_STREAM_OPEN, il driver HFP richiede un canale sco, se non è già aperto e completa la richiesta con i risultati della richiesta sco. In IOCTL_BTHHFP_STREAM_CLOSE, il driver HFP richiede una disconnessione del canale SCO, se si apre.
Connessione e disconnessione remota sco
In una disconnessione sco remota, se il canale di flusso viene chiuso, il driver HFP non fa nulla. Se il canale di flusso viene aperto, il driver HFP avvia un timer di riconnessione. Al termine del timer, se sco è ancora disconnesso e il canale di flusso è ancora aperto, il driver richiede un canale SCO. Si noti che nessun trasferimento di dati audio sull'aria mentre sco è disconnesso, quindi ci sarà un divario nell'audio durante questo periodo. Se la richiesta sco ha esito negativo, il driver HFP segnala una modifica dello stato del canale di flusso al driver audio completando qualsiasi chiamata IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE. Questo dovrebbe essere raro, poiché la disconnessione remota sco è normalmente associata al dispositivo HF che richiede il trasferimento dell'audio della chiamata al gateway audio. Il driver audio deve considerare questa condizione di errore mid-stream.
Questa procedura consente a un'applicazione VoIP di ricevere un callback di trasferimento audio dall'API CallButtons e rilasciare le risorse audio nell'endpoint HFP anziché causare errori di streaming.
In una connessione sco remota, se il canale di flusso è aperto, il driver accetta semplicemente la connessione. Se il canale di flusso viene chiuso, il driver HFP accetta la connessione e avvia un timer di disconnessione. Al termine del timer di disconnessione, se sco è ancora connesso e il canale di flusso è ancora chiuso, il driver interrompe la connessione SCO.
Questa procedura consente a un'applicazione VoIP di ricevere un callback di trasferimento audio dall'API CallButtons e stabilire risorse audio nell'endpoint HFP, senza rifiutare o chiudere prematuramente la connessione SCO.