Inicialização do dispositivo HFP
Este artigo explica o processo quando um dispositivo hfp (perfil mãos livres) Bluetooth chega ao sistema de áudio.
Para cada dispositivo HFP emparelhado que chega ao sistema de áudio, o driver HFP do Windows registra uma interface de dispositivo na classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. O driver de áudio usa notificações de interface do dispositivo para se manter informado sobre todas as instâncias das interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. O driver de áudio chama IoRegisterPlugPlayNotification de dentro de sua rotina de driver AVStrMiniDevicePostStart (ou de uma rotina portcls equivalente) para registrar um retorno de chamada para descobrir os dispositivos HFP atualmente instalados e ser notificado sobre novos dispositivos HFP.
Quando o driver de áudio chama IoRegisterPlugPlayNotification, a chamada é feita usando os seguintes parâmetros:
- EventCategory é definido como EventCategoryDeviceInterfaceChange.
- EventCategoryFlags normalmente é definido como PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES para receber notificações imediatas de interfaces existentes. No entanto, alguns designs alternativos de driver de áudio podem encontrar interfaces existentes por outros meios.
- EventCategoryData é definido como GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
- DriverObject é definido como DriverObject do driver de áudio.
- CallbackRoutine é definido como uma rotina no driver de áudio que receberá as notificações.
As seções a seguir descrevem as tarefas que o driver de áudio pode executar para cada instância registrada de um dispositivo HFP emparelhado.
Manipulando instâncias de interface
Para cada instância de interface registrada na classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, o driver de áudio deve usar o seguinte protocolo para comunicação:
- Quando o Windows chama a rotina de retorno de chamada do driver de áudio registrada quando o driver de áudio chamado IoRegisterPlugPlayNotification, o Windows passa um link simbólico para a interface HFP, usando DEVICE_INTERFACE_CHANGE_NOTIFICATION. SymbolicLinkName.
- Quando o driver de áudio chama IoGetDeviceObjectPointer, o driver usa o link simbólico para obter o FileObject hfp e o DeviceObject para o dispositivo HFP.
- Quando o driver de áudio envia IOCTLs para o driver HFP, o driver usa o FileObject hfp e o DeviceObject para o dispositivo HFP.
Recuperando informações estáticas
O driver de áudio pode recuperar informações estáticas do driver HFP. Por exemplo, o driver HFP pode fornecer o ksnodetype, a ID do contêiner e o nome amigável do dispositivo HFP emparelhado. O driver de áudio pode usar essas informações para criar e inicializar um filtro KS ou filtros que representam o dispositivo HFP emparelhado. O driver de áudio usa IOCTL_BTHHFP_DEVICE_GET_DESCRIPTOR para obter essas informações.
O driver de áudio também pode recuperar o endereço Bluetooth do dispositivo HFP emparelhado. Cada dispositivo HFP emparelhado tem um endereço Bluetooth exclusivo, que pode ser útil como uma cadeia de caracteres de identificador exclusiva. Para obter mais informações, consulte Obtendo o endereço Bluetooth do dispositivo HF.
Criando, inicializando o contexto de fábrica de filtros específico de áudio
Para criar e inicializar um contexto de fábrica de filtros específico de áudio, o driver de áudio deve armazenar o DeviceObject hfp e o FileObject HFP no contexto de fábrica de filtros e, em seguida, inicializar o campo IsConnected como false.
Criando a fábrica de filtros KS
Para cada instância de dispositivo na classe de interface GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, o driver de áudio cria e habilita uma ou mais fábricas de filtros.
Se o driver de áudio for um driver AVStream, o driver de áudio chamará KsCreateFilterFactory para adicionar a nova fábrica de filtros e KsFilterFactorySetDeviceClassesState para habilitar a fábrica. Se o driver de áudio for um driver PortCls, ele criará e habilitará indiretamente fábricas de filtro KS chamando PcRegisterSubdevice. Para muitos designs de driver de áudio PortCls, há dois sub-dispositivos registrados para um determinado dispositivo HFP emparelhado.
Cada fábrica de filtros (ou, para drivers de áudio PortCls, cada par de fábricas de filtros) representa a funcionalidade de áudio de um único dispositivo HFP emparelhado. O driver de áudio cria fábricas de filtro separadas para cada dispositivo HFP emparelhado representado por instâncias exclusivas de interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. Para cada dispositivo HFP emparelhado, o driver de áudio deve usar cadeias de caracteres exclusivas para o parâmetro RefString de KsCreateFilterFactory ou o parâmetro Name de PcRegisterSubdevice. O desenvolvedor do driver pode achar útil usar a cadeia de caracteres de endereço Bluetooth do dispositivo HFP emparelhada como uma cadeia de caracteres exclusiva. Consulte Obtendo o endereço Bluetooth do dispositivo HF para obter informações sobre como recuperar a cadeia de caracteres exclusiva.
Observe que não há um número máximo específico de possíveis dispositivos HFP emparelhados, portanto, o driver de áudio deve evitar limitações específicas de codificação rígida. Em vez disso, o driver de áudio deve lidar corretamente com a chegada dinâmica e a remoção de várias interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
No entanto, como uma questão prática, um driver PortCls deve especificar um número máximo de sub-dispositivos ao chamar PcAddAdapterDevice. PcAddAdapterDevice pré-aloca memória extra para cada sub-dispositivo em potencial. O desenvolvedor do driver de áudio deve selecionar um número alto o suficiente para acomodar muitos dispositivos emparelhados, mas, ao mesmo tempo, selecionar um número que não resulte em um desperdício de recursos. Por exemplo, dar suporte a apenas dois dispositivos HFP pode ser inadequado e dar suporte a dois mil certamente resultaria em recursos superexpostos. No entanto, é provável que apoiar dezesseis seja razoável.
Se, em runtime, o driver de áudio for notificado de outra interface GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS, mas já tiver registrado seu número máximo de sub-dispositivos, o driver de áudio poderá invocar algum algoritmo para escolher um dispositivo HFP emparelhado cujos sub-dispositivos ele pode cancelar o registro para abrir espaço para o novo dispositivo HFP. Por exemplo, o driver de áudio pode acompanhar o dispositivo HFP com a conexão mais antiga. Enquanto um driver de áudio mais simples, mas talvez menos amigável, poderia simplesmente ignorar a interface de GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS adicional depois de atingir seu máximo.
Enviando a conexão get status IOCTL
O driver de áudio envia a conexão get status IOCTL para obter informações sobre as alterações que ocorreram na conexão.
Enviando o volume get status IOCTL
O driver de áudio envia o volume get status IOCTL para obter informações sobre quaisquer alterações no nível de volume que ocorreram no volume status do headset.