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 discute como o sistema de áudio determina e lida com informações de status de conexão para um dispositivo HFP (perfil mãos-livres Bluetooth).
O driver de áudio deve dar suporte a KSPROPERTY_JACK_DESCRIPTION e manter um campo IsConnected no contexto da fábrica de filtros. O driver usa esse valor ao manipular a propriedade KSPROPERTY_JACK_DESCRIPTION .
Quando IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE é concluído com êxito, o driver de áudio atualiza IsConnected com o novo status de conexão. Se o status tiver sido alterado, o driver de áudio gerará o evento KSEVENT_PINCAPS_JACKINFOCHANGE , fazendo com que o sistema de áudio reavaliasse o estado da conexão. Em seguida, o driver de áudio chama outra instância de IOCTL_BTHHFP_DEVICE_GET_CONNECTION_STATUS_UPDATE para receber a próxima alteração de status. Se uma solicitação de alteração de status anterior ainda estiver pendente, essa segunda chamada falhará e o driver de áudio não atualizará seu status de conexão e não fará outra solicitação de informações de alteração de status.
Conforme discutido nas considerações de streaming do Kernel, o driver de áudio deve suportar KSPROPERTY_ONESHOT_RECONNECT e KSPROPERTY_ONESHOT_DISCONNECT. Os responsáveis por essas propriedades devem enviar os IOCTLs REQUESTCONNECT e REQUESTDISCONNECT, respectivamente, para o driver HFP. Essas IOCTLs são concluídas rapidamente e o driver de áudio precisa estar pronto para responder aos resultados retornados.
Este artigo também aborda outros fatores relacionados à conexão do dispositivo de áudio Bluetooth que o desenvolvedor do driver de áudio deve estar ciente.
Canal de fluxo
O canal de transmissão representa a alocação de largura de banda aérea do driver de áudio. Na maioria das vezes, este é o canal SCO. No entanto, alguns dos detalhes do gerenciamento do status do canal SCO são tratados inteiramente dentro do driver HFP. Isso inclui, por exemplo, desconexões remotas que podem ocorrer devido a cenários de chamada em que o HF inicia uma transferência de áudio para o AG (com o computador desempenhando a função do AG nesse caso).
Estados dos pinos do filtro de áudio
O driver de áudio implementa manipuladores de estado de pino KS para dois pinos KS. O canal de fluxo SCO é necessário para que qualquer um desses pinos transfira dados pelo ar. Quando qualquer um desses pinos faz a transição para KSSTATE_ACQUIRE, o driver de áudio abre o canal enviando IOCTL_BTHHFP_STREAM_OPEN para o driver HFP. Essa chamada assíncrona pode levar vários segundos para ser concluída. O driver de áudio não precisa implementar seu próprio mecanismo de tempo limite e deve aguardar a conclusão do IOCTL antes de concluir a transição para KSSTATE_ACQUIRE.
Quando ambos os pinos KS fazem a transição para KSSTATE_STOP, o driver de áudio envia IOCTL_BTHHFP_STREAM_CLOSE ao driver HFP, e isso é concluído rapidamente.
Para determinar quando enviar IOCTL_BTHHFP_STREAM_OPEN e IOCTL_BTHHFP_STREAM_CLOSE, o driver de áudio pode usar um mecanismo de contagem de referência simples para acompanhar o número de pinos que exigem o canal de fluxo SCO. O driver de áudio abriria e fecharia o canal de fluxo SCO quando a contagem de referência mudasse de 0 para 1.
Em IOCTL_BTHHFP_STREAM_OPEN, o driver HFP solicita um canal SCO, se ainda não estiver aberto, e conclui a solicitação com os resultados da solicitação SCO. Em IOCTL_BTHHFP_STREAM_CLOSE, o driver HFP solicitará uma desconexão do canal SCO, se estiver aberto.
Conexão e desconexão remotas do SCO
Em uma desconexão remota do SCO, se o canal de fluxo estiver fechado, o driver HFP não fará nada. Se o canal de fluxo for aberto, o driver HFP iniciará um temporizador de reconexão. Quando o temporizador expira, se o SCO ainda estiver desconectado e o canal de fluxo ainda estiver aberto, o driver solicitará um canal SCO. Observe que nenhum dado de áudio é transferido pelo ar enquanto o SCO está desconectado, portanto, haverá uma lacuna no áudio durante esse período. Se a solicitação SCO falhar, o driver HFP sinaliza uma alteração de status do canal de fluxo para o driver de áudio ao concluir qualquer invocação de IOCTL_BTHHFP_STREAM_GET_STATUS_UPDATE. Isso deve ser raro, pois a desconexão remota do SCO normalmente está associada ao dispositivo HF que solicita a transferência de áudio de chamada para o gateway de áudio. O driver de áudio deve considerar essa uma condição de erro no meio do fluxo.
Esse procedimento permite que um aplicativo VoIP tenha tempo para receber um retorno de chamada de transferência de áudio da API CallButtons e liberar seus recursos de áudio de maneira clara e precisa no ponto de extremidade HFP, evitando, assim, erros de streaming.
Em uma conexão SCO remota, se o canal de fluxo estiver aberto, o driver simplesmente aceitará a conexão. Se o canal de fluxo estiver fechado, o driver HFP aceitará a conexão e iniciará um temporizador de desconexão. Quando o temporizador de desconexão expira, se o SCO ainda estiver conectado e o canal de fluxo ainda estiver fechado, o driver interromperá a conexão SCO.
Este procedimento permite tempo para um aplicativo de VoIP receber um retorno de chamada de transferência de áudio da API CallButtons e estabelecer os recursos de áudio necessários no ponto de extremidade HFP, sem rejeitar ou fechar a conexão SCO prematuramente.