Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Soporte de audio para audífonos mediante Bluetooth LE

Los dispositivos de ayuda auditiva (HA) pueden tener una mejor accesibilidad en dispositivos móviles con Android mediante el uso de canales L2CAP (CoC) orientados a la conexión a través de Bluetooth Low Energy (BLE). CoC utiliza un búfer elástico de varios paquetes de audio para mantener un flujo constante de audio, incluso en presencia de pérdida de paquetes. Este búfer proporciona calidad de audio para audífonos a expensas de la latencia.

El diseño de CoC hace referencia a la versión 5 de la especificación principal de Bluetooth (BT). Para mantenerse alineado con las especificaciones básicas, todos los valores multibyte en esta página se leerán como little-endian.

Terminología

  • Central : el dispositivo Android que busca anuncios a través de Bluetooth.
  • Periférico : el audífono que envía paquetes de publicidad a través de Bluetooth.

Topología de red y arquitectura del sistema

Cuando se utiliza CoC para audífonos, la topología de la red asume una central única y dos periféricos, uno izquierdo y otro derecho, como se ve en la Figura 1 . El sistema de audio Bluetooth ve los periféricos izquierdo y derecho como un solo receptor de audio. Si falta un periférico, debido a un ajuste monoaural o una pérdida de conexión, la central mezcla el canal de audio izquierdo y derecho y transmite el audio al periférico restante. Si la central pierde la conexión con ambos periféricos, entonces la central considera que el enlace al receptor de audio se perdió. En esos casos, la central enruta el audio a otra salida.


Figura 1. Topología para emparejar audífonos con dispositivos móviles Android usando CoC sobre BLE

Cuando la central no está transmitiendo datos de audio al periférico y puede mantener una conexión BLE, la central no debe desconectarse del periférico. Mantener la conexión permite la comunicación de datos al servidor GATT que reside en el periférico.

Al emparejar y conectar dispositivos auditivos, la central deberá:

  • Mantenga un registro de los periféricos izquierdo y derecho emparejados más recientemente.
  • Suponga que los periféricos están en uso si existe un emparejamiento válido. La central intentará conectarse o reconectarse con el dispositivo emparejado cuando se pierda la conexión.
  • Suponga que los periféricos ya no están en uso si se elimina un emparejamiento.

En los casos anteriores, el emparejamiento se refiere a la acción de registrar un conjunto de audífonos con un UUID dado y designadores de izquierda / derecha en el sistema operativo, no al proceso de emparejamiento de Bluetooth.

Requisitos del sistema

Para implementar correctamente CoC para una buena experiencia de usuario, los sistemas Bluetooth en los dispositivos centrales y periféricos deberán:

  • implementar un controlador BT 4.2 o superior compatible. LE Secure Connections es muy recomendable.
  • tener el soporte central al menos 2 enlaces LE simultáneos con parámetros como se describe en Formato y temporización del paquete de audio .
  • que el periférico admita al menos 1 enlace LE con los parámetros descritos en Formato y temporización del paquete de audio .
  • tener un control de flujo basado en crédito LE [BT Vol 3, Parte A, Sec 10.1]. Los dispositivos admitirán un tamaño MTU y MPS de al menos 167 bytes en CoC y podrán almacenar hasta 8 paquetes en búfer.
  • tener una extensión de longitud de datos LE [BT Vol 6, Parte B, Sec 5.1.9] con una carga útil de al menos 167 bytes.
  • contar con el apoyo de dispositivos central de la conexión de HCl LE actualización del sistema y cumplir con los no-cero maximum_CE_Length y minimum_CE_Length parámetros.
  • hacer que la central mantenga el rendimiento de datos para dos conexiones LE CoC a dos periféricos diferentes con los intervalos de conexión y los tamaños de carga útil en formato de paquete de audio y sincronización .
  • MaxRxOctets que el periférico configure los parámetros MaxRxOctets y MaxRxTime en las LL_LENGTH_REQ o LL_LENGTH_RSP para que sean los valores requeridos más pequeños necesarios para estas especificaciones. Esto permite a la central optimizar su programador de tiempo al calcular la cantidad de tiempo necesaria para recibir una trama.

Se recomienda encarecidamente que la central y el periférico admitan 2 MB de PHY como se especifica en la especificación BT 5.0. La central admitirá enlaces de audio de al menos 64 kbit / s en PHY de 1M y 2M. No se utilizará la PHY de largo alcance BLE.

CoC utiliza los mecanismos estándar de Bluetooth para el cifrado de la capa de enlace y el salto de frecuencia.

Servicios de ASHA GATT

Un periférico implementará el servicio de servidor GATT de transmisión de audio para audífonos (ASHA) que se describe a continuación. El periférico anunciará este servicio cuando esté en modo detectable general para permitir que la central reconozca un receptor de audio. Cualquier operación de transmisión de audio LE deberá requerir cifrado. La transmisión de audio BLE consta de las siguientes características:

Característica Propiedades Descripción
ReadOnlyProperties Leer Consulte ReadOnlyProperties .
AudioControlPoint Escribir y escribir sin respuesta Punto de control para flujo de audio. Consulte AudioControlPoint .
AudioStatusPoint Leer / Notificar Campo de informe de estado para el punto de control de audio. Los códigos de operación son:
  • 0 - Estado OK
  • -1 - Comando desconocido
  • -2 - Parámetros ilegales
Volumen Escribe sin respuesta Byte entre -128 y 0 que indica la cantidad de atenuación que se aplicará a la señal de audio transmitida, en un rango de -48 dB a 0 dB. El ajuste -128 se interpretará como totalmente silenciado, es decir, el nivel de volumen no silenciado más bajo es -127, que equivale a una atenuación de -47,625 dB. En el ajuste 0, un tono sinusoidal de carril a carril transmitido representará un equivalente de entrada de 100 dBSPL en el audífono. La central transmitirá en escala nominal completa y utilizará esta variable para establecer el nivel de presentación deseado en el periférico.
LE_PSM_OUT Leer PSM a utilizar para conectar el canal de audio. Para seleccionar del rango dinámico [BT Vol 3, Part A, Sec 4.22]

Los UUID asignados al servicio y características:

UUID del servicio : {0xFDF0}

Característica UUID
ReadOnlyProperties {6333651e-c481-4a3e-9169-7c902aad37bb}
AudioControlPoint {f0d4de7e-4a88-476c-9d9f-1937b0996cc0}
AudioStatus {38663f1a-e711-4cac-b641-326b56404837}
Volumen {00e4ca9e-ab14-41e4-8823-f9e70c7e91df}
LE_PSM_OUT {2d410339-82b6-42aa-b34e-e2e01df8cc1a}

Además del servicio ASHA GATT, el periférico también implementará el Servicio de información de dispositivos para permitir que la central detecte los nombres de los fabricantes y los nombres de los dispositivos del periférico.

ReadOnlyProperties

ReadOnlyProperties tiene los siguientes valores:

Byte Descripción
0 Versión: debe ser 0x01
1 Ver DeviceCapabilities .
2-9 Consulte HiSyncId .
10 Consulte FeatureMap .
11-12 RenderDelay. Este es el tiempo, en milisegundos, desde que el periférico recibe una trama de audio hasta que el periférico genera la salida. Estos bytes se pueden usar para retrasar la sincronización de un video con el audio.
13-14 Reservado para utilización futura. Inicializar a ceros.
15-16 ID de códec compatibles. Esta es una máscara de bits de los ID de códec admitidos. Un 1 en una ubicación de bit corresponde a un códec compatible. Por ejemplo, 0x0002 indica que se admite G.722 a 16 kHz. Todos los demás bits se establecerán en 0.

Capacidades del dispositivo

Poco Descripción
0 Lado del dispositivo (izquierda: 0, derecha: 1).
1 Monoaural (0) / Binaural (1). Indica si el dispositivo es independiente y recibe datos mono, o si el dispositivo es parte de un conjunto.
2-7 Reservado (establecido en 0).

HiSyncID

Este campo debe ser único para todos los dispositivos binaurales, pero debe ser el mismo para el conjunto izquierdo y derecho.

Byte Descripción
0-1 ID del fabricante. Son los identificadores de empresa asignados por BTSIG.
2-7 Identificación única que identifica el audífono. Esta identificación debe configurarse con el mismo valor tanto en el periférico izquierdo como en el derecho.

FeatureMap

Poco Descripción
0 Compatible con transmisión de salida de audio LE CoC (Sí / No).
1-7 Reservado (establecido en 0).

ID de códec

Si el bit está establecido, ese códec en particular es compatible.

ID / número de bit Códec y frecuencia de muestreo Tasa de bits requerida Pedazo de tiempo Obligatorio en central (C) o periférico (P)
0 Reservado Reservado Reservado Reservado
1 G.722 a 16 kHz 64 kbit / s Variable C y P
2-15 están reservados.
0 también está reservado.

AudioControlPoint

Este punto de control no se puede utilizar cuando el LE CoC está cerrado. Consulte Iniciar y detener una transmisión de audio para obtener una descripción del procedimiento.

Código de operación Argumentos Descripción
1 «Start»
  • uint8_t codec
  • uint8_t audiotype
  • int8_t volume
  • int8_t otherstate
Indica al periférico que reinicie el códec e inicie la reproducción del cuadro 0. El campo del códec indica el ID del códec que se utilizará para esta reproducción. Por ejemplo, el campo del códec es "1" para G.722 a 16k Hz.

El campo de bits de tipo de audio indica los tipos de audio presentes en la transmisión:
  • 0 - Desconocido
  • 1 - Tono de llamada
  • 2 - Llamada telefónica
  • 3 - Medios
El campo otherstate indica si el otro lado de los dispositivos binaural está conectado. El valor del campo es 1 cuando el otro dispositivo periférico está conectado; de lo contrario, el valor es 0.

El periférico no solicitará actualizaciones de conexión antes de que se haya recibido un código de operación «Stop» .
2 «Stop» Ninguna Indica al periférico que deje de reproducir audio. Se debe iniciar una nueva secuencia de configuración de audio después de esta parada para reproducir el audio nuevamente.
3 «Status»
  • uint8_t connected
Informa al periférico conectado que hay una actualización de estado en el otro periférico. El campo conectado indica el tipo de actualización:
  • 0 - Otro periférico desconectado
  • 1 - Otro periférico conectado
  • 2 - Se produjo una actualización de parámetro de conexión LE en cualquiera de las conexiones

Anuncios del servicio ASHA GATT

El UUID del servicio debe estar en el paquete de publicidad. En el anuncio o en el marco de respuesta de escaneo, los periféricos deben tener un Datos de servicio:

Desplazamiento de bytes Nombre Descripción
0 AD Longitud > = 0x09
1 Tipo de anuncio 0x16 (datos de servicio: UUID de 16 bits)
2-3 UUID de servicio 0xFDF0 (little-endian)

Nota: esta es una identificación temporal.
4 Versión de protocolo 0x01
5 Capacidad
  • 0 - lado izquierdo (0) o derecho (1)
  • 1 - dispositivos simples (0) o duales (1).
  • 2-7 - reservado. Estos bits deben ser cero.
6-9 HiSyncID truncado Cuatro bytes menos significativos del HiSyncId . Estos bytes deben ser la parte más aleatoria del ID.

Los periféricos deben tener un tipo de datos de Nombre local completo que indique el nombre del audífono. Este nombre se utilizará en la interfaz de usuario del dispositivo móvil para que el usuario pueda seleccionar el dispositivo correcto. El nombre no indicará el canal izquierdo o derecho ya que esta información se proporciona en DeviceCapabilities .

Si los periféricos ponen el nombre y los tipos de datos del servicio ASHA en el mismo tipo de trama (ADV o SCAN RESP), los dos tipos de datos ("Nombre local completo" y "Datos de servicio para el servicio ASHA") aparecerán en el mismo marco. Esto permite que el escáner del dispositivo móvil obtenga ambos datos en el mismo resultado de escaneo.

Durante el emparejamiento inicial, es importante que los periféricos se anuncien a una velocidad lo suficientemente rápida como para permitir que el dispositivo móvil detecte rápidamente los periféricos y se vincule a ellos.

Sincronización de dispositivos periféricos izquierdo y derecho

Para trabajar con Bluetooth en dispositivos móviles Android, los dispositivos periféricos son responsables de garantizar que estén sincronizados. La reproducción en los dispositivos periféricos izquierdo y derecho debe sincronizarse a tiempo. Ambos dispositivos periféricos deben reproducir muestras de audio de la fuente al mismo tiempo.

Los dispositivos periféricos pueden sincronizar su tiempo mediante el uso de un número de secuencia antepuesto a cada paquete de la carga útil de audio. La central garantiza que los paquetes de audio destinados a reproducirse al mismo tiempo en cada periférico tengan el mismo número de secuencia. El número de secuencia aumenta en uno después de cada paquete de audio. Cada número de secuencia tiene una longitud de 8 bits, por lo que los números de secuencia se repetirán después de 256 paquetes de audio. Dado que el tamaño de cada paquete de audio y la frecuencia de muestreo son fijos para cada conexión, los dos periféricos pueden deducir el tiempo de reproducción relativo. Para obtener más información sobre el paquete de audio, consulte Formato y tiempo del paquete de audio .

La central ayuda proporcionando disparadores a los dispositivos binaurales cuando es posible que sea necesario realizar la sincronización. Estos disparadores informan a cada periférico del estado de su dispositivo periférico emparejado siempre que haya una operación que pueda afectar la sincronización. Los desencadenantes son:

  • Como parte del comando «Start» de AudioControlPoint, se proporciona el estado de conexión actual del otro lado de los dispositivos binaurales.
  • Siempre que haya una conexión, desconexión o una operación de actualización de parámetros de conexión en un periférico, el comando «Status» de AudioControlPoint se envía al otro lado de los dispositivos binaurales.

Formato y sincronización de paquetes de audio

El empaquetado de cuadros de audio (bloques de muestras) en paquetes permite al audífono derivar la sincronización de los anclajes de sincronización de la capa de enlace. Para simplificar la implementación:

  • Una trama de audio siempre debe coincidir con el intervalo de conexión en el tiempo. Por ejemplo, si el intervalo de conexión es de 20 ms y la frecuencia de muestreo es de 16 kHz, la trama de audio contendrá 320 muestras.
  • Las frecuencias de muestreo en el sistema están restringidas a múltiplos de 8 kHz para tener siempre un número entero de muestras en una trama, independientemente del tiempo de trama o del intervalo de conexión.
  • Un byte de secuencia debe anteponer las tramas de audio. El byte de secuencia se contará con reinicio y permitirá que el periférico detecte discrepancias o subdesbordamiento del búfer.
  • Una trama de audio siempre debe caber en un solo paquete LE. La trama de audio se enviará como un paquete L2CAP separado. El tamaño de la PDU LE LL será:
    tamaño de carga útil de audio + 1 (contador de secuencia) + 6 (4 para encabezado L2CAP, 2 para SDU)
  • Un evento de conexión siempre debe ser lo suficientemente grande como para contener 2 paquetes de audio y 2 paquetes vacíos para que un ACK reserve ancho de banda para retransmisiones. Tenga en cuenta que el paquete de audio puede estar fragmentado por el controlador Bluetooth de la central. El periférico debe poder recibir más de 2 paquetes de audio fragmentados por evento de conexión.

Para darle a la central algo de flexibilidad, no se especifica la longitud del paquete G.722. La longitud del paquete G.722 puede cambiar según el intervalo de conexión que establece la central.

El formato de octeto de salida G.722 hace referencia a la Rec. UIT-T G.722 (09/2012) sección 1.4.4 "Multiplexor"

Para todos los códecs que admite un periférico, el periférico admitirá los siguientes parámetros de conexión. Esta es una lista no exhaustiva de configuraciones que la central puede implementar.

Códec Bitrate Intervalo de conexión Longitud CE (1 M / 2 M PHY) Tamaño de carga útil de audio
G.722 a 16 kHz 64 kbit / s 20 ms 5000/3750 nosotros 160 bytes

Iniciar y detener una transmisión de audio

Antes de iniciar un flujo de audio, la central consulta los periféricos y establece un códec de denominador común. A continuación, la configuración de la transmisión continúa con la siguiente secuencia:

  1. Se lee PSM y, opcionalmente, RenderDelay. Estos valores pueden ser almacenados en caché por la central.
  2. Se abre el canal CoC L2CAP - el periférico otorgará 8 créditos inicialmente.
  3. Se emite una actualización de conexión para cambiar el enlace a los parámetros requeridos para el códec elegido. La central puede realizar esta actualización de la conexión antes de la conexión CoC en el paso anterior.
  4. Tanto el host central como el periférico esperan el evento de actualización completa.
  5. Reinicie el codificador de audio y restablezca el recuento de secuencia de paquetes a 0. Se emite un comando «Start» con los parámetros relevantes en el AudioControlPoint. La central espera una notificación de estado exitosa del comando anterior de «Start» del periférico antes de transmitir. Esta espera le da tiempo al periférico para preparar su canal de reproducción de audio. Durante la transmisión de audio, la réplica debe estar disponible en cada evento de conexión, aunque la latencia de la réplica actual puede ser distinta de cero.
  6. El periférico toma el primer paquete de audio de su cola interna (número de secuencia 0) y lo reproduce.

La central emite el comando «Detener» para cerrar el flujo de audio. Después de este comando, el periférico no necesita estar disponible en todos los eventos de conexión. Para reiniciar la transmisión de audio, siga la secuencia anterior, comenzando desde el paso 5. Cuando la central no esté transmitiendo audio, aún debe mantener una conexión LE para los servicios GATT.

El periférico no emitirá una actualización de conexión a la central. Para ahorrar energía, la central puede emitir una actualización de conexión al periférico cuando no está transmitiendo audio.