Audio Bluetooth de bajo consumo

El audio 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 alternar entre diferentes casos de uso sin problemas. Android 13 (nivel de API 33) incluye compatibilidad integrada con LEA.

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

Casos de uso

Es posible que desees integrar la LEA para los siguientes casos de uso:

• Compartir audio: Los usuarios pueden compartir simultáneamente varios flujos de audio en uno o más dispositivos de salida de audio. El audio se sincroniza entre el dispositivo fuente y los dispositivos conectados.

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

• Compatibilidad con el códec de audio LC3: Este es el códec de audio predeterminado y reemplaza el códec SBC que se usa para A2DP (multimedia) y mSBC en HFP (voz). 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. El Bluetooth clásico reduce la calidad de 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 Hearables pueden grabar audio con micrófonos estéreo para mejorar el audio espacial.

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

• Compatibilidad con el protocolo de atributos mejorados (EATT): El EATT permite que los desarrolladores envíen varios comandos a la vez a los dispositivos de audio inalámbricos vinculados.

Situaciones clave

Existen cuatro categorías principales de casos de uso:

1. Conversacionales: Las aplicaciones de Teléfono 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: La reproducción simultánea de micrófono y alta fidelidad permite que los juegos transmitan audio de alta calidad a los dispositivos de audio. Una app de juegos puede acceder a la entrada de audio BLE cuando un juego activa el micrófono Bluetooth como listo para usar. Luego, cuando un jugador inicia una conversación en vivo con otro jugador, la app del juego puede usar los datos del micrófono sin demora.

3. Multimedia: Las aplicaciones multimedia pueden establecer el dispositivo preferido del administrador de audio. El usuario puede anular esta opción cambiando su dispositivo preferido en la configuración del sistema.

4. Accesibilidad: Los audífonos que admiten audio BLE ahora 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().
• clearCommunicationDevice() se llama después de que tu app finaliza una llamada o sesión para garantizar que el usuario tenga una excelente experiencia cuando se mueve entre diferentes aplicaciones.

BluetoothProfile

• BluetoothLeAudio controla el servicio de Bluetooth a través del objeto proxy.

Telecom InCallService

• InCallService#requestCallEndpointChange() reemplaza las APIs de InCallService.setAudioRoute() y InCallService.requestBluetoothAudio(), que dejaron de estar disponibles, para permitir que las apps soliciten el enrutamiento de audio a un CallEndpoint específico. Los clientes no deben definir su propio CallEndpoint cuando solicitan un cambio. En su lugar, el extremo nuevo debe ser uno de los extremos válidos que proporciona InCallService.onAvailableCallEndpointsChanged(java.util.List).
• CallEndpoint.TYPE_BLUETOOTH dirige la transmisión de audio a través de Bluetooth.
• Las APIs InCallService mencionadas anteriormente están diseñadas para que las use la app de teléfono predeterminada en un teléfono Android o en otras plataformas de llamadas, como wearables, automóviles o cualquier otro dispositivo Bluetooth que pueda influir en el enrutamiento de audio.

Telecom CallControl

• La nueva clase CallControl se introdujo en el nivel de API 34 para reemplazar Connection y ConnectionService solo para aplicaciones de VoIP.
• CallControl.requestCallEndpointChange() también solicita un cambio de CallEndpoint. Esta API reemplaza las APIs obsoletas Connection.requestBluetoothAudio() y Connection.setAudioRoute().
• Además de las APIs de la plataforma de Telecom actualizadas, se recomienda usar la biblioteca de Telecom Jetpack cuando se compilan aplicaciones de llamadas de voz o video. Esta biblioteca puede simplificar en gran medida el proceso de integración y mejorar las llamadas VoIP en todas las plataformas de Android.

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 audición es un dispositivo LEA.

Grabador de audio

• setPreferredDevice() establece el dispositivo preferido para el enrutamiento de audio. El usuario puede anular este parámetro 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 basadas en casos 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 por sí mismas o usar la API de Telecom, que se encarga de la lógica de enrutamiento de audio y estado por ti.

• Autoadministrado: Para las aplicaciones que actualmente usan startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn(), o que desean autoadministrar el estado de enrutamiento de audio, sigue la guía de llamadas autoadministradas del Administrador de audio.

• Administrada: Usa la biblioteca de Telecom Jetpack o las APIs de la plataforma de Telecom para crear una aplicación de llamadas de audio o video.

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

Aplicaciones de grabación de audio

• Grabadora de medios: Cuando grabes audio con la Grabadora de medios, ahora podrás grabar en estéreo si el dispositivo auditivo Bluetooth admite LEA. Consulta la guía de grabación de audio.

Recomendaciones de auriculares

A medida que se lanzan más visores para 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 para LEA deben seguir para mejorar la experiencia integral de los usuarios de Android.

Descripción	Contexto
Se admite la derivación de claves de transporte cruzado (CTKD) para auriculares de modo dual: Admite la derivación de claves para la vinculación de Classic a LE y de LE a Classic.	La mayoría de los auriculares nuevos para LEA serán de modo dual hasta que crezca la participación de mercado de los dispositivos fuente de LEA. Es importante que los usuarios puedan vincular sus auriculares de modo dual sin problemas y configurar ambos transportes. Esto también es importante para la Vinculación rápida de Google.
Admiten anuncios segmentados (TA) si quieres que los auriculares de la LEA se vuelvan a conectar de forma confiable a los dispositivos fuente. Los auriculares de audio LE deben usar TA para solicitar una conexión entrante de los dispositivos centrales. Se agregará al próximo BT SIG.	A diferencia del modelo de búsqueda de BR/EDR, en el que la conexión puede iniciarla el teléfono o los auriculares, en LEA, la conexión debe iniciarla el dispositivo central. Actualmente, 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 impedir que los auriculares se conecten a otro dispositivo central. Por lo tanto, es importante que los auriculares de LEA admitan correctamente a los TA 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 dual El auricular principal: componente BR/EDR debe anunciar su dirección pública y habilitar la consulta y el análisis de página 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 LE: El auricular principal debe realizar un anuncio de Connectable y Discoverable (limitado o general) con la misma dirección pública que el componente BR/EDR y el mismo nombre local completo que el componente 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 de Connectable y Non-Discoverable 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. 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 dual, el dispositivo principal debe ser de modo dual para garantizar que las funcionalidades de LE y Classic funcionen correctamente después de la vinculación.	Esto evita que los auriculares LEA de modo dual 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 del líder es especialmente importante para los dispositivos de modo dual que se vinculan de forma incremental. Por ejemplo, si solo hay un auricular disponible durante el primer vínculo, debería presentarse como un dispositivo de modo dual. Cuando un usuario vincula el segundo auricular más adelante, solo necesita vincularlo con el componente LE, y el CSIP se asegurará de que se agrupen en Android. Se recomienda la dirección de identidad durante el vínculo porque el componente BR/EDR ya expone la dirección pública del dispositivo a los dispositivos cercanos.
Admite el Protocolo de Atributos Mejorados (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 calificación secundaria de la conexión.	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 operar a 16, 24, 32 y 48 kHz, además de admitir frecuencias más altas.	Aprovecha las tasas de muestreo más altas admitidas para las rutas de captura de llamadas LEA o VoIP y la reproducción de contenido multimedia.
Compatibilidad con LE Power Control	Mejor administración de energía

Compatibilidad con el tipo 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, este último debe conectarse al MCS y al TBS del dispositivo central. Es posible que el dispositivo central no siempre use el audio LE como ruta de transmisión, ya que podría recurrir a A2DP o HFP. El dispositivo periférico puede usar la interacción con ASCS como indicación de si el dispositivo central usará audio LE para la transmisión. Algunos ejemplos de interacciones con el ASCS son leer, escribir y registrarse para recibir notificaciones.

Nota: De acuerdo con la especificación, los auriculares pueden quitar tipos de contexto de los tipos de contexto disponibles en cualquier momento y para todos los dispositivos conectados, incluso un dispositivo que esté transmitiendo un tipo de contexto determinado. Se recomienda que los auriculares no quiten el tipo de contexto que se está transmitiendo actualmente de los tipos de contexto disponibles en el dispositivo que está transmitiendo ese tipo de contexto.

Recomendaciones para transmisores Auracast

En esta sección, se proporcionan recomendaciones para configurar transmisores 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 contenido multimedia local o otra transmisión de Auracast activa.

Para mejorar la experiencia del usuario, Android recomienda que los transmisores de Auracast cumplan con 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 o de tren.
• Audio de fondo: Silencio de fondo, estática o música ambiental que se transmite entre los períodos de audio de interés.
• Transmisión intermitente: Es una transmisión que alterna períodos de audio de interés y períodos de audio de fondo o sin audio.

Cómo identificar transmisiones intermitentes

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

1. Metadatos de nivel 2 de la estructura BASE (anuncios periódicos) [2]
2. Metadatos del anuncio de transmisión pública (anuncios extendidos) [3]

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

Cómo identificar el 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 Audio_Active_State.

• Metadatos de nivel 2 de la estructura BASE: Un valor de 0x01 indica que los BIS de un subgrupo actualmente 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 deben establecerse en 0x01 poco antes de transmitir el audio de interés, lo que permite que un dispositivo de exploración se sincronice con una fuente de transmisión pública. Por el contrario, debe establecerse en 0x00 poco después de que finalice la transmisión.

Aprovecha el contexto de audio de transmisión

Proporcionar contexto explícito ayuda al marco de trabajo de Android y a los dispositivos receptores a priorizar los flujos entrantes. Por ejemplo, un sistema de dirección pública (PA) puede establecer el tipo Streaming_Audio_Context en Instructional para permitir que los anuncios interrumpan claramente la reproducción de medios 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/