Os aparelhos auditivos (HA) podem ter melhor acessibilidade Dispositivos móveis Android usando L2CAP orientados a conexão (CoC) por Bluetooth de baixa energia (BLE). O CoC usa um elástico de vários pacotes de áudio para manter um fluxo constante de áudio, na presença de perda de pacotes. Esse buffer oferece qualidade de áudio aparelhos auditivos em detrimento da latência.
O design do CoC faz referência Bluetooth Especificação principal versão 5 (BT). Para manter o alinhamento com as especificações principais, todos os componentes valores nesta página serão lidos como small-endian.
Terminologia
- Central: o dispositivo Android que verifica se há anúncios por Bluetooth.
- Periférico: o aparelho auditivo que envia pacotes de publicidade por Bluetooth.
Topologia de rede e arquitetura do sistema
Ao usar CoC para aparelhos auditivos, a topologia de rede pressupõe um único central e dois periféricos, um esquerdo e um direito, como visto Figura 1. O sistema de áudio Bluetooth enxerga o lado esquerdo e periféricos corretos como um único coletor de áudio. Se um periférico for devido a um ajuste mono ou à perda de conexão, central mistura os canais de áudio esquerdo e direito e transmite o áudio aos outros periféricos. Se a central perder a conexão com os dois periféricos, a central considera o link para o coletor de áudio perdidos. Nesses casos, a central roteia o áudio para outra saída.
e
Figura 1. Topologia para parear 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 da periférico. Manter a conexão permite que a comunicação de dados para o servidor GATT que está no periférico.
Ao parear e conectar aparelhos auditivos, o central precisa:
- Acompanhe os periféricos esquerdo e direito mais recentes pareados.
- Suponha que os periféricos estejam em uso se houver um pareamento válido. O central vai tentar se conectar ou reconectar com o dispositivo dispositivo do Google quando a conexão for perdida.
- Caso um pareamento seja excluído, suponha que os periféricos não estejam mais em uso.
Nos casos acima, pareamento 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 no processo de pareamento do Bluetooth.
Requisitos do sistema
Para implementar corretamente o CoC e ter uma boa experiência do usuário, o Bluetooth os sistemas na central e nos dispositivos periféricos devem:
- implementar um controlador compatível com BT 4.2 ou superior. As conexões seguras de LE são altamente recomendado.
- ter no suporte central pelo menos dois links LE simultâneos com parâmetros como descritos em Pacote de áudio formato e tempo.
- os periféricos suportam pelo menos um link LE com os parâmetros; descritos em Pacote de áudio formato e tempo.
- ter um controle de fluxo com base em crédito de LE [BT Vol 3, Part A, Sec 10.1]. Os dispositivos devem oferecer suporte a MTU e MPS de pelo menos 167 bytes em CoC e armazenar em buffer até 8 pacotes.
- têm 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.
-
faça com que o dispositivo central seja compatível com o comando de atualização de conexão do HCI LE
e obedecer aos
maximum_CE_Lengthe Parâmetrosminimum_CE_Length. - fazem com que a central mantenha a capacidade de processamento de dados de duas conexões LE CoC para duas diferentes periféricos com os intervalos de conexão e o payload em pacotes de áudio formato e tempo.
-
defina o periférico como
MaxRxOctetse ParâmetrosMaxRxTimenoLL_LENGTH_REQouLL_LENGTH_RSPpara serem os menores valores necessários necessárias para essas especificações. Isso permite que a rede otimizar o programador de tempo ao calcular a quantidade de tempo necessárias para receber um frame.
Recomenda-se que a central e os periféricos suportem PHY de 2 MB como especificado na especificação BT 5.0. A central deve ser compatível com links de áudio de pelo menos 64 kbit/s em 1 milhão e 2 milhões de PHYs. O PHY de longo alcance de BLE não será usado.
O CoC usa mecanismos Bluetooth padrão para criptografia da camada de enlace. e salto de frequência.
Serviços ASHA GATT
Um periférico deve implementar o streaming de áudio para aparelhos auditivos (ASHA) GATT descrito abaixo. O periférico deve anunciar esse serviço no modo detectável geral para permitir que de reconhecimento central de um coletor de áudio. Qualquer operação de streaming de LE Audio que exigem criptografia. O streaming de áudio BLE consiste no as seguintes características:
| Característica | Propriedades | Descrição |
|---|---|---|
| ReadOnlyProperties | Lidas | Consulte ReadOnlyProperties. |
| Ponto de controle de áudio | Escrever e escrever sem resposta | Ponto de controle para o stream de áudio. Consulte AudioControlPoint. |
| Ponto de AudioStatus | Ler/Notificar | Campo do relatório de status do ponto de controle de áudio. Consulte AudioStatusPoint. |
| Volume | Escrever sem resposta | Byte entre -128 e 0 indicando a quantidade de atenuação a ser aplicada à o sinal de áudio transmitido, variando de -48 dB a 0 dB. Ambiente -128 deve ser interpretado como totalmente silenciado, ou seja, o menor volume não silenciado é de -127, o que equivale a uma atenuação de -47,625 dB. Na configuração 0, uma transmissão de tom senoidal coluna a trilho deve representar uma entrada de 100 dBSPL equivalente no aparelho auditivo. A fonte central deve ser transmitida em escala total e usar essa variável para definir o nível de apresentação desejado em o periférico. |
| LE_PSM_OUT | Lidas | PSM a ser usado para conectar o canal de áudio. Para ser selecionado no intervalo dinâmico [BT Vol 3, Parte A, Sec 4.22] |
Os UUIDs atribuídos ao serviço e às características:
UUID de serviço: {0xFDF0}
| Característica | UUID |
|---|---|
| ReadOnlyProperties | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| Ponto de controle de áudio | {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 serviço de informações do dispositivo para que a central detecte os nomes do fabricante e dos dispositivos 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 | o RenderDelay. É o tempo, em milésimos de segundo, a partir do qual um periférico recebe um frame de áudio até ser renderizado a saída. Esses bytes podem ser usados para atrasar um vídeo para para sincronizar com o áudio. |
| 13-14 | Reservado para uso futuro. Inicializar como zero. |
| 15-16 | IDs de codec compatíveis. Isso é um bitmask. de IDs de codecs suportados. Um 1 em uma localização 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. |
Recursos do dispositivo
| Bit | 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 é compatível com CSIS (0: incompatível, 1: compatível) |
| 3-7 | Reservado (definido como 0) |
HiSyncID
Este campo precisa ser exclusivo para todos os dispositivos binaurais, mas precisa ser o o mesmo para os conjuntos da esquerda e da direita.
| Byte | Descrição |
|---|---|
| 0-1 | ID do fabricante. É o Empresa Identificadores atribuídos pelo BTSIG. |
| 2-7 | ID exclusivo que identifica o conjunto de aparelhos auditivos. Esse ID precisa ser definido para o mesmo periférico à esquerda e à direita. |
FeatureMap
| Bit | Descrição |
|---|---|
| 0 | Compatível com streaming de saída de áudio LE CoC (Sim/Não). |
| 1-7 | Reservado (definido como 0). |
IDs de codecs
Se o bit estiver definido, o codec específico será compatível.
| Documento de identificação /&número do bit | Codec e taxa de amostragem | Taxa de bits necessária | Tempo para a renderização do frame | Obrigatório na região 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. |
||||
Ponto de controle de áudio
Este ponto de controle não pode ser usado quando o LE CoC está fechado. Consulte Início e interromper um stream de áudio para a descrição do procedimento.
| Código de operação | Argumentos | Subprocedimento GATT | Descrição |
|---|---|---|---|
1 «Start» |
|
Escrever com resposta e esperar uma notificação de status adicional via 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 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 O código de operação «Stop» foi recebido.
|
2 «Stop» |
Nenhum | Escrever com resposta e esperar uma notificação de status adicional via AudioStatusPoint. | Instrui o periférico a parar a renderização de áudio. Um novo áudio de configuração deve ser iniciada após essa parada para para renderizar o áudio novamente. |
3 «Status» |
|
Escrever sem resposta |
informa ao periférico conectado que há uma atualização de status no
outros periféricos. O campo conectado indica o tipo de atualização:
|
Ponto de AudioStatus
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 |
Publicidade do serviço ASHA GATT
O UUID de serviço precisa estar no pacote de divulgação. Na publicidade ou na verificação, os periféricos devem ter os Dados de Serviço:
| Deslocamento de byte | Nome | Descrição |
|---|---|---|
| 0 | Duração do anúncio | >= 0 x 09 |
| 1 | Tipo de anúncio | 0x16 (dados de serviço - UUID de 16 bits) |
| 2 a 3 | UUID de serviço |
0xFDF0 (little-endian) Observação:esse é um ID temporário. |
| 4 | Versão do protocolo | 0x01 |
| 5 | Capacidade |
|
| 6-9 | HiSyncID truncado | Os quatro bytes mais importantes do HiSyncId. Esses bytes devem ser a parte mais aleatória do ID. |
Os periféricos precisam ter um Nome local completo tipo de dados 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 no dispositivo certo. O nome não deve indicar a direção esquerda ou direita canal, já que essas informações são fornecidas DeviceCapabilities.
Se os periféricos colocarem o nome e os tipos de dados de serviço ASHA no mesmo de frame (ADV ou SCAN RESP) e os dois tipos de dado ("Nome local completo" e "Dados de Serviço para o serviço ASHA") será exibido no mesmo frame. Isso permite que o leitor do dispositivo móvel receba os dois dados no mesmo resultado da verificação.
Durante o pareamento inicial, é importante que os periféricos anunciar a uma taxa rápida o suficiente para permitir que o dispositivo móvel descobrir os periféricos e se vincular a eles.
Sincronizar dispositivos periféricos esquerdo e direito
Para funcionar com o Bluetooth em dispositivos móveis Android e dispositivos periféricos são responsáveis por garantir a sincronização deles. A reprodução Os dispositivos periféricos esquerdo e direito precisam ser sincronizados tempo de resposta. Os dois dispositivos periféricos devem reproduzir amostras de áudio do ao mesmo tempo.
Os dispositivos periféricos podem sincronizar os horários usando uma sequência número anexado ao início de cada pacote do payload de áudio. A principal Os pacotes de áudio devem ser reproduzidos ao mesmo tempo em cada periférico têm o mesmo número de sequência. A sequência o número aumenta em um a cada pacote de áudio. Cada sequência o número tem 8 bits, por isso os números de sequência se repetirão depois de 256 pacotes de áudio. Como o tamanho de cada pacote de áudio e a taxa de amostragem são fixos para cada conexão, os dois periféricos podem deduzir o valor relativo tempo de jogo. Para mais informações sobre o pacote de áudio, consulte Formato do pacote de áudio e tempo real.
A central auxilia ao fornecer gatilhos aos dispositivos binaurais quando a sincronização talvez isso precise acontecer. Esses gatilhos informam cada periférico sobre o status dispositivo periférico pareado sempre que há uma operação que podem afetar a sincronização. Os gatilhos são:
-
Como parte do comando
«Start»do AudioControlPoint, o estado de conexão atual do outro lado da interface binaural dispositivos é fornecida. -
Sempre que houver uma conexão, desconexão ou
de 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 marcação de tempo do pacote de áudio
O empacotamento de frames de áudio (blocos de amostras) em pacotes permite que os ouvintes o instrumento derivam o tempo das âncoras de tempo da camada de enlace. Para simplificar a implementação:
- Um frame de áudio deve sempre corresponder ao intervalo de conexão. Por exemplo, se o intervalo de conexão for 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 a sempre terão um número inteiro de amostras em um frame, independentemente o tempo para a renderização do frame ou o intervalo de conexão.
- Um byte de sequência precede os frames de áudio. O byte de sequência conta com encapsulamento e permite que o periférico detectar incompatibilidade ou falta de fluxo do buffer.
-
Um quadro de áudio deve sempre caber em um único pacote LE. O áudio
deve ser enviado como um pacote L2CAP separado. O tamanho do LE
A PDU do LL será:
tamanho do payload de áudio + 1 (contador de sequências) + 6 (4 para cabeçalho L2CAP, 2 para SDU) - Um evento de conexão deve ser sempre grande o suficiente para conter dois áudios e 2 pacotes vazios para uma ACK reservar largura de banda para e retransmissões. Observe que o pacote de áudio pode ser fragmentado por o 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 à central alguma flexibilidade, o tamanho do pacote G.722 não é especificado. O tamanho do pacote G.722 pode mudar com base na conexão definido pela central.
O formato octeto de saída G.722 faz referência à 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 deve oferecem suporte aos parâmetros de conexão abaixo. Esta é uma lista incompleta de configurações que a central pode implementar.
| Codec | Taxa de bits | Intervalo da conexão | Comprimento CE (1M/2M PHY) | Tamanho do payload de áudio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 bytes |
Iniciar e parar um stream de áudio
Antes de iniciar um stream de áudio, a central consulta os periféricos e estabelece um codec de denominador comum. O stream do dispositivo segue esta sequência:
- PSM e, opcionalmente, RenderDelay é lido. Esses valores podem ser armazenados em cache pela central.
- O canal do CoC L2CAP está aberto – o periférico concederá 8 créditos inicialmente.
- Uma atualização de conexão é emitida para alternar o link para os parâmetros necessário para o codec escolhido. A central pode fazer essa atualização de conexão antes da conexão do CoC na etapa anterior.
- Os hosts central e periférico aguardam a atualização evento completo.
-
Reinicie o codificador de áudio e redefina a contagem da sequência de pacotes como 0.
Um comando
«Start»com os parâmetros relevantes é emitido no AudioControlPoint. A central espera uma notificação de status bem-sucedida do comando«Start»anterior do periférico antes do streaming. Essa espera dá ao periférico para preparar o pipeline de reprodução de áudio. Durante o streaming de áudio, a réplica deve estar disponível em cada evento de conexão, mesmo que a a latência da réplica pode ser diferente de zero. - O periférico pega o primeiro pacote de áudio da fila interna dele (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 todas evento de conexão. Para reiniciar o streaming de áudio, siga a sequência acima, começando da etapa 5. Quando a central não está streaming de áudio, ele ainda deverá manter uma conexão LE para GATT serviços.
O periférico não deve atualizar a conexão com a central. Para economizar energia, a central pode atualizar a conexão com o quando não estiver transmitindo áudio.