A acessibilidade de aparelhos auditivos (HA, na sigla em inglês) pode ser melhorada em dispositivos móveis com Android usando canais L2CAP (CoC) orientados à conexão por Bluetooth de baixa energia (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 oferece qualidade de áudio para dispositivos de aparelho auditivo em detrimento da latência.
O design do CoC faz referência à especificação principal do Bluetooth versão 5 (BT). Para manter o alinhamento com as especificações principais, todos os valores de vários bytes nesta página serão lidos como little-endian.
Terminologia
- Central: o dispositivo Android que faz a verificação de anúncios por Bluetooth.
- Periféricos: o aparelho auditivo que envia pacotes de publicidade por Bluetooth.
Topologia de rede e arquitetura do sistema
Ao usar o CoC para aparelhos auditivos, a topologia de rede assume um único central e dois periféricos, um à esquerda e outro à direita, conforme mostrado na Figura 1. O sistema de áudio Bluetooth considera os periféricos esquerdo e direito como um único destino de áudio. Se um periférico estiver ausente devido a um ajuste monaural ou a uma perda de conexão, a central vai misturar os canais de áudio esquerdo e direito e transmitir o áudio para o periférico restante. Se a central perder a conexão com os dois periféricos, ela vai considerar que a ligação com o sink de áudio foi perdida. Nesses casos, a central encaminha o áudio para outra saída.
Figura 1. Topologia para parear aparelhos auditivos com
dispositivos móveis Android usando CoC por BLE
Quando a central não estiver transmitindo dados de áudio para o periférico e puder manter uma conexão BLE, ela não vai se desconectar do periférico. A manutenção da conexão permite a comunicação de dados para o servidor GATT que reside no periférico.
Ao parear e conectar aparelhos auditivos, a central precisa:
- Acompanhe os periféricos esquerdos e direitos mais recentes pareados.
- Suponha que os periféricos estejam em uso se houver um pareamento válido. A central vai tentar se conectar ou se reconectar com o dispositivo pareado quando a conexão for perdida.
- Suponha que os periféricos não estejam mais em uso se um pareamento for excluído.
Nos casos acima, paring se refere à ação de registrar um conjunto de aparelhos auditivos com um UUID e designadores esquerdo/direito no SO, não ao processo de pareamento do Bluetooth.
Requisitos do sistema
Para implementar corretamente o CoC e garantir uma boa experiência do usuário, os sistemas Bluetooth nos dispositivos centrais e periféricos precisam:
- implementar um controlador BT 4.2 ou mais recente. As conexões seguras do LE são altamente recomendadas.
- ter o suporte central de pelo menos dois links LE simultâneos com parâmetros, conforme descrito em Formato e temporização de pacotes de áudio.
- ter suporte a pelo menos um link LE com os parâmetros descritos em Formato e temporização de pacotes de áudio.
- ter um controle de fluxo baseado em crédito LE [BT Vol 3, Parte A, Sec 10.1]. Os dispositivos precisam oferecer suporte a um tamanho de MTU e MPS de pelo menos 167 bytes no CoC e ser capazes de armazenar até 8 pacotes.
- ter uma extensão de comprimento de dados LE [BT Vol 6, Parte B, Sec 5.1.9] com um payload de pelo menos 167 bytes.
-
O dispositivo central precisa oferecer suporte ao comando de atualização de conexão HCI LE
e obedecer aos parâmetros
maximum_CE_Lengtheminimum_CE_Lengthdiferentes de zero. - a central mantenha a taxa de transferência de dados para duas conexões CoC de LE para dois periféricos diferentes com os intervalos de conexão e os tamanhos de payload no formato e tempo de pacote de áudio.
-
o periférico define os parâmetros
MaxRxOctetseMaxRxTimenos framesLL_LENGTH_REQouLL_LENGTH_RSPcomo os menores valores necessários para essas especificações. Isso permite que o central otimize o agendador de tempo ao calcular a quantidade de tempo necessária para receber um frame.
É altamente recomendável que o central e o periférico ofereçam suporte a PHY de 2 MB, conforme especificado na especificação do BT 5.0. A central precisa oferecer suporte a links de áudio de pelo menos 64 kbit/s em PHYs de 1 M e 2 M. O PHY de longo alcance do BLE 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 GATT da ASHA
Um periférico precisa implementar o serviço de servidor GATT (ASHA) de streaming de áudio descrito abaixo. O periférico precisa anunciar esse serviço quando estiver no modo de descoberta geral para que a central reconheça um sink de áudio. Todas as operações de streaming de áudio LE exigem criptografia. O streaming de áudio BLE consiste nas seguintes características:
| Característica | Propriedades | Descrição |
|---|---|---|
| ReadOnlyProperties | Ler | Consulte Propriedades ReadOnly. |
| AudioControlPoint | Escrita e Escrita sem resposta | Ponto de controle para o stream de áudio. Consulte AudioControlPoint. |
| AudioStatusPoint | Ler/notificar | Campo do relatório de status do ponto de controle de áudio. Consulte AudioStatusPoint. |
| Volume | Gravação sem resposta | Byte entre -128 e 0 que indica a quantidade de atenuação a ser aplicada ao sinal de áudio transmitido por streaming, variando de -48 dB a 0 dB. A configuração -128 será interpretada como totalmente silenciada, ou seja, o nível de volume mais baixo não silenciado é -127, o que equivale a uma atenuação de -47,625 dB. Na configuração 0, um tom senoidal de trilho a trilho transmitido por streaming representa uma entrada equivalente de 100 dBSPL no aparelho auditivo. A central vai transmitir em escala nominal completa 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 no intervalo dinâmico [BT Vol 3, Parte A, Sec 4.22] |
Os UUIDs atribuídos ao serviço e às características:
UUID do 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 precisa implementar o serviço de informações do dispositivo para permitir que a central detecte os nomes do fabricante e do dispositivo do periférico.
ReadOnlyProperties
ReadOnlyProperties tem os seguintes valores:
| Byte | Descrição |
|---|---|
| 0 | Versão: precisa ser 0x01 |
| 1 | Consulte DeviceCapabilities. |
| 2-9 | Consulte HiSyncId. |
| 10 | Consulte FeatureMap. |
| 11-12 | RenderDelay. Esse é o tempo, em milissegundos, entre o momento em que o periférico recebe um frame de áudio até que ele renderize a saída. Esses bytes podem ser usados para atrasar um vídeo para sincronizar com o áudio. |
| 13-14 | Reservado para uso futuro. Inicialização em zeros. |
| 15-16 | IDs de codec compatíveis. Essa é uma máscara de bits de IDs de codec aceitos. Um 1 em um local de bit corresponde a um codec com suporte. Por exemplo, 0x0002 indica que o G.722 a 16 kHz tem suporte. Todos os outros bits serão definidos como 0. |
DeviceCapabilities
| Bit | Descrição |
|---|---|
| 0 | Lado do dispositivo (0: esquerda, 1: direita) |
| 1 | Indica se o dispositivo é independente e recebe dados mono ou se ele faz parte de um conjunto (0: monoaural, 1: binaural) |
| 2 | O dispositivo oferece suporte a CSIS (0: sem suporte, 1: com suporte) |
| 3-7 | Reservado (definido como 0) |
HiSyncID
Esse campo precisa ser único para todos os dispositivos binaurais, mas precisa 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 precisa ser definido como o mesmo nos periféricos esquerdo e direito. |
FeatureMap
| Bit | Descrição |
|---|---|
| 0 | Suporte a streaming de saída de áudio CoC LE (Sim/Não). |
| 1-7 | Reservado (definido como 0). |
IDs de codec
Se o bit estiver definido, o codec terá suporte.
| ID / Número de bits | Codec e taxa de amostragem | Taxa de bits necessária | Tempo para a renderização do frame | Obrigatório em central (C) ou periférico (P) |
|---|---|---|---|---|
| 0 | Reservados | Reservados | Reservados | Reservados |
| 1 | G.722 a 16 kHz | 64 kbit/s | Variável | C e P |
|
2 a 15 são reservados. 0 também é reservado. |
||||
AudioControlPoint
Esse ponto de controle não pode ser usado quando o CoC de LE está fechado. Consulte Como iniciar e interromper um stream de áudio para conferir a descrição do procedimento.
| Código de operação | Argumentos | Subprocedimento GATT | Descrição |
|---|---|---|---|
1 «Start» |
|
Escreva com resposta e espere uma notificação de status adicional pela característica AudioStatusPoint. |
Instrui o periférico a redefinir o codec e iniciar a
reprodução do frame 0. O campo "codec" indica o ID do codec a ser usado
para essa reprodução.
Por exemplo, o campo codec é "1" para G.722 a 16 kHz. O campo de bit de tipo de áudio indica os tipos de áudio presentes no stream:
O periférico não pode solicitar atualizações de conexão antes que um opcode «Stop» seja recebido.
|
2 «Stop» |
Nenhum | Escreva com resposta e espere uma notificação de status adicional pela característica AudioStatusPoint. | Instruções para o periférico parar de renderizar áudio. Uma nova sequência de configuração de áudio precisa ser iniciada após essa parada para renderizar o áudio novamente. |
3 «Status» |
|
Escrever sem resposta |
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:
|
AudioStatusPoint
Campo do relatório de status do ponto de controle de áudio
| Códigos de operação | Descrição |
|---|---|
| 0 | Status OK |
| -1 | Comando desconhecido |
| -2 | Parâmetros ilegais |
Anúncios para o serviço ASHA GATT
O UUID do serviço precisa estar no pacote de publicidade. No anúncio ou no frame de resposta da varredura, os periféricos precisam ter dados de serviço:
| Deslocamento de bytes | Nome | Descrição |
|---|---|---|
| 0 | Duração do anúncio | >= 0x09 |
| 1 | Tipo de anúncio | 0x16 (dados de serviço: UUID de 16 bits) |
| 2 a 3 | UUID do serviço |
0xFDF0 (little-endian) Observação:este é um ID temporário. |
| 4 | Versão do protocolo | 0x01 |
| 5 | Capacidade |
|
| 6-9 | HiSyncID truncado | Quatro bytes mais significativos do HiSyncId. Esses bytes devem ser a parte mais aleatória do ID. |
Os periféricos precisam 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 certo. O nome não indica o canal esquerdo ou direito, já que essas informações são fornecidas em DeviceCapabilities.
Se os periféricos colocarem o nome e os tipos de dados de serviço ASHA no mesmo tipo de frame (ADV ou SCAN RESP), os dois tipos de dados ("Nome local completo" e "Dados de serviço para serviço ASHA") vão aparecer no mesmo frame. Isso permite que o leitor de dispositivos móveis receba os dois dados no mesmo resultado da verificação.
Durante o pareamento inicial, é importante que os periféricos sejam anunciados com rapidez suficiente para que o dispositivo móvel os descubra e se conecte a eles.
Sincronizar dispositivos periféricos esquerdos e direitos
Para trabalhar com Bluetooth em dispositivos móveis Android, os dispositivos periféricos são responsáveis por garantir que eles sejam sincronizados. A reprodução nos dispositivos periféricos esquerdo e direito precisa ser sincronizada no tempo. Os dois dispositivos periféricos precisam reproduzir amostras de áudio da fonte ao mesmo tempo.
Os dispositivos periféricos podem sincronizar o tempo usando um número de sequência adicionado a cada pacote do payload de áudio. A central garante que os pacotes de áudio que precisam ser reproduzidos ao mesmo tempo em cada periférico tenham o mesmo número de sequência. O número de sequência aumenta 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 são repetidos após 256 pacotes de áudio. Como o tamanho do pacote de áudio e a taxa de amostragem são fixos para cada conexão, os dois periféricos podem deduzir o tempo de reprodução relativo. Para mais informações sobre o pacote de áudio, consulte Formato e tempo do pacote de áudio.
A central auxilia fornecendo acionadores aos dispositivos binaurais quando a sincronização precisa acontecer. Esses acionadores informam a cada periférico o status do dispositivo periférico pareado sempre que houver uma operação que possa afetar a sincronização. Os acionadores são:
-
Como parte do comando
«Start»do AudioControlPoint, o estado de conexão atual do outro lado dos dispositivos binaurais é fornecido. -
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 será enviado para o outro lado dos dispositivos binaurais.
Formato e tempo de pacotes de áudio
O empacotamento de frames de áudio (blocos de amostras) em pacotes permite que o instrumento auditivo derive o tempo das ancoras de tempo da camada de link. Para simplificar a implementação:
- Um frame de áudio sempre precisa 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 16 kHz, o frame de áudio vai 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 frame, independentemente do tempo de frame ou do intervalo de conexão.
- Um byte de sequência precisa ser adicionado antes dos frames de áudio. O byte de sequência será contado com o recurso de wrap-around e permitirá que o periférico detecte incompatibilidade ou underflow do buffer.
-
Um frame de áudio sempre se encaixa em um único pacote LE. O frame de áudio
será enviado como um pacote L2CAP separado. O tamanho da PDU
LL LE será:
tamanho do payload de áudio + 1 (contador de sequência) + 6 (4 para o cabeçalho L2CAP, 2 para a SDU) - Um evento de conexão precisa ser grande o suficiente para conter dois pacotes de áudio e dois pacotes vazios para que um ACK reserve a largura de banda para retransmissões. O pacote de áudio pode ser fragmentado pelo controlador de Bluetooth da central. O periférico precisa ser capaz de receber mais de dois pacotes de áudio fragmentados por evento de conexão.
Para dar alguma flexibilidade à central, o comprimento do pacote G.722 não é especificado. O comprimento do pacote G.722 pode mudar com base no intervalo de conexão definido pela central.
O formato de octeto de saída G.722 faz referência à Rec. ITU-T G.722 (09/2012) seção 1.4.4 "Multiplexer"
Para todos os codecs compatíveis com um periférico, ele precisa oferecer suporte aos 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 do payload de áudio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5.000/3.750 us | 160 bytes |
Iniciar e interromper um stream 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 stream prossegue pela seguinte sequência:
- O PSM e, opcionalmente, o RenderDelay são lidos. Esses valores podem ser armazenados em cache pela central.
- O canal CoC L2CAP é aberto. O periférico concede 8 créditos inicialmente.
- Uma atualização de conexão é emitida para alternar a vinculação aos parâmetros necessários para o codec escolhido. A central pode fazer essa atualização antes da conexão CoC na etapa anterior.
- O host central e o periférico aguardam o evento de atualização completo.
-
Reinicie o codificador de áudio e redefina a contagem da sequência de pacotes 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 do streaming. Essa espera dá tempo ao periférico para preparar o pipeline de reprodução de áudio. Durante o streaming de áudio, a réplica precisa estar disponível em todos os eventos de conexão, mesmo que a latência da réplica atual não seja zero. - O periférico pega o primeiro pacote de áudio da fila interna (número de sequência 0) e o reproduz.
A central emite o comando «Stop» para fechar o stream de áudio. Depois desse 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 pela etapa 5. Quando a central não estiver transmitindo áudio, ela ainda precisará manter uma conexão LE para os serviços GATT.
O periférico não pode 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 ele não está transmitindo áudio.