O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Suporte de áudio para aparelhos auditivos usando Bluetooth LE

Dispositivos de aparelhos auditivos (HA) podem ter acessibilidade aprimorada em dispositivos móveis com Android usando canais L2CAP orientados para 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. Este buffer fornece qualidade de áudio para aparelhos auditivos em detrimento da latência.

O design do CoC faz referência à Bluetooth Core Specification Version 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 verifica se há anúncios por Bluetooth.
  • Periférico - o aparelho auditivo que envia pacotes de anúncios via Bluetooth.

Topologia de rede e arquitetura do sistema

Ao usar o CoC para próteses auditivas, a topologia da rede assume uma única central e dois periféricos, um esquerdo e um direito, conforme mostrado na Figura 1 . O sistema de áudio Bluetooth vê os periféricos esquerdo e direito como um único coletor de áudio. Se um periférico estiver faltando, devido a um ajuste monoaural 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, ela considerará o link para o coletor de áudio perdido. 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 está transmitindo dados de áudio para o periférico e pode 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 direito e esquerdo mais recentes emparelhados.
  • Suponha que os periféricos estejam em uso se houver um emparelhamento válido. A central deve tentar se 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 se refere à 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:

  • implementar um controlador compatível com BT 4.2 ou superior. O 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 tempo de pacote de áudio .
  • fazer com que o periférico suporte pelo menos 1 link LE com os parâmetros descritos em Formato e tempo 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.
  • tem 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.
  • tem o apoio dispositivo central do Connection HCI LE Update Command e cumprir com os não-zero maximum_CE_Length e minimum_CE_Length parâmetros.
  • 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 em formato de pacote de áudio e tempo .
  • tem o conjunto periférica os MaxRxOctets e MaxRxTime parâmetros nos LL_LENGTH_REQ ou LL_LENGTH_RSP frames para ser os menores valores necessários que são necessários para estas especificações. Isso permite que a central otimize seu programador de tempo ao calcular a quantidade de tempo necessária para receber um quadro.

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

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

Serviços ASHA GATT

Um periférico deve implementar o serviço de servidor GATT de transmissão de áudio para aparelhos auditivos (ASHA) descrito abaixo. O periférico deve anunciar este serviço quando em modo detectável geral para permitir que a central reconheça um coletor de áudio. Qualquer operação de streaming de áudio LE deve exigir criptografia. O streaming de áudio BLE consiste nas seguintes características:

Característica Propriedades Descrição
ReadOnlyProperties Ler Consulte ReadOnlyProperties .
AudioControlPoint Escreva e escreva sem resposta Ponto de controle para fluxo de áudio. Consulte AudioControlPoint .
AudioStatusPoint Ler / Notificar Campo de relatório de status para o ponto de controle de áudio. Opcodes são:
  • 0 - Status OK
  • -1 - Comando desconhecido
  • -2 - Parâmetros ilegais
Volume Escreva sem resposta Byte entre -128 e 0 indicando a quantidade de atenuação a ser aplicada ao sinal de áudio transmitido, variando de -48 dB a 0 dB. A configuração -128 deve ser interpretada como totalmente sem áudio, ou seja, o nível de volume mais baixo sem áudio é -127, que é equivalente a -47,625 dB de atenuação. Na configuração 0, um tom senoidal rail-to-rail transmitido deve representar um equivalente de entrada de 100 dBSPL no aparelho auditivo. A central deve transmitir em escala total nominal e usar essa variável para definir o nível de apresentação desejado no periférico.
LE_PSM_OUT Ler PSM a ser usado para conectar o canal de áudio. Para ser escolhido na faixa dinâmica [BT Vol 3, Parte A, Seção 4.22]

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

UUID de serviço : {0xFDF0}

Característica UUID
ReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
AudioStatus {38663f1a-e711-4cac-b641-326b56404837}
Volume {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Além do serviço ASHA GATT, o periférico também deve implementar o Serviço de Informação do Dispositivo para permitir que a central detecte os nomes do fabricante e do dispositivo do periférico.

ReadOnlyProperties

ReadOnlyProperties têm os seguintes valores:

Byte Descrição
0 Versão - deve ser 0x01
1 Consulte DeviceCapabilities .
2-9 Veja HiSyncId .
10 Veja FeatureMap .
11-12 RenderDelay. Este é o tempo, em milissegundos, desde que o periférico recebe um quadro de áudio até o periférico renderizar a saída. Esses bytes podem ser usados ​​para atrasar um vídeo para sincronizar com o áudio.
13-14 Reservado para uso futuro. Inicialize com zeros.
15-16 IDs de codec suportados. Esta é uma máscara de bits de IDs de codec suportados. Um 1 em um local de bit corresponde a um codec compatível. Por exemplo, 0x0002 indica que G.722 a 16 kHz é compatível. Todos os outros bits devem ser definidos como 0.

DeviceCapabilities

Mordeu Descrição
0 Lado do dispositivo (esquerda: 0, direita: 1).
1 Mono (0) / Binaural (1). Indica se o dispositivo é autônomo e recebe dados mono ou se o dispositivo faz parte de um conjunto.
2-7 Reservado (definido como 0).

HiSyncID

Este campo deve ser exclusivo para todos os dispositivos binaurais, mas deve ser o mesmo para o conjunto esquerdo e direito.

Byte Descrição
0-1 ID do fabricante. São os identificadores da empresa atribuídos pelo BTSIG.
2-7 Identificação única que identifica o conjunto de aparelhos auditivos. Este ID deve ser definido para o mesmo no periférico esquerdo e direito.

FeatureMap

Mordeu Descrição
0 Suporte para streaming de saída de áudio LE CoC (Sim / Não).
1-7 Reservado (definido como 0).

IDs de codec

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

ID / número do bit Codec e taxa de amostragem Taxa de bits exigida Tempo de quadro Obrigatório em central (C) ou periférico (P)
0 Reservado Reservado Reservado Reservado
1 G.722 a 16 kHz 64 kbit / s Variável C e P
2-15 são reservados.
0 também é reservado.

AudioControlPoint

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

Código de operação Argumentos Descrição
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Instrui o periférico a redefinir o codec e iniciar a reprodução do quadro 0. O campo codec indica o ID do codec a ser usado para esta reprodução. Por exemplo, o campo do codec é "1" para G.722 a 16k Hz.

O campo de bit de tipo de áudio indica os tipos de áudio presentes no stream:
  • 0 - desconhecido
  • 1 - Toque
  • 2 - Chamada Telefônica
  • 3 - Mídia
O campo otherstate indica se o outro lado dos dispositivos binaurais está conectado. O valor do campo é 1 quando o outro dispositivo periférico está conectado, caso contrário, o valor é 0.

O periférico não deve solicitar atualizações de conexão antes que um opcode «Stop» seja recebido.
2 «Stop» Nenhum Instrui o periférico a parar de renderizar áudio. Uma nova sequência de configuração de áudio deve ser iniciada após esta parada para renderizar o áudio novamente.
3 «Status»
  • uint8_t connected
Informa ao periférico conectado que há uma atualização de status no outro periférico. O campo conectado indica o tipo de atualização:
  • 0 - Outro periférico desconectado
  • 1 - Outro periférico conectado
  • 2 - Uma atualização de parâmetro de conexão LE ocorreu em qualquer conexão

Anúncios para o serviço ASHA GATT

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

Deslocamento de byte Nome Descrição
0 Comprimento AD > = 0x09
1 Tipo de AD 0x16 (Dados de Serviço - UUID de 16 bits)
2-3 UUID de serviço 0xFDF0 (little-endian)

Nota: este é um ID temporário.
4 Versão do protocolo 0x01
5 Capacidade
  • 0 - lado esquerdo (0) ou direito (1)
  • 1 - dispositivos simples (0) ou duplos (1).
  • 2-7 - reservado. Esses bits devem ser zero.
6-9 HiSyncID truncado Quatro bytes menos significativos do HiSyncId . Esses bytes devem ser a parte mais aleatória do ID.

Os periféricos devem ter um tipo de dados Nome local completo que indica o nome do aparelho auditivo. Este nome será usado na interface do usuário do dispositivo móvel para que o usuário possa selecionar o dispositivo certo. O nome não deve indicar o canal esquerdo ou direito, uma vez que esta informação é fornecida em DeviceCapabilities .

Se os periféricos colocarem o nome e os tipos de dados de 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 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 de áudio. A central garante que os pacotes de áudio destinados a serem reproduzidos 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, então 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 são fixos 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 gatilhos para os dispositivos binaurais quando a sincronização pode ser necessária. Esses acionadores 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, o estado atual da conexão do outro lado dos dispositivos binaurais é fornecido.
  • Sempre que houver uma conexão, desconexão ou operação de atualização de parâmetro 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 a temporização das âncoras de temporização 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 20 ms e a taxa de amostragem for 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 de quadro ou do intervalo de conexão.
  • Um byte de sequência deve preceder os quadros de áudio. O byte de sequência deve ser contado com wrap-around e permitir que o periférico detecte incompatibilidade de buffer ou underflow.
  • 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 da PDU LE LL deve ser:
    tamanho de carga de áudio + 1 (contador de sequência) + 6 (4 para cabeçalho L2CAP, 2 para SDU)
  • Um evento de conexão deve ser sempre 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 do 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.

Codec Taxa de bits Intervalo de conexão Comprimento CE (1M / 2M PHY) Tamanho da carga de áudio
G.722 a 16 kHz 64 kbit / s 20 ms 5000/3750 us 160 bytes

Iniciando e interrompendo um stream de áudio

Antes de iniciar um fluxo de áudio, a central consulta os periféricos e estabelece um codec denominador comum. A configuração do stream prossegue com 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 esta atualização de conexão antes da conexão CoC no passo 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 «Start» anterior do periférico antes da transmissão. 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 possa ser diferente de zero.
  6. O periférico pega o primeiro pacote de áudio de sua fila interna (número de sequência 0) e o reproduz.

A central emite o comando «Stop» para fechar o stream de áudio. Após este comando, o periférico não precisa estar disponível em todos os eventos de conexão. Para reiniciar o streaming de áudio, siga a sequência acima, começando a partir do passo 5. Quando a central não está transmitindo áudio, ela ainda deve 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.