Conexión de dispositivos HFP
En este artículo se describe cómo el sistema de audio determina y controla la información de estado de conexión de un dispositivo bluetooth de perfil manos libres (HFP).
El controlador de audio debe admitir KSPROPERTY_JACK_DESCRIPTION y mantener un campo IsConnected en el contexto del generador de filtros. El controlador usa este valor al controlar la propiedad KSPROPERTY_JACK_DESCRIPTION .
Cuando IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE se completa correctamente, el controlador de audio actualiza IsConnected con el nuevo estado de conexión. Si el estado ha cambiado, el controlador de audio genera el evento de KSEVENT_PINCAPS_JACKINFOCHANGE , lo que hace que el sistema de audio vuelva a evaluar el estado de conexión. A continuación, el controlador de audio llama a otra instancia de IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE para recibir el siguiente cambio de estado. Si una solicitud de cambio de estado anterior sigue pendiente, se produce un error en esta segunda llamada y el controlador de audio no actualiza su estado de conexión y no realiza otra solicitud de información de cambio de estado.
Como se describe en Consideraciones de streaming de kernel, el controlador de audio debe admitir KSPROPERTY_ONESHOT_RECONNECT y KSPROPERTY_ONESHOT_DISCONNECT. Los controladores de estas propiedades deben enviar IOCTLs REQUESTCONNECT y REQUESTDISCONNECT, respectivamente, al controlador HFP. Estas ICTL se completan rápidamente y el controlador de audio debe estar listo para responder a los resultados devueltos.
En este artículo también se tratan otros factores relacionados con la conexión del dispositivo de audio Bluetooth que el desarrollador del controlador de audio debe tener en cuenta.
Canal de transmisión
El canal de transmisión representa la asignación del controlador de audio de ancho de banda por vía inalámbrica. En su mayor parte, este es el canal SCO. Sin embargo, algunos de los detalles de la administración del estado del canal SCO se controlan completamente dentro del controlador HFP. Esto incluye, por ejemplo, desconexiones remotas que pueden deberse a escenarios de llamada en los que el HF inicia una transferencia de audio al GRUPO de disponibilidad (con el equipo desempeñando el rol del AG en este caso).
Estados de patillas de filtro de audio
El controlador de audio implementa controladores de estado de patilla KS para dos patillas KS. El canal de transmisión sco es necesario para que cualquiera de estos pines transfiera datos por aire. Cuando cualquiera de estas patillas pasa a KSSTATE_ACQUIRE, el controlador de audio abre el canal enviando IOCTL_BTHHFP_STREAM_OPEN al controlador HFP. Esta llamada asincrónica puede tardar varios segundos en completarse. El controlador de audio no necesita implementar su propio mecanismo de tiempo de espera y debe esperar a que se complete el IOCTL antes de completar la transición a KSSTATE_ACQUIRE.
Cuando ambas patillas KS pasan a KSSTATE_STOP, el controlador de audio envía IOCTL_BTHHFP_STREAM_CLOSE al controlador HFP, que se completa rápidamente.
Para determinar cuándo enviar IOCTL_BTHHFP_STREAM_OPEN y IOCTL_BTHHFP_STREAM_CLOSE, el controlador de audio puede usar un mecanismo de recuento de referencias simple para realizar un seguimiento del número de patillas que requieren el canal de transmisión sco. El controlador de audio abriría y cerraría el canal de secuencia sco cuando el recuento de referencias cambia de 0 a 1.
En IOCTL_BTHHFP_STREAM_OPEN, el controlador HFP solicita un canal SCO, si aún no está abierto y completa la solicitud con los resultados de la solicitud SCO. En IOCTL_BTHHFP_STREAM_CLOSE, el controlador HFP solicita una desconexión del canal SCO, si hay una abierta.
Conexión y desconexión remota de SCO
En una desconexión sco remota, si el canal de transmisión está cerrado, el controlador HFP no hace nada. Si se abre el canal de transmisión, el controlador HFP inicia un temporizador de reconexión. Cuando expira el temporizador, si SCO sigue desconectado y el canal de transmisión sigue abierto, el controlador solicita un canal SCO. Tenga en cuenta que no se transfieren datos de audio por aire mientras sco está desconectado, por lo que habrá una brecha en el audio durante este período. Si se produce un error en la solicitud SCO, el controlador HFP señala un cambio de estado del canal de transmisión al controlador de audio completando cualquier invocación de IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE. Esto debería ser poco frecuente, ya que la desconexión remota de SCO normalmente está asociada con el dispositivo HF que solicita la transferencia de audio de llamada a la puerta de enlace de audio. El controlador de audio debe considerar esta condición de error de secuencia media.
Este procedimiento permite que una aplicación VoIP reciba una devolución de llamada de transferencia de audio de la API CallButtons y libere limpiamente sus recursos de audio en el punto de conexión de HFP, en lugar de provocar errores de streaming.
En una conexión SCO remota, si el canal de transmisión está abierto, el controlador simplemente acepta la conexión. Si se cierra el canal de transmisión, el controlador HFP acepta la conexión e inicia un temporizador de desconexión. Cuando expira el temporizador de desconexión, si SCO sigue conectado y el canal de transmisión sigue cerrado, el controlador interrumpe la conexión SCO.
Este procedimiento permite que una aplicación VoIP reciba una devolución de llamada de transferencia de audio de la API CallButtons y establezca recursos de audio en el punto de conexión HFP, sin rechazar o cerrar prematuramente la conexión SCO.