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 batería y les permite alternar sin problemas entre los diferentes casos de uso. Android 13 (nivel de API 33) incluye compatibilidad integrada para LEA.

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

Casos de uso

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

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

• Transmitir audio: Los usuarios pueden transmitir audio a amigos y familiares, al mismo tiempo que se conectan a transmisiones públicas de información, entretenimiento o accesibilidad.

• Compatibilidad con códecs de audio LC3: Es el códec de audio predeterminado y reemplaza el códec SBC utilizado para A2DP (contenido 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 salida de audio cuando usan micrófonos. La versión clásica de Bluetooth reduce la calidad del audio cuando se utilizan micrófonos Bluetooth. Con BLE Audio, el muestreo de entrada y salida puede alcanzar los 32 kHz.

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

• Compatibilidad con perfiles de audífonos (HAP): El HAP ofrece a los usuarios una 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 mejorados (EATT): EATT permite que los desarrolladores envíen varios comandos a la vez a los dispositivos auditivos vinculados.

Situaciones clave

Hay cuatro categorías principales de casos de uso:

1. Conversacional: Las aplicaciones de Teléfono y VoIP que requieren enrutamiento de comunicación de baja latencia ofrecen audio de alta calidad y menos uso de la 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 dispositivos de audio. 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 inicia una conversación en vivo con otro jugador, la app de juego puede 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 BLE Audio pueden usar el micrófono, lo que les permite a los usuarios utilizarlos continuamente para una llamada.

APIs y métodos de BLE Audio

Se requieren las siguientes APIs y métodos para admitir los audios de BLE Audio:

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 distinto al seleccionado 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 tu app finaliza una llamada o sesión para ayudar a garantizar que el usuario tenga una excelente experiencia cuando cambia de una aplicación a otra.

BluetoothProfile

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

Servicio en llamada 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 LEA. Se usa para identificar si el dispositivo auditivo es un dispositivo LEA.

Grabador de audio

• setPreferredDevice() establece el dispositivo preferido para el enrutamiento de audio. El usuario puede anular esta opción 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 las pautas para implementar el 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 autogestionando su estado o utilizando la API de Telecom, que realiza el enrutamiento de audio y la lógica de estado por ti.

• Autoadministrado: Para aplicaciones que actualmente usan startBluetoothSco(), stopBluetoothSco() y setSpeakerphoneOn() o si quieres administrar por tu cuenta el estado de enrutamiento de audio, sigue la guía de llamadas autoadministradas del Administrador de audio.

• Administrada: Usa la API de Telecom para crear una aplicación de llamada de audio o video. Esta API te permite controlar rápida y fácilmente el enrutamiento de audio y el cambio entre Dispositivos Bluetooth Para obtener más información, consulta la Guía sobre llamadas administradas de telecomunicaciones

Aplicaciones de grabación de audio

• Grabadora de contenido multimedia: Cuando grabes audio con la grabadora multimedia, 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 LE Audio (LEA)

A medida que se lanzan más auriculares de la LEA, descubrimos problemas en el mundo real y pruebas que degraden la experiencia del usuario. La especificación no abarca todos de estos problemas. En la siguiente tabla, se proporciona una lista de recomendaciones que Los fabricantes de auriculares de la LEA deben seguir las instrucciones 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 duales: Se admite la derivación de claves tanto para la vinculación clásica a LE como Vinculación de un LE a un clásico.	La mayoría de los nuevos auriculares LEA tendrán un modo dual hasta que el dispositivo de origen de LEA y participación de mercado. Es importante que los usuarios puedan vincular sus de auriculares dual-mode a la perfección y para configurar ambos medios de transporte. Este es también es importante para la Vinculación rápida de Google.
Si lo deseas, puedes admitir anuncios segmentados (TA). los auriculares LEA para que 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 reunión de BT SIG.	A diferencia del modelo de paginación de BR/EDR, en el que se puede iniciar una conexión por el teléfono o los auriculares, se debe establecer una conexión en LEA que el dispositivo central inicia. Actualmente, muchos auriculares no utilizan TA, lo que significa que el dispositivo central tal vez no pueda vuelve a conectarte al periférico sin agregarlo a una lista de entidades permitidas. Sin embargo, una solución alternativa incluida en la lista de entidades permitidas puede impedir que los auriculares que se conecta a otro dispositivo central. Por lo tanto, es importante para que los auriculares LEA admitan TA correctamente para que el dispositivo central puedan volver a conectarse de manera confiable sin soluciones alternativas que puedan fallar conexiones de varios puntos.
Visibilidad optimizada de los auriculares de modo dual Auricular principal: componente BR/EDR debe promocionar mediante su dirección pública y habilitar el análisis de consultas y de página con disponible a través del EIR y configura el bit 14 de LE Audio en la Principales Clases de Servicios de Clase de Dispositivo (CoD). Auricular principal (componente LE): Es el auricular principal debe realizar un trabajo de tipo conectable y detectable (ya sea limitado o anuncios generales) que usen la misma dirección pública que el BR/EDR. Componente y el mismo nombre local completo que el BR/EDR de imagen, con la categoría de apariencia configurada como una opción Es una categoría de apariencia que coincide con el tipo de dispositivo remoto con el expectativa de que el dispositivo central usará esta información para ajustar la IU y las políticas de enrutamiento de audio. Auricular secundario (solo LE): El auricular secundario debe realizar un anuncio conectable y no detectable con la categoría de apariencia debe configurarse como una categoría de apariencia adecuada que coincida con el tipo de dispositivo remoto con la expectativa de que el el dispositivo central usará esta información para ajustar su IU y políticas de enrutamiento de audio Los auriculares deben elegir dinámicamente a un líder de la CSIP. como el dispositivo principal. Si el auricular está en modo dual, el el dispositivo principal debe ser Dual Mode para garantizar que tanto el modelo de bajo consumo como el clásico funcionen correctamente después de la vinculación.	Esto evita que los auriculares LEA de modo dual aparezcan como duplicados 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 un líder es importante en especial para el modelo de doble modo que se vinculan de forma incremental. Por ejemplo, si solo hay un auricular está disponible en la vinculación inicial, debe presentarse como un modo dual. Cuando un usuario se vincula con el segundo auricular más adelante, solo necesita vincularse con el componente LE, y CSIP se asegurará se agrupan en Android. Se recomienda la dirección de identidad durante la vinculación porque el BR/EDR ya expone la dirección pública del dispositivo a las dispositivos.
Admitir el protocolo de atributos mejorados (EATT)	Reduce la latencia de vinculación y conexión.
Compatibilidad con almacenamiento en caché GATT sólido.	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 aumenta el potencial de la batería. de ahorros en la nube.
Asegúrate de que durante el procesamiento previo y posterior tanto para la reproducción como para captura, la canalización de procesamiento de señales puede operar a 16, 24, 32 y 48 kHz, y admite frecuencias más altas.	Aprovecha las tasas de muestreo más altas admitidas para las llamadas de LEA. de captura de VoIP y 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 Números asignados 6.12.3 a menos que el visor no admita explícitamente un tipo de contexto determinado.	Por ejemplo, si el contexto escribe "Juego" no es compatible, entonces Android enviará sonidos del juego. En particular, ten en cuenta que la columna "Sin especificar" contexto tipo no significa “cualquier tipo de contexto” y no abarca tipos de contextos.
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 LE Audio como transmisión porque podría recurrir a A2DP o HFP. El periférico puede usar la interacción de ASCS para indicar si la instalación usará LE Audio para la transmisión. Algunos ejemplos de interacciones de ASCS son operaciones de lectura, escritura y registro para notificación.