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). 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 à especificação Bluetooth Core 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 de rede assume uma única central e dois periféricos, um esquerdo e outro direito, conforme visto na Figura 1 . O sistema de áudio Bluetooth vê 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 mixa o canal de áudio esquerdo e direito e transmite o áudio para o periférico restante. Caso a central perca a conexão com ambos os periféricos, então a central considera perdida a ligação ao sink 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 deverá se desconectar do periférico. A manutenção da conexão permite a comunicação de dados com o servidor GATT residente no periférico.
Ao emparelhar e conectar aparelhos auditivos, a central deverá:
- 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 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 esquerdo/direito no sistema operacional, e não ao 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:
- implemente um controlador compatível com BT 4.2 ou superior. LE Secure Connections é altamente recomendado.
- fazer com que a central suporte pelo menos 2 links LE simultâneos com parâmetros descritos em Formato e temporização de pacotes de áudio .
- ter o periférico suportando pelo menos 1 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, 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, Seção 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 esteja em conformidade com os parâmetros
maximum_CE_Lengtheminimum_CE_Lengthdiferentes 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 tempo do pacote de áudio .
- 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 agendador 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 deverá 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.
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 streaming de áudio para aparelhos auditivos (ASHA) descrito abaixo. O periférico deverá 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 exigirão criptografia. O streaming de áudio BLE consiste nas seguintes características:
| Característica | Propriedades | Descrição |
|---|---|---|
| Propriedades somente leitura | Ler | Consulte ReadOnlyProperties . |
| AudioControlPoint | Escreva e escreva sem resposta | Ponto de controle para fluxo de áudio. Consulte AudioControlPoint . |
| Ponto de status de áudio | Ler/Notificar | Campo de relatório de status para o ponto de controle de áudio. Consulte AudioStatusPoint |
| 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 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 transmitido entre trilhos deverá representar uma entrada equivalente a 100 dBSPL no aparelho auditivo. A central deverá transmitir em escala nominal completa e utilizar 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 do serviço : {0xFDF0}
| Característica | UUID |
|---|---|
| Propriedades somente leitura | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Status de á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 deverá implementar o Serviço de Informações de Dispositivos 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 FeatureMap . |
| 11-12 | RenderDelay. Este é o tempo, em milissegundos, desde o momento em que o periférico recebe um quadro de áudio até que o periférico 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. Inicialize com zeros. |
| 15-16 | IDs de codec suportados. Esta é uma máscara de bits de IDs de codec suportados. Uma localização de 1 em um 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. |
Capacidades do dispositivo
| Pedaço | Descrição |
|---|---|
| 0 | Lado do dispositivo (0: esquerdo, 1: direito) |
| 1 | Indica se o dispositivo é independente e recebe dados mono ou se o dispositivo faz parte de um conjunto (0: mono, 1: binaural) |
| 2 | O dispositivo suporta CSIS (0: não compatível, 1: compatível) |
| 3-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 pela BTSIG. |
| 2-7 | ID exclusivo que identifica o conjunto de aparelhos auditivos. Este ID deve ser definido como o mesmo no periférico esquerdo e direito. |
Mapa de recursos
| Pedaço | Descrição |
|---|---|
| 0 | Suporte para streaming de saída de áudio LE CoC (Sim/Não). |
| 1-7 | Reservado (definido como 0). |
Códigos de codec
Se o bit estiver definido, esse codec específico será compatível.
| ID/Número do bit | Codec e taxa de amostragem | Taxa de bits necessária | Tempo de quadro | Obrigatório em central (C) ou periférico (P) |
|---|---|---|---|---|
| 0 | Reservado | Reservado | Reservado | Reservado |
| 1 | G.722 a 16 kHz | 64kbit/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 | Subprocedimento do GATT | Descrição |
|---|---|---|---|
1 «Start» |
| Escreva com resposta e espere uma notificação de status adicional por meio da característica AudioStatusPoint . | 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 codec é “1” para G.722 a 16k Hz. O campo de bit do tipo de áudio indica o(s) tipo(s) de áudio presente(s) no stream:
O periférico não deverá 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 por meio da característica AudioStatusPoint . | Instrui o periférico a interromper a renderização de áudio. Uma nova sequência de configuração de áudio deve ser iniciada após esta parada para renderizar o áudio novamente. |
3 «Status» |
| Escreva 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:
|
Ponto de status de áudio
Campo de relatório de status para o ponto de controle de áudio
| Códigos de operação | Descrição |
|---|---|
| 0 | Estado OK |
| -1 | Comando desconhecido |
| -2 | Parâmetros ilegais |
Anúncios do 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 de varredura, os periféricos devem ter Dados de Serviço:
| 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 | UUID de serviço | 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 Nome Local Completo que indique 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 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 do 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 o 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 conecte a eles.
Sincronizando dispositivos periféricos esquerdo e direito
Para funcionar 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 aumenta 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 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 precisar acontecer. Esses gatilhos informam a cada periférico o 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â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 tempo a partir das âncoras de temporização da camada de link. Para simplificar a implementação:
- Um quadro de áudio deve sempre corresponder ao intervalo de tempo da conexão. 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 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 contar com wrap-around e permitir que o periférico detecte incompatibilidade ou underflow de buffer.
- Um quadro de áudio sempre caberá em um único pacote LE. O quadro de áudio deverá ser enviado como um pacote L2CAP separado. O tamanho da LE LL PDU 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 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 definido pela central.
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 suportados por um periférico, o periférico deverá 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 | 64kbit/s | 20ms | 5000/3750 nós | 160 bytes |
Iniciando e interrompendo um fluxo 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 pela seguinte sequência:
- PSM e, opcionalmente, RenderDelay são lidos. Esses valores podem ser armazenados em cache pela central.
- O canal CoC L2CAP é aberto – o periférico concederá 8 créditos inicialmente.
- Uma atualização de conexão é emitida para mudar o link para os parâmetros necessários para o codec escolhido. A central poderá fazer esta atualização de conexão antes da conexão do CoC na etapa anterior.
- Tanto o host central quanto o periférico aguardam o evento de conclusão da atualização.
- 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«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 deverá estar disponível em todos os eventos de conexão, mesmo que a latência atual da réplica 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 encerrar 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, 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 deverá emitir atualização de conexão para a central. Para economizar energia, a central poderá emitir uma atualização de conexão para o periférico quando este não estiver transmitindo áudio.