Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo explica o processo quando um dispositivo HFP (perfil mãos livres Bluetooth) se conecta ao sistema de áudio.
Para cada dispositivo HFP emparelhado que chega ao sistema de áudio, o driver HFP do Windows registra uma interface do dispositivo na classe GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. O driver de áudio utiliza notificações de interface de dispositivo para se manter informado sobre todas as instâncias das interfaces GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS. O driver de áudio chama a função IoRegisterPlugPlayNotification de dentro de sua rotina AVStrMiniDevicePostStart (ou de uma rotina equivalente em Portcls) para registrar um callback que descobre os dispositivos HFP atualmente instalados e ser notificado de novos dispositivos HFP.
Quando o driver de áudio chama IoRegisterPlugPlayNotification, a chamada é feita usando os seguintes parâmetros:
- EventCategory está definido como EventCategoryDeviceInterfaceChange.
- Em geral, o EventCategoryFlags é configurado como PNPNOTIFY_DEVICE_INTERFACE_INCLUDE_EXISTING_INTERFACES para receber notificações imediatas de interfaces existentes. No entanto, alguns designs alternativos do driver de áudio podem encontrar interfaces existentes por meio de outros meios.
- EventCategoryData está definido como GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS.
- DriverObject é definido como o 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 Windows chama a função de retorno registrada pelo driver de áudio ao chamar IoRegisterPlugPlayNotification, ele 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 HFP FileObject e o DeviceObject para o dispositivo HFP.
- Quando o driver de áudio envia IOCTLs para o driver HFP, o driver usa o HFP FileObject 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 Como obter o endereço Bluetooth do dispositivo HF.
Criando, inicializando o contexto de fábrica de filtros específico para á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 HFP FileObject no contexto da 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 ativar a fábrica de filtros. Se o driver de áudio for um driver PortCls, ele criará e habilitará indiretamente fábricas de filtros KS ao chamar 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 filtros de fábrica separados para cada dispositivo HFP emparelhado, representado por instâncias únicas de interfaces de 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 emparelhado como uma sequência exclusiva. Consulte Como obter 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. 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.
Por uma questão prática, no entanto, um driver PortCls deve especificar um número máximo de sub-dispositivos quando chama 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 sobrecarregados. No entanto, é provável que o suporte a dezesseis seja razoável.
Se, em runtime, o driver de áudio for notificado de outro GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS interface, 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 controlar o dispositivo HFP com a conexão mais antiga. Um driver de áudio mais simples, mas possivelmente menos intuitivo, poderia simplesmente ignorar a interface adicional de GUID_DEVINTERFACE_BLUETOOTH_HFP_SCO_HCIBYPASS após ter atingido seu limite máximo.
Enviando o status da conexão get IOCTL
O driver de áudio envia a IOCTL 'get connection status' para obter informações sobre quaisquer alterações que tenham ocorrido na conexão.
Enviando o comando IOCTL para obter status do volume
O driver de áudio envia o status de obtenção de volume IOCTL para obter informações sobre quaisquer alterações no nível de volume que ocorreram no status do volume do headset.