Audio Bluetooth de bajo consumo

El audio de Bluetooth de bajo consumo (LEA) garantiza que los usuarios puedan recibir audio de alta fidelidad sin sacrificar la duración de la batería y les permite cambiar sin problemas entre diferentes casos de uso. Android 13 (nivel de API 33) incluye compatibilidad integrada con LEA.

La mayoría de los auriculares LEA serán de modo doble hasta que crezca la participación de mercado de los dispositivos de fuente LEA. Los usuarios deberían poder vincular y configurar ambos transportes en sus auriculares de modo dual.

Casos de uso

Te recomendamos integrar la LEA para los siguientes casos de uso:

  • Uso compartido de audio: Los usuarios pueden compartir simultáneamente varias transmisiones de audio con uno o más dispositivos receptores de audio. El audio se sincroniza entre el dispositivo de origen y los dispositivos conectados.

  • Transmisión de audio: Los usuarios pueden transmitir audio a amigos y familiares, y, al mismo tiempo, conectarse a transmisiones públicas para obtener información, entretenimiento o accesibilidad.

  • Compatibilidad con el códec de audio LC3: Es el códec de audio predeterminado y reemplaza el códec SBC que se usa para A2DP (contenido multimedia) y mSBC en HFP (voz). El LC3 es más eficiente, reconfigurable y de mayor calidad.

  • Mejoras en el muestreo de audio: Los auriculares pueden mantener una alta calidad de audio de salida cuando se usan micrófonos. Bluetooth clásico disminuye la calidad del audio cuando se usan micrófonos Bluetooth. Con BLE Audio, el muestreo de entrada y salida puede alcanzar los 32 kHz.

  • Micrófono estéreo: Los dispositivos de audio pueden grabar audio con micrófonos estéreo para mejorar el audio espacial.

  • Compatibilidad con el perfil de audífonos (HAP): El HAP ofrece a los usuarios mayor accesibilidad y uso que los protocolos de ASHA anteriores. Los usuarios pueden usar sus audífonos para llamadas telefónicas y aplicaciones de VoIP.

  • Compatibilidad con el protocolo de atributos mejorado (EATT): El EATT te permite enviar varios comandos a la vez a los dispositivos de audio vinculados.

Situaciones clave

Hay cuatro categorías principales de casos de uso:

  1. Conversacional: Las aplicaciones de marcador y VoIP que requieren un enrutamiento de comunicación de baja latencia ofrecen audio de alta calidad y un menor uso de batería.

  2. Juegos: El micrófono simultáneo y la reproducción de alta fidelidad permiten que los juegos transmitan audio de alta calidad a los dispositivos de audio. Una app de juego puede acceder a la entrada de audio BLE cuando un juego prepara el micrófono Bluetooth para usarlo. Luego, cuando un jugador inicie una conversación en vivo con un jugador par, la app de juego podrá usar los datos del micrófono sin demoras.

  3. Contenido multimedia: Las aplicaciones de contenido multimedia pueden configurar el dispositivo preferido del administrador de audio. El usuario puede anular esta opción cambiando su dispositivo preferido desde la configuración del sistema.

  4. Accesibilidad: Los audífonos compatibles con BLE Audio pueden usar el micrófono, lo que permite que los usuarios usen sus audífonos de forma continua durante una llamada.

APIs y métodos de audio BLE

Se requieren las siguientes APIs y métodos para admitir dispositivos de audio BLE:

AudioManager

  • setCommunicationDevice() selecciona el dispositivo de audio que se debe usar para los casos de uso de comunicación, por ejemplo, llamadas de voz o videollamadas. Las aplicaciones de chat de voz o videochat pueden usar este método para seleccionar un dispositivo de audio diferente del que selecciona la plataforma de forma predeterminada. Esta API reemplaza las siguientes APIs obsoletas: startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn().
  • Se llama a clearCommunicationDevice() después de que tu app finaliza una llamada o sesión para garantizar que el usuario tenga una excelente experiencia cuando se mueva entre diferentes aplicaciones.

BluetoothProfile

InCallService de Telecom

CallControl de Telecom

Información del dispositivo de audio

  • AudioDeviceInfo.TYPE_BLE_HEADSET describe el tipo de dispositivo de audio como un dispositivo LEA. Se usa para identificar si el dispositivo de audio es un dispositivo LEA.

Grabador de audio

  • setPreferredDevice() establece el dispositivo preferido para el enrutamiento de audio que se usará. El usuario puede anular esta opción en la configuración del sistema.

Adaptador Bluetooth

  • isLeAudioSupported(): Devuelve una constante @BluetoothStatusCodes (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un código de error) que indica si el hardware del dispositivo admite LE Audio.
  • isLeAudioBroadcastSourceSupported(): Devuelve una constante @BluetoothStatusCodes (FEATURE_SUPPORTED, FEATURE_NOT_SUPPORTED o un código de error) que indica si el hardware del dispositivo admite la fuente de transmisión de LE Audio.

Guías según el caso de uso

A continuación, se incluyen lineamientos para implementar la LEA según casos de uso específicos.

Aplicaciones de comunicación por voz

Las aplicaciones de comunicación por voz pueden administrar el enrutamiento de audio y el estado del dispositivo de forma automática o con la API de Telecom, que se encarga de la lógica de enrutamiento de audio y estado por ti.

Estas dos soluciones te permiten controlar el enrutamiento de audio y cambiar entre dispositivos Bluetooth. Para obtener más información, consulta la guía de llamadas administradas de Telecom.

Aplicaciones de grabación de audio

  • Media Recorder: Cuando grabas audio con Media Recorder, puedes grabar en estéreo si el dispositivo de audio Bluetooth admite LEA. Para obtener más información, consulta la guía de grabación de audio.

Recomendaciones de visores

A medida que se lanzan más auriculares LEA, descubrimos problemas en las pruebas del mundo real que degradan la experiencia del usuario. La especificación no abarca todos estos problemas. En la siguiente tabla, se proporciona una lista de recomendaciones que los fabricantes de auriculares LEA deben seguir para mejorar la experiencia de extremo a extremo de los usuarios de Android.

Descripción Contexto
Admite la derivación de claves de transporte cruzado (CTKD) para auriculares de modo doble:
  • Admite la derivación de claves para la vinculación de clásico a LE y de LE a clásico.
 La mayoría de los auriculares LEA nuevos serán de modo doble hasta que crezca la participación de mercado de los dispositivos de origen LEA. Es importante que los usuarios puedan vincular sus auriculares de modo doble sin problemas y configurar ambos transportes. Esto también es importante para la Vinculación rápida de Google.

Admite anuncios segmentados (TA) si quieres que tus auriculares LEA se vuelvan a conectar de forma confiable a los dispositivos de origen.

Los auriculares de LE Audio deben usar TA para solicitar una conexión entrante desde los dispositivos centrales.

Se agregará al próximo SIG de BT.

 A diferencia del modelo de paginación de BR/EDR, en el que el teléfono o los auriculares pueden iniciar una conexión, en LEA, el dispositivo central debe iniciar la conexión. Muchos auriculares no usan TA, lo que significa que es posible que el dispositivo central no pueda volver a conectarse al periférico sin agregarlo a una lista de entidades permitidas. Sin embargo, una solución alternativa de lista de entidades permitidas podría evitar que los auriculares se conecten a un dispositivo central diferente. Por lo tanto, es importante que los auriculares LEA admitan las TA correctamente para que el dispositivo central pueda volver a conectarse de forma confiable sin soluciones alternativas que puedan interrumpir las conexiones multipunto.
Visibilidad optimizada para auriculares de modo doble
  • El auricular principal (componente BR/EDR) debe anunciarse con su dirección pública y habilitar la búsqueda y el análisis de páginas con su nombre disponible a través de EIR, y establecer el bit 14 de LE Audio en 1 en las clases de servicio principales de la clase de dispositivo (CoD).
  • Auricular principal: componente de LE: El auricular principal debe realizar un anuncio conectable y detectable (limitado o general) con la misma dirección pública que el componente de BR/EDR y el mismo nombre local completo que el componente de BR/EDR, con su categoría de apariencia establecida como una categoría de apariencia adecuada que coincida con el tipo de dispositivo remoto, con la expectativa de que el dispositivo central use esta información para ajustar su IU y sus políticas de enrutamiento de audio.
  • Auricular secundario (solo LE): El auricular secundario debe realizar un anuncio conectable y no detectable con su categoría de apariencia establecida como una categoría de apariencia adecuada que coincida con el tipo de dispositivo remoto, con la expectativa de que el dispositivo central use esta información para ajustar sus políticas de IU y enrutamiento de audio.

    Los auriculares deben elegir de forma dinámica un líder del grupo de CSIP para que sea el dispositivo principal. Si el auricular es de modo doble, el dispositivo principal debe ser de modo doble para garantizar que las funciones de LE y Classic funcionen correctamente después de la vinculación.

 Esto evita que los auriculares LEA de modo doble aparezcan como entradas duplicadas en la configuración de Bluetooth, lo que podría confundir a los usuarios y comprometer la experiencia de vinculación de LEA.

La elección dinámica de líder es especialmente importante para los dispositivos de modo doble que se vinculan de forma incremental. Por ejemplo, si solo hay un auricular disponible en la vinculación inicial, debería presentarse como un dispositivo de modo doble. Cuando un usuario vincule el segundo auricular más adelante, solo necesitará vincularlo con el componente de LE, y CSIP se asegurará de que se agrupen en Android.

Se recomienda la dirección de identidad durante la vinculación porque el componente de BR/EDR ya expone la dirección pública del dispositivo a los dispositivos cercanos.
Se agregó compatibilidad con el Protocolo de atributos mejorado (EATT). Reduce la latencia de vinculación y conexión.
Admite el almacenamiento en caché de GATT sólido. Reduce la latencia de conexión, en especial para los auriculares TWS.
Admite la subclasificación de conexiones. Permite una programación de paquetes más flexible y un posible ahorro de batería.
Asegúrate de que, durante el procesamiento previo y posterior para la reproducción y la captura, la canalización de procesamiento de señales pueda funcionar a 16, 24, 32 y 48 kHz, y que admita frecuencias más altas. Aprovecha las tasas de muestreo más altas que se admiten para las rutas de captura de llamadas de LEA o VoIP y la reproducción de contenido multimedia.
Admite el control de energía de LE. Mejor administración de energía

Compatibilidad con tipos de contexto

Descripción Contexto
Usa todos los tipos de contexto especificados en Assigned Numbers 6.12.3, a menos que los auriculares no admitan explícitamente un tipo de contexto determinado. Por ejemplo, si no se admite el tipo de contexto "Juego", Android enviará sonidos de juego. En particular, ten en cuenta que el tipo de contexto "Sin especificar" no significa "cualquier tipo de contexto" y no abarca los tipos de contexto no admitidos.

Cuando el dispositivo central interactúa con el ASCS del dispositivo periférico, el periférico debe conectarse al MCS y al TBS del dispositivo central.

Es posible que el dispositivo central no siempre use LE Audio como la ruta de transmisión, ya que podría recurrir al uso de A2DP o HFP. El dispositivo periférico puede usar la interacción de ASCS como un indicador de si el dispositivo central usará LE Audio para la transmisión.

Algunos ejemplos de interacciones de ASCS son leer, escribir y registrarse para recibir notificaciones.

Recomendaciones de transmisores Auracast

En esta sección, se proporcionan recomendaciones para configurar transmisores de Auracast.

Transmisiones intermitentes

Los anuncios de audio en espacios públicos, como las terminales de transporte público, suelen ser intermitentes y estar separados por largos períodos de silencio. La transmisión continua de silencio o audio de fondo entre anuncios desperdicia la energía del receptor y evita que los usuarios escuchen su transmisión de audio principal, como el contenido multimedia local o cualquier otra transmisión de Auracast activa.

Para mejorar la experiencia del usuario, Android recomienda que los transmisores de Auracast sigan los siguientes lineamientos para controlar las transmisiones intermitentes.

Definiciones

  • Audio de interés: Es el contenido informativo principal destinado al usuario, como un anuncio de puerta de embarque o de tren.
  • Audio de fondo: Silencio, estática o música ambiental de fondo que se transmite entre períodos de audio de interés.
  • Transmisión intermitente: Es una transmisión que alterna entre períodos de audio de interés y períodos de audio de fondo o sin audio.

Identifica transmisiones intermitentes

Para designar una transmisión como intermitente, la emisora debe incluir la estructura de LTV (longitud-tipo-valor) de metadatos de Audio_Active_State [1] en dos ubicaciones:

  1. La estructura BASE de metadatos de nivel 2 (anuncios periódicos) [2]
  2. Los metadatos de anuncio de transmisión pública (anuncios extendidos) [3]

Para ayudar al receptor a identificar la transmisión intermitente y decidir si reproducir la transmisión, el transmisor también debe configurar con precisión la estructura de LTV de metadatos de Streaming_Audio_Context [1].

Identificación de audio de interés

Para indicar de forma dinámica si una transmisión intermitente contiene audio de interés en un momento determinado, el transmisor usa las estructuras de LTV de metadatos de Audio_Active_State.

  • Metadatos de nivel 2 de la estructura BASE: Un valor de 0x01 indica que los BIS en un subgrupo contienen audio de interés.
  • Metadatos de anuncio de transmisión pública: Un valor de 0x01 indica que al menos uno de los BIS dentro de un BIG contiene audio de interés.

Los valores de LTV de los metadatos de Audio_Active_State se deben establecer en 0x01 poco antes de transmitir el audio de interés, lo que permite que un dispositivo de análisis se sincronice con una fuente de transmisión pública. Por el contrario, se debe establecer en 0x00 poco después de que finalice la transmisión.

Aprovecha el contexto de las transmisiones de audio

Proporcionar un contexto explícito ayuda al framework de Android y a los dispositivos receptores a priorizar las transmisiones entrantes. Por ejemplo, un sistema de megafonía (PA) puede establecer el tipo Streaming_Audio_Context en Instructional para permitir que los anuncios interrumpan de forma limpia la reproducción de contenido multimedia local de un receptor y la reanuden sin problemas después.

Referencias

[1] Números asignados de Bluetooth, https://www.bluetooth.com/specifications/assigned-numbers/
[2] Perfil de audio básico, https://www.bluetooth.com/specifications/specs/basic-audio-profile-1-0-3/
[3] Perfil de transmisión pública, https://www.bluetooth.com/specifications/specs/public-broadcast-profile-1-0-2/