Dispositivos de aparelhos auditivos (HA) podem ter acessibilidade aprimorada em dispositivos móveis com Android usando canais L2CAP (CoC) orientados à conexão 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 à Bluetooth Core Specification 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 propaganda por Bluetooth.
Topologia de rede e arquitetura do sistema
Ao utilizar CoC para próteses auditivas, a topologia de rede assume uma única central e dois periféricos, um esquerdo e outro direito, conforme Figura 1 . O sistema de áudio Bluetooth visualiza os periféricos esquerdo e direito como um único coletor de áudio. Se um periférico estiver faltando, devido a um ajuste mono ou a uma perda de conexão, a central mixa o canal de áudio esquerdo e direito e transmite o áudio para o periférico restante. Se a central perder a conexão com ambos os periféricos, então a central considera 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 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. A manutenção da conexão permite a comunicação dos 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 mais recentes emparelhados.
- Suponha que os periféricos estejam em uso se existir 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 SO, 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 centrais e periféricos devem:
- implementar um controlador compatível com BT 4.2 ou superior. O LE Secure Connections é altamente recomendado.
- ter a central suportando pelo menos 2 enlaces LE simultâneos com parâmetros conforme descrito em Formato de pacote de áudio e temporização .
- ter o periférico suportando pelo menos 1 link LE com os parâmetros descritos em Formato de pacote de áudio e temporização .
- 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.
- faça com que o dispositivo central suporte o comando de atualização de conexão HCI LE e cumpra os parâmetros diferentes de zero
maximum_CE_Lengtheminimum_CE_Length. - 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 temporização .
- faça com que o periférico defina os parâmetros
MaxRxOctetseMaxRxTimenos quadrosLL_LENGTH_REQouLL_LENGTH_RSPpara serem os menores valores necessários para essas 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 o periférico 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 de 1M e 2M. O PHY de longo alcance 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 ASHA GATT
Um periférico deve implementar o serviço de servidor GATT de Audio Streaming for Hearing Aid (ASHA) descrito abaixo. O periférico deve anunciar este serviço quando em modo geral detectável 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:
| Característica | Propriedades | Descrição |
|---|---|---|
| Propriedades somente leitura | 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. Os códigos de operação são:
|
| Volume | Escrever 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 silenciada, ou seja, o nível de volume não silenciado mais baixo é -127, o que equivale a -47,625 dB de atenuação. Na configuração 0, um tom senoidal de trilho para trilho transmitido deve representar uma entrada de 100 dBSPL equivalente no aparelho auditivo. A central deve transmitir em escala nominal total e usar esta 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 |
|---|---|
| Propriedades somente leitura | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Status do áudio | {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 Device Information Service para permitir que a central detecte os nomes dos fabricantes e dos dispositivos do periférico.
Propriedades somente leitura
ReadOnlyProperties têm os seguintes valores:
| Byte | Descrição |
|---|---|
| 0 | Versão - deve ser 0x01 |
| 1 | Consulte DeviceCapabilities . |
| 2-9 | Consulte HiSyncId . |
| 10 | Consulte Mapa de recursos . |
| 11-12 | RenderDelay. Este é o tempo, em milissegundos, desde quando 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 com suporte. 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. |
Capacidades do dispositivo
| Pedaço | 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 de Empresa atribuídos pelo BTSIG. |
| 2-7 | ID exclusivo que identifica o aparelho auditivo. Este ID deve ser definido para o mesmo no periférico esquerdo e direito. |
Mapa de recursos
| Pedaço | Descrição |
|---|---|
| 0 | Streaming de saída de áudio LE CoC suportado (Sim/Não). |
| 1-7 | Reservado (definido como 0). |
Códigos de codec
Se o bit estiver definido, esse codec específico é compatível.
| ID / número de bits | Codec e taxa de amostragem | Taxa de bits necessária | Tempo do quadro | Obrigatório na central (C) ou periférica (P) |
|---|---|---|---|---|
| 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 interrompendo um fluxo de áudio para obter a descrição do procedimento.
| Código de operação | Argumentos | Descrição |
|---|---|---|
1 «Start» |
| 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 fluxo:
O periférico não deve solicitar atualizações de conexão antes que um opcode «Stop» tenha sido 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» |
| 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:
|
Anúncios para o serviço ASHA GATT
O serviço UUID deve estar no pacote de anúncio. No anúncio ou no quadro de resposta de varredura, os periféricos devem ter um Service Data:
| Deslocamento de bytes | Nome | Descrição |
|---|---|---|
| 0 | Comprimento do anúncio | >= 0x09 |
| 1 | Tipo de anúncio | 0x16 (dados de serviço - UUID de 16 bits) |
| 2-3 | Serviço UUID | 0xFDF0 (little-endian) Nota: Este é um ID temporário. |
| 4 | Versão do protocolo | 0x01 |
| 5 | Capacidade |
|
| 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 de 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 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), então os dois tipos de dados ("Nome Local Completo" e "Dados de Serviço para serviço ASHA") deverão aparecer no mesmo quadro. Isso permite que o scanner do dispositivo móvel obtenha os dois dados no mesmo resultado da verificação.
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 vincule 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.
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 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, 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 triggers informam a cada periférico o estado de seu 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, é 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â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 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 estar contando 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 da carga de áudio + 1 (contador de sequência) + 6 (4 para cabeçalho L2CAP, 2 para SDU) - Um evento de conexão deve sempre 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 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 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.
| Codec | Taxa de bits | Intervalo de conexão | Comprimento CE (1M/2M PHY) | Tamanho da carga de áudio |
|---|---|---|---|---|
| G.722 @ 16 kHz | 64 kbit/s | 20 ms | 5000/3750 nós | 160 bytes |
Iniciar e parar 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 prossegue pela seguinte sequência:
- PSM e, opcionalmente, RenderDelay é lido. Esses valores podem ser armazenados em cache pela central.
- Abre-se o canal CoC L2CAP – o periférico deve conceder inicialmente 8 créditos.
- 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.
- Tanto o host central quanto o periférico aguardam o evento de atualização completa.
- 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 espera por uma notificação de status bem-sucedida do comando anterior«Start»do periférico antes do streaming. 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. - 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 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, a partir do passo 5. Quando a central não estiver 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.