Áudio Bluetooth de baixa energia

O áudio de baixa energia (LEA, na sigla em inglês) do Bluetooth garante que os usuários recebam áudio de alta fidelidade sem sacrificar a duração da bateria e permite que eles alternem entre diferentes casos de uso. O Android 13 (nível 33 da API) inclui suporte integrado para LEA.

A maioria dos headsets LEA será de modo duplo até que a participação de mercado dos dispositivos de origem LEA cresça. Os usuários precisam conseguir parear e configurar os dois transportes nos headsets de modo duplo.

Casos de uso

É recomendável integrar a LEA para os seguintes casos de uso:

  • Compartilhamento de áudio: os usuários podem compartilhar simultaneamente vários fluxos de áudio com um ou mais dispositivos de receptor de áudio. O áudio é sincronizado entre o dispositivo de origem e os dispositivos conectados.

  • Transmitir áudio: os usuários podem transmitir áudio para amigos e familiares, além de se conectar a transmissões públicas para ter acesso a informações, entretenimento ou recursos de acessibilidade.

  • Suporte ao codec de áudio LC3: esse é o codec de áudio padrão e substitui o codec SBC usado para A2DP (mídia) e mSBC em HFP (voz). O LC3 é mais eficiente, reconfigurável e de maior qualidade.

  • Melhorias na amostragem de áudio: os fones de ouvido podem manter a qualidade de áudio de alta saída ao usar microfones. O Bluetooth clássico reduz a qualidade do áudio ao usar microfones Bluetooth. Com o BLE Audio, a amostragem de entrada e saída pode chegar a 32 kHz.

  • Microfone estéreo: os hearables podem gravar áudio com microfones estéreo para melhorias de áudio espacial.

  • Compatibilidade com o perfil de aparelhos auditivos (HAP): o HAP oferece aos usuários mais acessibilidade e uso do que os protocolos ASHA anteriores. Os usuários podem usar os aparelhos auditivos para fazer ligações e usar aplicativos VoIP.

  • Suporte ao protocolo de atributo avançado (EATT): o EATT permite que os desenvolvedores enviem vários comandos de uma vez para aparelhos auditivos pareados.

Principais cenários

Há quatro categorias principais de casos de uso:

  1. Conversacional: aplicativos de discador e VoIP que exigem roteamento de comunicação de baixa latência oferecem áudio de alta qualidade e menor uso da bateria.

  2. Jogos: o microfone simultâneo e a reprodução de alta fidelidade permitem que os jogos transmitam áudio de alta qualidade para os dispositivos de áudio. Um app de jogos pode acessar a entrada de áudio BLE quando um jogo ativa o microfone Bluetooth como pronto para uso. Assim, quando um jogador inicia uma conversa ao vivo com outro, o app de jogo pode usar os dados do microfone sem atraso.

  3. Mídia: os aplicativos de mídia podem definir o dispositivo preferido do gerenciador de áudio. O usuário pode substituir isso alterando o dispositivo preferido nas configurações do sistema.

  4. Acessibilidade: os aparelhos auditivos compatíveis com BLE Audio agora podem usar o microfone, permitindo que os usuários usem os aparelhos auditivos continuamente para uma chamada.

APIs e métodos de áudio BLE

As seguintes APIs e métodos são necessários para oferecer suporte a dispositivos auditivos de áudio BLE:

AudioManager

  • setCommunicationDevice() seleciona o dispositivo de áudio que deve ser usado para casos de uso de comunicação, como chamadas de voz ou vídeo. Esse método pode ser usado por aplicativos de chat de voz ou chat por vídeo para selecionar um dispositivo de áudio diferente daquele selecionado por padrão pela plataforma. Essa API substitui as seguintes APIs descontinuadas: startBluetoothSco(), stopBluetoothSco(), e setSpeakerphoneOn().
  • clearCommunicationDevice() é chamado depois que o app termina uma chamada ou sessão para garantir que o usuário tenha uma ótima experiência ao alternar entre diferentes aplicativos.

BluetoothProfile

Telecom InCallService

Telecom CallControl

Informações do dispositivo de áudio

  • AudioDeviceInfo.TYPE_BLE_HEADSET descreve o tipo de dispositivo de áudio como um dispositivo LEA. Usado para identificar se o dispositivo auditivo é um dispositivo LEA.

Gravador de áudio

  • setPreferredDevice() define o dispositivo preferido para usar no roteamento de áudio. O usuário pode mudar isso nas configurações do sistema.

Adaptador Bluetooth

Guias com base no caso de uso

Confira abaixo as diretrizes para implementar a LEA com base em casos de uso específicos.

Aplicativos de comunicação por voz

Os aplicativos de comunicação por voz podem gerenciar o roteamento de áudio e o estado do dispositivo por conta própria ou usando a API Telecom, que faz o roteamento de áudio e a lógica de estado para você.

Com essas duas soluções, você controla o roteamento de áudio e alterna entre dispositivos Bluetooth com rapidez e facilidade. Para mais informações, consulte o guia de chamadas gerenciadas por telecomunicações.

Aplicativos de gravação de áudio

  • Gravador de mídia: ao gravar áudio usando o Gravador de mídia, agora é possível gravar em estéreo se o dispositivo auditivo Bluetooth for compatível com LEA. Confira o guia de gravação de áudio.

Recomendações de fones de ouvido

À medida que mais headsets LEA são lançados, descobrimos problemas em testes no mundo real que prejudicam a experiência do usuário. A especificação não aborda todos esses problemas. A tabela a seguir fornece uma lista de recomendações que os fabricantes de headsets LEA precisam seguir para melhorar a experiência de ponta a ponta dos usuários do Android.

Descrição Contexto
Compatibilidade com derivação de chaves de transporte cruzado (CTKD) para fones de ouvido de modo duplo:
  • Suporte à derivação de chaves para pareamento clássico para LE e LE para clássico.
 A maioria dos novos headsets LEA será de modo duplo até que a participação de mercado dos dispositivos de origem LEA aumente. É importante que os usuários possam parear os fones de ouvido de modo duplo sem problemas e configurar os dois transportes. Isso também é importante para o Google Fast Pair.

Suporte a anúncios segmentados (TAs, na sigla em inglês) se você quiser que os headsets LEA se reconectem de forma confiável aos dispositivos de origem.

Os fones de ouvido de áudio LE usam TAs para solicitar uma conexão de entrada dos dispositivos centrais.

Será adicionado ao próximo BT SIG.

 Ao contrário do modelo de paginação do BR/EDR, em que uma conexão pode ser iniciada pelo smartphone ou pelo headset, uma conexão no LEA precisa ser iniciada pelo dispositivo central. No momento, muitos headsets não usam TAs. Isso significa que o dispositivo central pode não conseguir se reconectar ao periférico sem adicioná-lo a uma lista de permissões. No entanto, uma solução alternativa de lista de permissões pode impedir que o headset se conecte a um dispositivo central diferente. Portanto, é importante que os headsets de LEA ofereçam suporte adequado aos TAs para que o dispositivo central possa se reconectar de maneira confiável sem soluções alternativas que possam interromper conexões multiponto.
Descoberta otimizada para fones de ouvido de modo duplo
  • O earbud principal: componente BR/EDR precisa anunciar usando o endereço público e ativar a consulta e a verificação de página com o nome disponível pelo EIR, além de definir o bit 14 de áudio LE como 1 nas principais classes de serviço da classe de dispositivo (CoD).
  • Earbud principal: componente LE: o earbud principal precisa fazer uma publicidade conectável e detectável (limitada ou geral) usando o mesmo endereço público do componente BR/EDR e o mesmo nome local completo do componente BR/EDR, com a categoria de aparência definida como uma categoria de aparência adequada que corresponda ao tipo de dispositivo remoto, com a expectativa de que o dispositivo central use essas informações para ajustar a interface e as políticas de roteamento de áudio.
  • Earbud secundário – somente LE: o earbud secundário precisa fazer um anúncio conectável e não detectável com a categoria de aparência definida como uma categoria adequada que corresponda ao tipo de dispositivo remoto, com a expectativa de que o dispositivo central use essas informações para ajustar a interface e as políticas de roteamento de áudio.

    Os fones de ouvido precisam eleger dinamicamente um líder do grupo CSIP para ser o dispositivo principal. Se o fone de ouvido for de modo duplo, o dispositivo principal também precisará ser para garantir que as funcionalidades LE e clássica funcionem corretamente após o pareamento.

 Isso evita que os fones de ouvido LEA de modo duplo apareçam como entradas duplicadas nas configurações de Bluetooth, o que pode confundir os usuários e comprometer a experiência de pareamento LEA.

A eleição dinâmica de líder é especialmente importante para dispositivos de modo duplo que são pareados incrementalmente. Por exemplo, se apenas um fone de ouvido estiver disponível no pareamento inicial, ele vai se apresentar como um dispositivo de modo duplo. Quando um usuário pareia com o segundo fone de ouvido mais tarde, ele só precisa parear com o componente LE, e o CSIP garante que eles sejam agrupados no Android.

O endereço de identidade é recomendado durante o pareamento porque o componente BR/EDR já expõe o endereço público do dispositivo para dispositivos próximos.
Suporte ao Enhanced Attribute Protocol (EATT). Reduz a latência de pareamento e conexão.
Suporte a armazenamento em cache GATT robusto. Reduz a latência da conexão, principalmente para fones de ouvido TWS.
Suporte à subavaliação da conexão. Permite um agendamento de pacotes mais flexível e uma possível economia de bateria.
Durante o pré e o pós-processamento para reprodução e captura, o pipeline de processamento de sinal precisa operar a 16, 24, 32 e 48 kHz, além de oferecer suporte a frequências mais altas. Aproveita as taxas de amostragem mais altas compatíveis com caminhos de captura de chamadas LEA ou VoIP e reprodução de mídia.
Compatibilidade com controle de energia LE Melhor gerenciamento de energia

Suporte ao tipo de contexto

Descrição Contexto
Use todos os tipos de contexto especificados em Assigned Numbers 6.12.3 a menos que o headset não seja compatível com um determinado tipo de contexto. Por exemplo, se o tipo de contexto "Jogo" não for compatível, o Android enviará sons de jogos. Em particular, observe que o tipo de contexto "Não especificado" não significa "qualquer tipo de contexto" e não abrange tipos de contexto não compatíveis.

Quando o dispositivo central interage com o ASCS do periférico, o periférico precisa se conectar ao MCS e ao TBS do dispositivo central.

O dispositivo central nem sempre usa o LE Audio como rota de streaming porque pode voltar a usar A2DP ou HFP. O dispositivo periférico pode usar a interação ASCS como uma indicação de se o dispositivo central vai usar o áudio LE para streaming.

Alguns exemplos de interações do ASCS são leitura, gravação e registro para notificação.

Recomendações de transmissores Auracast

Nesta seção, fornecemos recomendações para configurar transmissores Auracast.

Transmissões intermitentes

Os anúncios de áudio em espaços públicos, como terminais de transporte, geralmente são intermitentes e separados por longos períodos de silêncio. A transmissão contínua de silêncio ou áudio em segundo plano entre anúncios desperdiça energia do receptor e impede que os usuários ouçam o stream de áudio principal, como mídia local ou outro stream do Auracast ativo.

Para melhorar a experiência do usuário, o Android recomenda que os transmissores Auracast sigam as diretrizes abaixo para lidar com transmissões intermitentes.

Definições

  • Áudio de interesse:o conteúdo informativo principal destinado ao usuário, como um anúncio de portão ou trem.
  • Áudio de fundo:silêncio, estática ou música ambiente transmitidos entre períodos de áudio de interesse.
  • Transmissão intermitente:uma transmissão que alterna entre períodos de áudio de interesse e períodos de áudio em segundo plano ou sem áudio.

Identificar transmissões intermitentes

Para designar uma transmissão como intermitente, o emissor precisa incluir a estrutura LTV (comprimento-tipo-valor) de metadados Audio_Active_State [1] em dois locais:

  1. Metadados de nível 2 da estrutura BASE (anúncios periódicos) [2]
  2. Metadados de anúncio de transmissão pública (anúncios estendidos) [3]

Para ajudar o destinatário a identificar a transmissão intermitente e decidir se quer reproduzir o stream, o emissor também precisa definir com precisão a estrutura LTV de metadados Streaming_Audio_Context [1].

Identificação de áudio de interesse

Para sinalizar dinamicamente se uma transmissão intermitente contém áudio de interesse a qualquer momento, o transmissor usa as estruturas LTV de metadados Audio_Active_State.

  • Metadados de nível 2 da estrutura BASE:um valor de 0x01 indica que os BISes em um subgrupo contêm áudio de interesse.
  • Metadados de anúncio de transmissão pública:um valor de 0x01 indica que pelo menos um dos BISs em um BIG contém áudio de interesse.

Os valores de LTV de metadados Audio_Active_State precisam ser definidos como 0x01 pouco antes da transmissão de áudio de interesse, permitindo que um dispositivo de leitura sincronize com uma fonte de transmissão pública. Por outro lado, ele precisa ser definido como 0x00 logo após o fim da transmissão.

Aproveitar o contexto de streaming de áudio

Fornecer contexto explícito ajuda o framework do Android e os dispositivos receptores a priorizar os fluxos de entrada. Por exemplo, um sistema de endereço público (PA, na sigla em inglês) pode definir o tipo Streaming_Audio_Context como "Instrucional" para permitir que os anúncios interrompam a reprodução de mídia local de um receptor e a retomem sem problemas depois.

Referências

[1] Números atribuídos do Bluetooth, https://www.bluetooth.com/specifications/assigned-numbers/
[2] Perfil de áudio básico, https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
[3] Perfil de transmissão pública, https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/