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 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 de LEA tendrán el modo dual hasta que aumente la participación en el mercado de dispositivos de origen de LEA. Los usuarios deberían poder vincular y configurar ambos transportes en sus auriculares en modo dual.

Casos de uso

Te recomendamos integrar LEA para los siguientes casos de uso:

• Compartir audio: Los usuarios pueden compartir varias transmisiones de audio simultáneamente en 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 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 (contenido multimedia) y mSBC en HFP (voz). LC3 es más eficiente, reconfigurable y de mejor calidad.

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

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

• Compatibilidad con perfiles de audífonos (HAP): 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 mejorado (EATT): EATT permite a los desarrolladores enviar varios comandos a la vez a elementos de audio vinculados.

Situaciones clave

Hay cuatro categorías principales de casos de uso:

1. Conversacional: Las aplicaciones de VoIP y Teléfono que requieren enrutamiento de comunicación de baja latencia ofrecen audio de alta calidad y menos uso de batería.

2. Videojuegos: El micrófono simultáneo y la reproducción de alta fidelidad permiten que los juegos transmitan audio de alta calidad a los audífonos. Una app de juego puede acceder a la entrada de audio BLE cuando un juego activa el micrófono Bluetooth como listo para usar. Luego, cuando un jugador inicie una conversación en vivo con otro jugador, la app de juego podrá usar los datos del micrófono sin demora.

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

4. Accesibilidad: Ahora, los audífonos compatibles con audio BLE pueden usar el micrófono, por lo que los usuarios pueden usarlos de forma continua para una llamada.

Métodos y API de BLE Audio

Se requieren las siguientes APIs y métodos para admitir la función de escucha de audio BLE:

Administrador de audio

• setCommunicationDevice() selecciona el dispositivo de audio que se debe usar para casos de uso de comunicación, como llamadas de voz o videollamadas. Las aplicaciones de chat de voz o video pueden utilizar este método para seleccionar un dispositivo de audio diferente al que se selecciona de forma predeterminada en la plataforma. Esta API reemplaza las siguientes APIs obsoletas: startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn().
• Se llama a clearCommunicationDevice después de que la 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 Bluetooth a través del objeto de proxy.

Servicio entrante de telecomunicaciones

• setAudioRoute() establece la ruta de audio al dispositivo activo actual.
• CallAudioState.ROUTE_BLUETOOTH dirige la transmisión de audio a través de Bluetooth.
• requestBluetoothAudio() solicita enrutamiento de audio a un dispositivo Bluetooth específico.

Información del dispositivo de audio

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

Grabador de audio

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

Adaptador Bluetooth

• isLeAudioSupported() se muestra si el hardware de la plataforma admite LEA.
• isLeAudioBroadcastSourceSupported() se muestra si el hardware de la plataforma admite LEA.

Guías basadas en casos de uso

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

Aplicaciones de comunicación por voz

Las aplicaciones de comunicación por voz tienen la opción de administrar el enrutamiento de audio y el estado del dispositivo, ya sea por su cuenta o mediante la API de Telecom, que realiza el enrutamiento de audio y la lógica de estado por ti.

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

• Administrado: Usa la API de Telecom para crear una aplicación de llamadas de audio o video. Esta API te permite 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 sobre llamadas administradas por telecomunicaciones.

Aplicaciones de grabación de audio

• Grabadora multimedia: Cuando grabes audio con la grabadora multimedia, ahora puedes grabar en estéreo si el sonido Bluetooth admite LEA. Consulta la guía de grabación de audio.

Recomendaciones de auriculares LE Audio (LEA)

A medida que se lanzan más visores LEA, descubrimos problemas en pruebas reales 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
Se admite la Derivación de claves de transporte cruzada (CTKD) para auriculares de modo dual: Se admite la derivación de claves para la vinculación clásica a LE y la de LE a clásica.	La mayoría de los nuevos auriculares de LEA tendrán el modo dual hasta que aumente la participación de mercado de los dispositivos de origen 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 Google Fast Pair.
Admite anuncios segmentados (TA) si quieres que tus auriculares de LEA se vuelvan a conectar de manera confiable a los dispositivos de origen. Los auriculares LE Audio deben usar TA para solicitar una conexión entrante desde los dispositivos centrales. Se agregará a la próxima BT SIG.	A diferencia del modelo de paginación de BR/EDR, en el que el teléfono o los auriculares pueden iniciar una conexión, el dispositivo central debe iniciar la conexión en LEA. 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 lista de tareas permitidas puede impedir que los auriculares se conecten a otro dispositivo central. Por lo tanto, es importante que los auriculares de LEA admitan TA correctamente para que el dispositivo central pueda reconectarse de manera confiable sin soluciones alternativas que puedan interrumpir las conexiones multipunto.
Visibilidad optimizada para auriculares dual-mode Auricular principal: El componente BR/EDR debe anunciar con su dirección pública y habilitar la consulta y el escaneo de página con su nombre disponible a través de EIR, y establecer el bit 14 de audio de bajo consumo en 1 en las clases de servicio mayor de la clase de dispositivo (CoD). Auricular principal (componente LE): El auricular principal debe realizar un anuncio que se pueda conectar y detectable (ya sea 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 aspecto configurada como una categoría de aspecto adecuada que coincida con el tipo de dispositivo remoto con la expectativa de que el dispositivo central usará esta información y el enrutamiento de la IU. Auricular secundario (solo LE): El auricular secundario debe mostrar un anuncio conectable y no detectable con la categoría de apariencia apropiada 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 como dispositivo principal. Si el auricular está en modo dual, el dispositivo principal debe tenerlo para garantizar que las funciones LE y Classic funcionen correctamente después de la vinculación.	De esta manera, se 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 modo dual 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 dual. Más adelante, cuando un usuario se vincule con el segundo auricular, solo deberá vincularse con el componente LE, y CSIP se asegurará de que estén agrupados en Android. Se recomienda la dirección de identidad durante la vinculación porque el componente BR/EDR ya expone la dirección pública del dispositivo a los dispositivos cercanos.
Se agregó compatibilidad con el Protocolo de atributos mejorados (EATT).	Reduce la latencia de vinculación y conexión.
Admite un almacenamiento sólido en caché GATT.	Reduce la latencia de conexión, especialmente para los auriculares TWS.
Admite la subclasificación de conexiones.	Permite una programación de paquetes más flexible y posibles ahorros de batería.
Asegúrate de que, durante el procesamiento previo y posterior de la reproducción y la captura, la canalización de procesamiento de señal pueda funcionar 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 llamadas LEA o las rutas de captura VoIP y la reproducción de contenido multimedia.
Compatibilidad con LE Power Control	Mejor administración de energía

Compatibilidad con tipos de contexto

Descripción	Contexto
Usa todos los tipos de contexto especificados en Números asignados 6.12.3, a menos que los auriculares no admitan explícitamente un tipo de contexto determinado.	Por ejemplo, si el tipo de contexto "Juego" no es compatible, Android enviará sonidos del juego. En particular, ten en cuenta que el tipo de contexto "Sin especificar" no significa "ningún tipo de contexto" y no abarca los tipos de contexto no compatibles.
Cuando el dispositivo central interactúa con el ASCS del dispositivo periférico, el periférico debe conectarse al MCS y TBS del dispositivo central. Es posible que el dispositivo central no siempre use audio de bajo consumo como ruta de transmisión, ya que podría volver a usar A2DP o HFP. El dispositivo periférico puede usar la interacción ASCS como indicación de si el dispositivo central usará audio de bajo consumo para la transmisión. Algunos ejemplos de interacciones de ASCS son la lectura, la escritura y el registro para la notificación.