Compartilhar via

Conexão de dispositivo HFP

  • Artigo

Este artigo discute como o sistema de áudio determina e lida com informações de conexão status para um dispositivo HFP (perfil sem mãos bluetooth).

O driver de áudio deve dar suporte a KSPROPERTY_JACK_DESCRIPTION e manter um campo IsConnected no contexto de 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 a nova status de conexão. Se o status tiver sido alterado, o driver de áudio aciona o evento KSEVENT_PINCAPS_JACKINFOCHANGE, fazendo com que o sistema de áudio reavalie 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 status. Se uma solicitação de alteração status anterior ainda estiver pendente, essa segunda chamada falhará e o driver de áudio não atualizará sua status de conexão e não fará outra solicitação para status informações de alteração.

Conforme discutido nas considerações de streaming do Kernel, o driver de áudio deve dar suporte a KSPROPERTY_ONESHOT_RECONNECT e KSPROPERTY_ONESHOT_DISCONNECT. Os manipuladores dessas propriedades devem enviar 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 de dispositivo de áudio Bluetooth dos quais o desenvolvedor do driver de áudio deve estar ciente.

Canal de fluxo

O canal de fluxo representa a alocação de largura de banda over-the-air do driver de áudio. Na maioria das vezes, este é o canal SCO. No entanto, alguns dos detalhes do gerenciamento do canal SCO status são tratados inteiramente dentro do driver HFP. Isso inclui, por exemplo, desconexões remotas que podem ser 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 de fixação de 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 para o driver HFP, que é 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 houver uma aberta.

Conexão e desconexão do SCO remoto

Em uma desconexão SCO remota, 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 sinalizará um canal de fluxo status mudar para o driver de áudio concluindo qualquer invocação 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 receba um retorno de chamada de transferência de áudio da API CallButtons e libere corretamente seus recursos de áudio no ponto de extremidade HFP, em vez de causar 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.

Esse procedimento permite tempo para um aplicativo VoIP receber um retorno de chamada de transferência de áudio da API CallButtons e estabelecer recursos de áudio no ponto de extremidade HFP, sem rejeitar ou fechar prematuramente a conexão SCO.