O Google está comprometido em promover a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Suporte de áudio para aparelhos auditivos usando Bluetooth LE

Os dispositivos de aparelho auditivo (HA) podem ter melhor acessibilidade em dispositivos móveis com Android, usando canais L2CAP (CoC) orientados a conexão por 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 à custa da latência.

O design do CoC faz referência à Bluetooth Core Specification Versão 5 (BT). Para permanecer alinhado com as especificações principais, todos os valores de vários bytes 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 usar o CoC para aparelhos auditivos, a topologia de rede assume uma única central e dois periféricos, um esquerdo e um direito, como mostra a 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 ausente, devido a um ajuste 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 considerará o link para o coletor de áudio perdido. Nesses casos, a central direciona 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 que reside no periférico.

Ao emparelhar e conectar aparelhos auditivos, a central deve:

  • Acompanhe os periféricos esquerdo e direito mais recentes emparelhados.
  • Suponha que os periféricos estejam em uso se existir um emparelhamento válido. A central deve tentar conectar-se ou reconectar-se ao 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 de esquerda / direita no sistema operacional, não o processo de emparelhamento Bluetooth.

requisitos de sistema

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

  • implemente um controlador BT 4.2 ou superior compatível. O LE Secure Connections é altamente recomendado.
  • tenha o suporte central de pelo menos 2 links LE simultâneos com parâmetros, conforme descrito no formato e tempo do pacote de áudio .
  • tenha o suporte periférico de 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 de 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 no CoC e poder armazenar buffer em até 8 pacotes.
  • ter uma extensão de comprimento de dados LE [BT Vol 6, Parte B, Seção 5.1.9] com uma carga útil de pelo menos 167 bytes.
  • tem o apoio dispositivo central do Connection HCI LE Atualização de comando e cumprir com os diferentes de 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 em dois periféricos diferentes, com os intervalos de conexão e os tamanhos de carga útil no formato e tempo do pacote de áudio .
  • tem o conjunto periférica os MaxRxOctets e MaxRxTime parâmetros nos LL_LENGTH_REQ ou LL_LENGTH_RSP quadros a ser os menores valores necessários que são necessários para estas especificações. Isso permite que a central otimize seu agendador de tempo ao calcular a quantidade de tempo necessária para receber um quadro.

É altamente recomendável 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 nos PHYs de 1M e 2M. O PHY de longo alcance BLE não deve ser utilizado.

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

Serviços ASHA GATT

Um periférico deve implementar o serviço do servidor GATT de Streaming de Áudio para Aparelhos Auditivos (ASHA) descrito abaixo. O periférico deve anunciar esse serviço quando no modo detectável geral, para permitir que a central reconheça um coletor de áudio. Qualquer operação de streaming de áudio LE requer criptografia. O streaming de áudio BLE consiste nas seguintes características:

Característica Propriedades Descrição
ReadOnlyProperties Ler Consulte ReadOnlyProperties .
AudioControlPoint Escrever e escrever 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 desativada, ou seja, o nível mais baixo de volume não desativado é -127, o que equivale a atenuação de -47,625 dB. Na configuração 0, um tom senoidal trilho a trilho transmitido deve representar uma entrada de 100 dBSPL equivalente no aparelho auditivo. A central deve transmitir em escala nominal 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 selecionado no intervalo dinâmico [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ções do Dispositivo para permitir que a central detecte os nomes dos fabricantes e os nomes dos dispositivos do periférico.

ReadOnlyProperties

ReadOnlyProperties possui os seguintes valores:

Byte Descrição
0 0 Versão - deve ser 0x01
1 Consulte DeviceCapabilities .
2-9 Veja HiSyncId .
10 Veja o FeatureMap .
11-12 RenderDelay. Este é o tempo, em milissegundos, desde o momento em 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 em zeros.
15-16 IDs de codec suportados. Esta é uma máscara de bit de IDs de codec suportados. Um 1 em um local de bit corresponde a um codec suportado. Por exemplo, 0x0002 indica que G.722 a 16 kHz é suportado. Todos os outros bits devem ser definidos como 0.

DeviceCapabilities

Mordeu Descrição
0 0 Lado do dispositivo (Esquerda: 0, Direita: 1).
1 Monoaural (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 ID exclusivo que identifica o conjunto de aparelhos auditivos. Esse ID deve ser definido da mesma forma no periférico esquerdo e no direito.

FeatureMap

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

IDs de codec

Se o bit estiver definido, esse codec específico será suportado.

ID / número de bit Codec e taxa de amostragem Taxa de bits necessária Tempo de quadro Obrigatório na central (C) ou periférica (P)
0 0 Reservado Reservado Reservado Reservado
1 G.722 @ 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 parando um fluxo de áudio para obter 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 em 16k Hz.

O campo de bit do tipo de áudio indica o (s) tipo (s) de áudio presentes no fluxo:
  • 0 - Desconhecido
  • 1 - Toque
  • 2 - Chamada telefônica
  • 3 - Mídia
O campo othertate 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 código de operação «Stop» seja recebido.
2 «Stop» Nenhum Instrui o periférico a parar de renderizar o á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 o 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 - Ocorreu uma atualização do parâmetro de conexão LE em qualquer conexão

Anúncios do serviço ASHA GATT

O UUID de serviço deve estar no pacote de anúncio. No quadro de resposta do anúncio ou da varredura, os periféricos devem ter um dado de serviço:

Deslocamento de bytes Nome Descrição
0 0 Comprimento do ANÚNCIO > = 0x09
1 Tipo de anúncio 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 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 essas informações são fornecidas no 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") aparecerão no mesmo quadro. Isso permite que o scanner do dispositivo móvel obtenha os dois dados no mesmo resultado da digitalização.

Durante o emparelhamento inicial, é importante que os periféricos façam propaganda a uma velocidade rápida o suficiente para permitir que o dispositivo móvel descubra rapidamente os periféricos e se ligue 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 a sincronização. A reprodução nos dispositivos periféricos esquerdo e direito precisa ser sincronizada a 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 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 e, 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 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 precisar acontecer. Esses gatilhos informam cada periférico do status do 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 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

A inserção 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 sempre deve corresponder ao intervalo de conexão no tempo. Por exemplo, se o intervalo de conexão for 20ms 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 8kHz 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 os quadros de áudio. O byte de sequência deve ser contado com wrap-around e permitir que o periférico detecte incompatibilidade ou subfluxo do buffer.
  • 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 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 que um ACK reserve largura de banda para retransmissões. Observe que o pacote de áudio pode estar fragmentado pelo controlador Bluetooth da central. O periférico deve poder receber mais de 2 pacotes de áudio fragmentados por evento de conexão.

Para dar à central alguma flexibilidade, o tamanho do pacote G.722 não é especificado. O tamanho 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 do CE (1M / 2M PHY) Tamanho da carga útil do áudio
G.722 @ 16 kHz 64 kbit / s 20 ms 5000/3750 nós 160 bytes

Iniciando e Parando um Fluxo de Áudio

Antes de iniciar um fluxo de áudio, a central consulta os periféricos e estabelece um codec de denominador comum. A configuração do fluxo continua 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 essa atualização de conexão antes da conexão CoC na etapa anterior.
  4. O host central e o periférico aguardam o evento de conclusão da atualização.
  5. Reinicie o codificador de áudio e redefina a contagem de sequência de pacotes para 0. Um comando «Start» com os parâmetros relevantes é emitido no AudioControlPoint. A central aguarda uma notificação de status bem-sucedida do comando anterior «Start» do periférico antes de transmitir. Essa espera fornece tempo periférico para preparar seu pipeline de reprodução de áudio. Durante a transmissão de áudio, a réplica deve estar disponível em todos os eventos de conexão, mesmo que a latência atual da réplica 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 fluxo de áudio. Após esse comando, o periférico não precisa estar disponível em todos os eventos de conexão. Para reiniciar a transmissão de áudio, siga a sequência acima, iniciando na etapa 5. Quando a central não estiver transmitindo áudio, ela ainda deverá manter uma conexão LE para os serviços do GATT.

O periférico não deve emitir uma atualização de conexão com 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.