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 explica el proceso cuando un dispositivo Bluetooth con perfil de manos libres (HFP) llega al sistema de audio.
Para cada dispositivo HFP emparejado que llega al sistema de audio, el controlador HFP de Windows registra una interfaz de dispositivo en la clase GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. El controlador de audio usa notificaciones de interfaz de dispositivo para mantenerse informado de todas las instancias de las interfaces de GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. El controlador de audio llama a IoRegisterPlugPlayNotification desde su rutina del controlador AVStrMiniDevicePostStart (o desde una rutina equivalente de Portcls) para registrar un callback que detecte los dispositivos HFP instalados actualmente y reciba notificaciones de nuevos dispositivos HFP.
Cuando el controlador de audio llama a IoRegisterPlugPlayNotification, la llamada se realiza mediante los parámetros siguientes:
- EventCategory se establece en EventCategoryDeviceInterfaceChange.
- EventCategoryFlags suele establecerse en PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES para recibir notificaciones inmediatas de las interfaces existentes. Sin embargo, algunos diseños de controladores de audio alternativos pueden encontrar interfaces existentes a través de otros medios.
- EventCategoryData se establece en GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
- DriverObject se establece en el DriverObject del controlador de audio.
- CallbackRoutine se configura como una rutina en el controlador de audio que recibirá las notificaciones.
En las secciones siguientes se describen las tareas que el controlador de audio puede realizar para cada instancia registrada de un dispositivo HFP emparejado.
Control de instancias de interfaz
Para cada instancia de interfaz registrada en la clase GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, el controlador de audio debe usar el siguiente protocolo para la comunicación:
- Cuando Windows llama a la rutina de devolución de llamada del controlador de audio que fue registrada cuando el controlador de audio llamó a IoRegisterPlugPlayNotification, Windows pasa un vínculo simbólico para la interfaz HFP, usando DEVICE_INTERFACE_CHANGE_NOTIFICATION. SymbolicLinkName.
- Cuando el controlador de audio llama a IoGetDeviceObjectPointer, el controlador usa el vínculo simbólico para obtener el FileObject HFP y el DeviceObject para el dispositivo HFP.
- Cuando el controlador de audio envía IOCTLs al controlador HFP, el controlador usa el objeto FileObject de HFP y deviceObject para el dispositivo HFP.
Recuperación de información estática
El controlador de audio puede recuperar información estática del controlador HFP. Por ejemplo, el controlador HFP puede proporcionar el ksnodetype, el identificador de contenedor y el nombre descriptivo del dispositivo HFP emparejado. El controlador de audio puede usar esta información para crear e inicializar un filtro KS o filtros que representan el dispositivo HFP emparejado. El controlador de audio usa IOCTL_BTHHFP_DEVICE_GET_DESCRIPTOR para obtener esta información.
El controlador de audio también puede recuperar la dirección Bluetooth del dispositivo HFP emparejado. Cada dispositivo HFP emparejado tiene una dirección Bluetooth única, que puede ser útil como una cadena de identificador única. Para obtener más información, consulta Obtener la dirección Bluetooth del dispositivo HF.
Creación e inicialización del contexto de fábrica de filtros específicos de audio
Para crear e inicializar un contexto de fábrica de filtros específico de audio, el controlador de audio debe almacenar el DeviceObject de HFP y el FileObject de HFP en el contexto de fábrica de filtros y, a continuación, inicializar el campo IsConnected en false.
Creación del generador de filtros KS
Para cada instancia de dispositivo de la clase de interfaz GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, el controlador de audio crea y habilita uno o varios generadores de filtros.
Si el controlador de audio es un controlador AVStream, el controlador de audio llama a KsCreateFilterFactory para agregar la nueva fábrica de filtros y a KsFilterFactorySetDeviceClassesState para habilitar la fábrica. Si el controlador de audio es un controlador PortCls, crea y habilita indirectamente generadores de filtros KS llamando a PcRegisterSubdevice. Para muchos diseños de controladores de audio PortCls, hay dos subdispositivos registrados para un dispositivo HFP emparejado determinado.
Cada generador de filtros (o, para los controladores de audio PortCls, cada par de generadores de filtros) representa la funcionalidad de audio de un único dispositivo HFP emparejado. El controlador de audio crea fábricas de filtros separadas para cada dispositivo HFP emparejado, representado por instancias únicas de las interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Para cada dispositivo HFP emparejado, el controlador de audio debe usar cadenas únicas para el parámetro RefString de KsCreateFilterFactory o el parámetro Name de PcRegisterSubdevice. El desarrollador del controlador podría encontrar útil utilizar la cadena de dirección Bluetooth del dispositivo HFP emparejado como una cadena única. Consulta Obtención de la dirección Bluetooth del dispositivo HF para obtener información sobre cómo recuperar la cadena única.
Tenga en cuenta que no hay ningún número máximo específico de dispositivos HFP emparejados posibles, por lo que el controlador de audio debe evitar limitaciones específicas de codificación rígida. En su lugar, el controlador de audio debe gestionar correctamente la llegada dinámica y la remoción de varias interfaces de GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
Sin embargo, como cuestión práctica, un controlador PortCls debe especificar un número máximo de subdispositivos cuando llama a PcAddAdapterDevice. PcAddAdapterDevice asigna previamente memoria adicional para cada subdispositivo potencial. El desarrollador del controlador de audio debe seleccionar un número lo suficientemente alto como para dar cabida a muchos dispositivos emparejados, pero al mismo tiempo seleccionar un número que no da lugar a un desperdicio de recursos. Por ejemplo, admitir solo dos dispositivos HFP podría ser inadecuado, y admitir dos mil sin duda daría lugar a recursos sobreextendidos. Sin embargo, es probable que el apoyo a dieciséis sea razonable.
Si, en tiempo de ejecución, el controlador de audio recibe una notificación de otra interfaz de GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, pero ya ha registrado su número máximo de subdispositivos, el controlador de audio puede invocar algún algoritmo para seleccionar un dispositivo HFP emparejado cuyos subdispositivos pueda anular el registro para hacer espacio para el nuevo dispositivo HFP. Por ejemplo, el controlador de audio podría realizar un seguimiento del dispositivo HFP con la conexión más antigua. Mientras que un controlador de audio más sencillo, pero quizás menos fácil de usar, podría simplemente ignorar una interfaz adicional de tipo GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS después de alcanzar su capacidad máxima.
Envío del IOCTL para obtener el estado de conexión
El controlador de audio envía el IOCTL de estado de conexión get para obtener información sobre los cambios que se han producido en la conexión.
Envío del IOCTL de estado de obtención del volumen
El controlador de audio envía el IOCTL para obtener el estado del volumen y así obtener información sobre los cambios en el nivel de volumen que se han producido en el estado del volumen de los auriculares.