Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se describe cómo determina el sistema de audio y controla la información de estado de conexión de un dispositivo de perfil de manos libres (HFP) Bluetooth.
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 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. Estos IOCTL 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 flujo representa la asignación del controlador de audio de ancho de banda inalámbrico. 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 gestionan completamente dentro del controlador HFP. Esto incluye, por ejemplo, desconexiones remotas que pueden deberse a escenarios de llamada en los que hf inicia una transferencia de audio al GRUPO de disponibilidad (con el equipo desempeñando el papel del GRUPO de disponibilidad en este caso).
Estados de pines del filtro de audio
El controlador de audio implementa manejadores de estado de pines KS para dos pines KS. El canal de flujo SCO es necesario para cualquiera de estos pines para transferir datos a través del aire. Cuando cualquiera de estos pines 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 ambos pines 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 utilizar un mecanismo simple de conteo de referencias para seguir el número de pins que requieren el canal de flujo SCO. El controlador de audio abriría y cerraría el canal de transmisión 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 uno está abierto.
Conexión y desconexión remota de SCO
En una desconexión remota de SCO, 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 el temporizador expira, 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 indica un cambio de estado del canal de transmisión al controlador de audio al finalizar 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 esto una condición de error en medio de la transmisión.
Este procedimiento permite que una aplicación VoIP reciba una devolución de llamada de transferencia de audio desde 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 el canal de transmisión está cerrado, el controlador HFP acepta la conexión e inicia un temporizador de desconexión. Cuando expira el temporizador de desconexión, si SCO todavía está 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 para la transferencia de audio desde la API de CallButtons y establezca recursos de audio en el punto de conexión HFP, sin rechazar o cerrar prematuramente la conexión SCO.