Suporte de áudio para aparelhos auditivos usando Bluetooth LE

Os aparelhos auditivos (HA) podem ter acessibilidade aprimorada em dispositivos móveis com Android usando canais L2CAP orientados à conexão (CoC) sobre Bluetooth Low Energy (BLE). O CoC usa um buffer elástico de vários pacotes de áudio para manter um fluxo constante de áudio, mesmo na presença de perda de pacotes. Esse buffer fornece qualidade de áudio para aparelhos auditivos em detrimento da latência.

O design do CoC faz referência à Especificação Núcleo Bluetooth Versão 5 (BT). Para ficar alinhado com as especificações principais, todos os valores multibyte nesta página devem ser lidos como little-endian.

Terminologia

• Central - o dispositivo Android que procura anúncios por Bluetooth.
• Periférico - o aparelho auditivo que envia pacotes de anúncios por Bluetooth.

Topologia de rede e arquitetura do sistema

Ao utilizar CoC para próteses auditivas, a topologia da rede assume uma única central e duas periféricas, uma esquerda e outra direita, conforme Figura 1 . O sistema de áudio Bluetooth visualiza os periféricos esquerdo e direito como um único coletor de áudio. Se faltar um periférico, por encaixe mono ou perda de conexão, a central mistura o canal de áudio esquerdo e direito e transmite o áudio para o periférico restante. Se a central perder a conexão com os dois periféricos, a central considera perdido o link para o coletor de áudio. Nesses casos, a central encaminha o áudio para outra saída.

Figura 1. Topologia para emparelhar aparelhos auditivos com dispositivos móveis Android usando CoC sobre BLE

Quando a central não estiver transmitindo dados de áudio para o periférico e puder manter uma conexão BLE, a central não deve se desconectar do periférico. Manter a conexão permite a comunicação de dados com o servidor GATT residente no periférico.

Ao emparelhar e conectar aparelhos auditivos, a central deve:

• Acompanhe os periféricos esquerdo e direito emparelhados mais recentemente.
• Suponha que os periféricos estejam em uso se houver um emparelhamento válido. A central deve tentar conectar ou reconectar com o dispositivo emparelhado quando a conexão for perdida.
• Suponha que os periféricos não estejam mais em uso se um emparelhamento for excluído.

Nos casos acima, o emparelhamento refere-se à ação de registrar um conjunto de aparelhos auditivos com um determinado UUID e designadores esquerdo/direito no sistema operacional, não o processo de emparelhamento Bluetooth.

requisitos de sistema

Para implementar corretamente o CoC para uma boa experiência do usuário, os sistemas Bluetooth nos dispositivos centrais e periféricos devem:

• implemente um controlador compatível com BT 4.2 ou superior. LE Secure Connections é altamente recomendado.
• ter o suporte central de pelo menos 2 links LE simultâneos com parâmetros conforme descrito em Formato e temporização do pacote de áudio .
• ter o suporte periférico de pelo menos 1 link LE com os parâmetros descritos em Formato e temporização do pacote de áudio .
• ter um controle de fluxo baseado em crédito LE [BT Vol 3, Parte A, Seção 10.1]. Os dispositivos devem suportar um tamanho de MTU e MPS de pelo menos 167 bytes em CoC e ser capazes de armazenar em buffer até 8 pacotes.
• ter uma extensão de comprimento de dados LE [BT Vol 6, Parte B, Sec 5.1.9] com uma carga útil de pelo menos 167 bytes.
• fazer com que o dispositivo central suporte o comando de atualização de conexão HCI LE e cumpra os parâmetros maximum_CE_Length e minimum_CE_Length diferentes de zero.
• faça com que a central mantenha a taxa de transferência de dados para duas conexões LE CoC para dois periféricos diferentes com os intervalos de conexão e tamanhos de carga útil no formato e temporização do pacote de áudio .
• faça com que o periférico defina os parâmetros MaxRxOctets e MaxRxTime nos quadros LL_LENGTH_REQ ou LL_LENGTH_RSP para serem os menores valores necessários para essas especificações. Isso permite que a central otimize seu agendador de tempo ao calcular a quantidade de tempo necessária para receber um quadro.

É fortemente recomendado que o suporte central e periférico 2MB PHY conforme especificado na especificação BT 5.0. A central deve suportar links de áudio de pelo menos 64 kbit/s em 1M e 2M PHYs. O BLE PHY de longo alcance não deve ser usado.

O CoC usa os mecanismos padrão do Bluetooth para criptografia de camada de link e salto de frequência.

serviços ASHA GATT

Um periférico deve implementar o serviço GATT de Streaming de Áudio para Aparelhos Auditivos (ASHA) descrito abaixo. O periférico deve anunciar este serviço quando estiver no modo detectável geral para permitir que a central reconheça um coletor de áudio. Quaisquer operações de streaming de áudio LE devem exigir criptografia. O streaming de áudio BLE consiste nas seguintes características:

Os UUIDs atribuídos ao serviço e características:

UUID do serviço : {0xFDF0}

Além do serviço ASHA GATT, o periférico também deve implementar o Device Information Service para permitir que a central detecte os nomes dos fabricantes e dos dispositivos do periférico.

ReadOnlyProperties

ReadOnlyProperties tem os seguintes valores:

Recursos do dispositivo

HiSyncID

Este campo deve ser único para todos os dispositivos binaurais, mas deve ser o mesmo para os conjuntos esquerdo e direito.

FeatureMap

códigos de codec

Se o bit estiver definido, esse codec específico é compatível.

AudioControlPoint

Este ponto de controle não pode ser usado quando o LE CoC está fechado. Consulte Iniciar e interromper um fluxo de áudio para obter a descrição do procedimento.

AudioStatusPoint

Campo de relatório de status para o ponto de controle de áudio

Anúncios para o serviço ASHA GATT

O serviço UUID deve estar no pacote de anúncio. Tanto no anúncio quanto no quadro de resposta de varredura, os periféricos devem ter um Service Data:

Os periféricos devem ter um tipo de dados Nome Local Completo que indique o nome do aparelho auditivo. Esse nome será usado na interface do usuário do dispositivo móvel para que o usuário possa selecionar o dispositivo correto. O nome não deve indicar o canal esquerdo ou direito, pois essa informação é fornecida em DeviceCapabilities .

Se os periféricos colocarem o nome e os tipos de dados do serviço ASHA no mesmo tipo de quadro (ADV ou SCAN RESP), os dois tipos de dados ("Nome local completo" e "Dados de serviço para serviço ASHA") devem aparecer no mesmo quadro. Isso permite que o scanner do dispositivo móvel obtenha os dois dados no mesmo resultado da varredura.

Durante o emparelhamento inicial, é importante que os periféricos anunciem a uma taxa rápida o suficiente para permitir que o dispositivo móvel descubra rapidamente os periféricos e se conecte a eles.

Sincronizando dispositivos periféricos esquerdo e direito

Para trabalhar com Bluetooth em dispositivos móveis Android, os dispositivos periféricos são responsáveis ​​por garantir que eles estejam sincronizados. A reprodução nos dispositivos periféricos esquerdo e direito precisa ser sincronizada no tempo. Ambos os dispositivos periféricos devem reproduzir amostras de áudio da fonte ao mesmo tempo.

Os dispositivos periféricos podem sincronizar seu tempo usando um número de sequência anexado a cada pacote da carga útil de áudio. A central garante que os pacotes de áudio que devem ser tocados ao mesmo tempo em cada periférico tenham o mesmo número de sequência. O número de sequência é incrementado em um após cada pacote de áudio. Cada número de sequência tem 8 bits de comprimento, portanto, os números de sequência serão repetidos após 256 pacotes de áudio. Como cada tamanho de pacote de áudio e taxa de amostragem é fixo para cada conexão, os dois periféricos podem deduzir o tempo de reprodução relativo. Para obter mais informações sobre o pacote de áudio, consulte Formato e tempo do pacote de áudio .

A central auxilia fornecendo acionadores para os dispositivos binaurais quando a sincronização pode precisar acontecer. Esses gatilhos informam a cada periférico o status de seu dispositivo periférico emparelhado sempre que houver uma operação que possa afetar a sincronização. Os gatilhos são:

• Como parte do comando «Start» do AudioControlPoint, é fornecido o estado atual da conexão do outro lado dos dispositivos binaurais.
• Sempre que houver uma operação de conexão, desconexão ou atualização dos parâmetros de conexão em um periférico, o comando «Status» do AudioControlPoint é enviado para o outro lado dos dispositivos binaurais.

Formato e tempo do pacote de áudio

O empacotamento de quadros de áudio (blocos de amostras) em pacotes permite que o aparelho auditivo obtenha o tempo das âncoras de tempo da camada de link. Para simplificar a implementação:

• Um quadro de áudio deve sempre corresponder ao intervalo de conexão no tempo. Por exemplo, se o intervalo de conexão for de 20 ms e a taxa de amostragem for de 16 kHz, o quadro de áudio deverá conter 320 amostras.
• As taxas de amostragem no sistema são restritas a múltiplos de 8 kHz para sempre ter um número inteiro de amostras em um quadro, independentemente do tempo do quadro ou do intervalo de conexão.
• Um byte de sequência deve preceder quadros de áudio. O byte de sequência deve contar com wrap-around e permitir que o periférico detecte incompatibilidade de buffer ou subfluxo.
• Um quadro de áudio deve sempre caber em um único pacote LE. O quadro de áudio deve ser enviado como um pacote L2CAP separado. O tamanho do LE LL PDU deve ser:
  tamanho da carga útil de áudio + 1 (contador de sequência) + 6 (4 para cabeçalho L2CAP, 2 para SDU)
• Um evento de conexão sempre deve ser grande o suficiente para conter 2 pacotes de áudio e 2 pacotes vazios para um ACK reservar largura de banda para retransmissões. Observe que o pacote de áudio pode ser fragmentado pelo controlador Bluetooth da central. O periférico deve ser capaz de receber mais de 2 pacotes de áudio fragmentados por evento de conexão.

Para dar à central alguma flexibilidade, o comprimento do pacote G.722 não é especificado. O comprimento do pacote G.722 pode mudar com base no intervalo de conexão que a central define.

O formato de octeto de saída G.722 faz referência ao Rec. ITU-T G.722 (09/2012) seção 1.4.4 "Multiplexador"

Para todos os codecs que um periférico suporta, o periférico deve suportar os parâmetros de conexão abaixo. Esta é uma lista não exaustiva de configurações que a central pode implementar.

Iniciar e interromper um fluxo de áudio

Antes de iniciar um stream de áudio, a central consulta os periféricos e estabelece um codec de denominador comum. A configuração do fluxo segue a seguinte sequência:

1. PSM e, opcionalmente, RenderDelay é lido. Esses valores podem ser armazenados em cache pela central.
2. O canal CoC L2CAP é aberto – o periférico deve conceder 8 créditos inicialmente.
3. Uma atualização de conexão é emitida para alternar o link para os parâmetros necessários para o codec escolhido. A central pode fazer essa atualização de conexão antes da conexão do CoC na etapa anterior.
4. Tanto o host central quanto o periférico aguardam o evento de conclusão da atualização.
5. Reinicie o codificador de áudio e redefina a contagem da sequência do pacote para 0. Um comando «Start» com os parâmetros relevantes é emitido no AudioControlPoint. A central espera por uma notificação de status bem-sucedida do comando anterior «Start» do periférico antes de transmitir. Essa espera dá ao periférico tempo para preparar seu pipeline de reprodução de áudio. Durante o streaming de áudio, a réplica deve estar disponível em todos os eventos de conexão, mesmo que a latência da réplica atual seja diferente de zero.
6. O periférico pega o primeiro pacote de áudio de sua fila interna (sequência número 0) e o reproduz.

A central emite o comando «Stop» para fechar o fluxo de áudio. Após este comando, o periférico não precisa estar disponível a cada evento de conexão. Para reiniciar o streaming de áudio, siga a sequência acima, começando no passo 5. Quando a central não estiver transmitindo áudio, ela ainda deverá manter uma conexão LE para serviços GATT.

O periférico não deve emitir uma atualização de conexão para a central. Para economizar energia, a central pode emitir uma atualização de conexão para o periférico quando não estiver transmitindo áudio.