Os aparelhos auditivos (HA, na sigla em inglês) podem ter acessibilidade aprimorada em dispositivos móveis Android usando canais L2CAP orientados à conexão (CoC) 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 aparelhos auditivos, mas aumenta a latência.
O design do CoC faz referência à Especificação principal do Bluetooth, versão 5 (BT). Para ficar alinhado com as especificações principais, todos os valores de vários bytes nesta página precisam 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 de sistema
Ao usar o CoC para aparelhos auditivos, a topologia de rede pressupõe um único dispositivo central e dois periféricos, um esquerdo e um direito, como mostrado na Figura 1. O sistema de áudio Bluetooth considera os periféricos esquerdo e direito como um único receptor de áudio. Se um dispositivo periférico estiver ausente devido a um ajuste monaural ou perda de conexão, o dispositivo central vai misturar os canais de áudio esquerdo e direito e transmitir o áudio para o dispositivo periférico restante. Se o dispositivo central perder a conexão com os dois periféricos, ele vai considerar que a vinculação com o coletor de áudio foi perdida. Nesses casos, o dispositivo 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 está transmitindo dados de áudio para o periférico e pode manter uma conexão BLE, ela 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 parear e conectar aparelhos auditivos, a central precisa:
- Acompanhe os periféricos esquerdo e direito pareados mais recentemente.
- Suponha que os periféricos estão em uso se houver um pareamento válido. O hub precisa tentar se conectar ou reconectar com o dispositivo pareado quando a conexão é perdida.
- Suponha que os periféricos não estejam mais em uso se um pareamento for excluído.
Nos casos acima, pareamento se refere à ação de registrar um conjunto de aparelhos auditivos com um determinado UUID e designadores esquerdo/direito no SO, não o processo de pareamento por Bluetooth.
Requisitos do sistema
Para implementar corretamente o CoC e oferecer uma boa experiência ao usuário, os sistemas Bluetooth nos dispositivos central e periférico precisam:
- implementar um controlador compatível com BT 4.2 ou mais recente. É altamente recomendável usar conexões seguras LE.
- ter suporte central para pelo menos dois links LE simultâneos com parâmetros conforme descrito em Formato e tempo do pacote de áudio.
- ter suporte para pelo menos uma conexão 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, Part A, Sec 10.1]. Os dispositivos precisam ser compatíveis com um tamanho de MTU e MPS de pelo menos 167 bytes no CoC e armazenar em buffer até 8 pacotes.
- ter uma extensão de comprimento de dados LE [BT Vol 6, Part B, Sec 5.1.9] com um payload de pelo menos 167 bytes.
-
o dispositivo central seja compatível com 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. - manter a taxa de transferência de dados para duas conexões LE CoC com dois periféricos diferentes com os intervalos de conexão e tamanhos de payload em Formato e tempo do pacote de áudio.
-
faça com que o periférico defina os parâmetros
MaxRxOctetseMaxRxTimenos framesLL_LENGTH_REQouLL_LENGTH_RSPcomo os menores valores necessários para essas especificações. Isso permite que o hub otimize o programador de tempo ao calcular a quantidade de tempo necessária para receber um frame.
É altamente recomendável que o dispositivo central e o periférico sejam compatíveis com a camada física de 2 MB, conforme especificado na especificação BT 5.0. O hub precisa ser compatível com links de áudio de pelo menos 64 kbit/s em PHYs de 1M e 2M. O PHY de longo alcance BLE não pode ser usado.
O CoC usa os mecanismos padrão do Bluetooth para criptografia da camada de enlace e salto de frequência.
Serviços GATT da ASHA
Um dispositivo periférico precisa implementar o serviço de servidor GATT de streaming de áudio para aparelhos auditivos (ASHA) descrito abaixo. O periférico precisa anunciar esse serviço quando estiver no modo de descoberta geral para permitir que o dispositivo central reconheça um receptor de áudio. Todas as operações de streaming de áudio LE precisam de criptografia. O streaming de áudio BLE tem as seguintes características:
| Característica | Propriedades | Descrição |
|---|---|---|
| ReadOnlyProperties | Ler | Consulte ReadOnlyProperties. |
| AudioControlPoint | Escrever e Escrever sem resposta | Ponto de controle para stream de áudio. Consulte AudioControlPoint. |
| AudioStatusPoint | Ler/Notificar | Campo de relatório de status para o ponto de controle de áudio. Consulte AudioStatusPoint. |
| Volume | Escrever sem resposta | Byte entre -128 e 0 que indica a quantidade de atenuação a ser aplicada ao sinal de áudio transmitido, variando de -48 dB a 0 dB. Definir -128 precisa ser interpretado como totalmente silenciado.Ou seja, o menor nível de volume não silenciado é -127, o que equivale a uma atenuação de -47,625 dB. Na configuração 0, um tom senoidal de ponta a ponta transmitido precisa representar uma entrada equivalente de 100 dBSPL no aparelho auditivo. A central precisa 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, Part 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 GATT ASHA, o periférico também precisa implementar o serviço de informações do dispositivo para permitir que o dispositivo 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: precisa ser 0x01 |
| 1 | Consulte DeviceCapabilities. |
| 2-9 | Consulte HiSyncId. |
| 10 | Consulte FeatureMap. |
| 11-12 | RenderDelay. É o tempo, em milissegundos, desde 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 e sincronizar com o áudio. |
| 13-14 | Reservado para uso futuro. Inicialize com zeros. |
| 15-16 | IDs de codec compatíveis. Esta é uma máscara de bits de IDs de codec compatíveis. Um 1 em um local de bit corresponde a um codec compatível. Por exemplo, 0x0002 indica que o G.722 a 16 kHz é compatível. Todos os outros bits precisam ser 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 faz parte de um conjunto (0: monaural, 1: binaural). |
| 2 | O dispositivo é compatível com CSIS (0: não compatível, 1: compatível) |
| 3-7 | Reservado (definido como 0) |
HiSyncID
Esse campo precisa ser exclusivo para todos os dispositivos binaurais, mas igual para os conjuntos esquerdo e direito.
| Byte | Descrição |
|---|---|
| 0-1 | ID do fabricante. São os identificadores de empresa atribuídos pela 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 | Transmissão de saída de áudio LE CoC compatível (Sim/Não). |
| 1-7 | Reservado (definido como 0). |
IDs de codec
Se o bit estiver definido, o codec específico terá suporte.
| ID / Número do bit | Codec e taxa de amostragem | Taxa de bits necessária | Tempo para a renderização do frame | Obrigatório no centro (C) ou na periferia (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 da LE está fechado. Consulte Como iniciar e interromper um fluxo de áudio para ver a descrição do procedimento.
| Opcode | 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 de codec é "1" para G.722 a 16k Hz. O campo de bits 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 de um opcode «Stop» ser recebido.
|
2 «Stop» |
Nenhum | Escreva com resposta e espere uma notificação de status adicional pela característica AudioStatusPoint. | Instrui o periférico a 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 de relatório de status para o ponto de controle de áudio
| Códigos de operação | Descrição |
|---|---|
| 0 | Status OK |
| -1 | Comando desconhecido |
| -2 | Parâmetros ilegais |
Publicidades do serviço GATT da ASHA
O UUID do serviço precisa estar no pacote de anúncio. No anúncio ou no frame de resposta da verificação, 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 precisam ser a parte mais aleatória do ID. |
Os periféricos precisam ter um tipo de dados Nome local completo que indica 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 pode indicar 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 do 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 scanner do dispositivo móvel receba os dois dados no mesmo resultado de verificação.
Durante o pareamento inicial, é importante que os periféricos anunciem em uma taxa rápida o suficiente para permitir que o dispositivo móvel descubra e se conecte a eles rapidamente.
Sincronizar dispositivos periféricos esquerdo e direito
Para trabalhar com Bluetooth em dispositivos móveis Android, os periféricos são responsáveis por garantir que estejam sincronizados. A reprodução nos dispositivos periféricos esquerdo e direito precisa ser sincronizada a tempo. Os dois dispositivos periféricos precisam reproduzir amostras de áudio da fonte ao mesmo tempo.
Os dispositivos periféricos podem sincronizar o horário usando um número de sequência adicionado a cada pacote da carga de áudio. O hub garante que os pacotes de áudio que devem ser reproduzidos ao mesmo tempo em cada dispositivo 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 se repetem 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 mais informações sobre o pacote de áudio, consulte Formato e tempo do pacote de áudio.
O dispositivo central ajuda fornecendo acionadores aos dispositivos binaurais quando a sincronização pode precisar acontecer. Esses gatilhos 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 gatilhos são:
-
Como parte do comando
«Start»de AudioControlPoint, o estado atual da conexão 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 do pacote de áudio
Ao agrupar frames de áudio (blocos de amostras) em pacotes, o aparelho auditivo pode derivar a marcação de tempo das âncoras de marcação 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 20 ms e a taxa de amostragem for 16 kHz, o frame de áudio precisará 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 do frame ou do intervalo de conexão.
- Um byte de sequência precisa preceder os frames de áudio. O byte de sequência precisa ser contado com substituição e permitir que o periférico detecte incompatibilidade ou estouro negativo do buffer.
-
Um frame de áudio precisa sempre caber em um único pacote LE. O frame de áudio precisa ser enviado como um pacote L2CAP separado. O tamanho da PDU LE
LL precisa 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 precisa ser sempre grande o suficiente para conter dois pacotes de áudio e dois pacotes vazios para um ACK reservar largura de banda para retransmissões. O pacote de áudio pode ser fragmentado pelo controlador Bluetooth do dispositivo central. O periférico precisa 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 de acordo com o intervalo de conexão definido pelo hub.
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 (PHY de 1M/2M) | Tamanho do payload de áudio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 bytes |
Iniciar e interromper um stream de áudio
Antes de iniciar um stream de áudio, o hub consulta os periféricos e estabelece um codec de denominador comum. A configuração do stream segue a seguinte sequência:
- PSM e, opcionalmente, RenderDelay são lidos. Esses valores podem ser armazenados em cache pelo hub.
- O canal L2CAP de CoC é aberto. O periférico precisa 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 pode fazer essa atualização de conexão antes da conexão CoC na etapa anterior.
- Os hosts central e 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. O hub aguarda uma notificação de status bem-sucedida do comando«Start»anterior do periférico antes de fazer o streaming. Essa espera dá ao periférico tempo 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.
O problema 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 a transmissão 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 serviços GATT.
O periférico não pode emitir uma atualização de conexão para o dispositivo central. Para economizar energia, o hub pode emitir uma atualização de conexão para o dispositivo periférico quando não estiver transmitindo áudio.