Los audífonos (HA) pueden tener una accesibilidad mejorada 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 especificación básica de Bluetooth versión 5 (BT). Para mantenerse alineado con las especificaciones principales, todos los valores de varios bytes 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 publicitarios 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 supone un único central 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 único receptor de audio. Si falta un periférico, debido a un ajuste monoaural o una pérdida de conexión, entonces 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 perdido el enlace con el disipador de audio. 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á:
- Realice un seguimiento 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.
- Supongamos 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 determinado y designadores izquierdo/derecho 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 compatible con BT 4.2 o superior. Se recomienda encarecidamente LE Secure Connections.
- Haga que la central admita al menos 2 enlaces LE simultáneos con parámetros como se describe en Formato y temporización de paquetes de audio .
- Tener el periférico compatible con 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éditos LE [BT Vol 3, Parte A, Sec 10.1]. Los dispositivos admitirán un tamaño de MTU y MPS de al menos 167 bytes en CoC y podrán almacenar en buffer hasta 8 paquetes.
- tener una extensión de longitud de datos LE [BT Vol 6, Part B, Sec 5.1.9] con una carga útil de al menos 167 bytes.
- haga que el dispositivo central admita el comando de actualización de la conexión HCI LE y cumpla con los parámetros
maximum_CE_Lengthyminimum_CE_Lengthdistintos de cero. - haga 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 y sincronización de paquetes de audio .
- haga que el periférico configure los parámetros
MaxRxOctetsyMaxRxTimeen los marcosLL_LENGTH_REQoLL_LENGTH_RSPpara que sean los valores más pequeños requeridos para estas especificaciones. Esto permite a la central optimizar su programador de tiempo al calcular la cantidad de tiempo necesario 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 1 M y 2 M. No se utilizará el 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 deberá 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 requerirá cifrado. La transmisión de audio BLE consta de las siguientes características:
| Característica | Propiedades | Descripción |
|---|---|---|
| Propiedades de sólo lectura | Leer | Consulte Propiedades de sólo lectura . |
| Punto de control de audio | Escribir y escribir sin respuesta | Punto de control para la transmisión de audio. Consulte AudioControlPoint . |
| Punto de estado de audio | Leer/Notificar | Campo de informe de estado para el punto de control de audio. Ver AudioStatusPoint |
| Volumen | Escribir sin respuesta | Byte entre -128 y 0 que indica la cantidad de atenuación que se aplicará a la señal de audio transmitida, que oscila entre -48 dB y 0 dB. El ajuste -128 se interpretará como completamente silenciado, es decir, el nivel de volumen más bajo no silenciado es -127, lo que equivale a una atenuación de -47,625 dB. En la configuración 0, un tono sinusoidal transmitido de riel a riel representará una entrada equivalente a 100 dBSPL en el audífono. La central transmitirá a 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 ser elegido del rango dinámico [BT Vol 3, Parte A, Sec 4.22] |
Los UUID asignados al servicio y características:
UUID de servicio : {0xFDF0}
| Característica | UUID |
|---|---|
| Propiedades de sólo lectura | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| Punto de control de audio | {f0d4de7e-4a88-476c-9d9f-1937b0996cc0} |
| Estado de audio | {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 del dispositivo para permitir que la central detecte los nombres del fabricante y los nombres de los dispositivos del periférico.
Propiedades de sólo lectura
ReadOnlyProperties tiene los siguientes valores:
| Byte | Descripción |
|---|---|
| 0 | Versión: debe ser 0x01 |
| 1 | Consulte Capacidades del dispositivo . |
| 2-9 | Consulte HiSyncId . |
| 10 | Consulte Mapa de funciones . |
| 11-12 | Retraso de renderizado. 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 utilizar para retrasar un vídeo y sincronizarlo con el audio. |
| 13-14 | Reservado para uso futuro. Inicializar a ceros. |
| 15-16 | ID de códec admitidos. Esta es una máscara de bits de los ID de códec compatibles. 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 pondrán a 0. |
Capacidades del dispositivo
| Poco | Descripción |
|---|---|
| 0 | Lado del dispositivo (0: izquierda, 1: derecha) |
| 1 | Indica si el dispositivo es independiente y recibe datos mono, o si el dispositivo forma parte de un conjunto (0: monoaural, 1: binaural) |
| 2 | El dispositivo es compatible con CSIS (0: no compatible, 1: compatible) |
| 3-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 | DNI del fabricante. Son los Identificadores de Empresa asignados por BTSIG. |
| 2-7 | ID único que identifica el conjunto de audífonos. Esta ID debe establecerse en la misma tanto en el periférico izquierdo como en el derecho. |
Mapa de características
| Poco | Descripción |
|---|---|
| 0 | Se admite transmisión de salida de audio LE CoC (Sí/No). |
| 1-7 | Reservado (establecido en 0). |
ID de códec
Si el bit está configurado, entonces 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. | ||||
Punto de control de audio
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 la descripción del procedimiento.
| Código de operación | Argumentos | Subprocedimiento del GATT | Descripción |
|---|---|---|---|
1 «Start» |
| Escriba con respuesta y espere una notificación de estado adicional a través de la función AudioStatusPoint . | Indica al periférico que reinicie el códec e inicie la reproducción del fotograma 0. El campo códec indica el ID del códec que se utilizará para esta reproducción. Por ejemplo, el campo de 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:
El periférico no solicitará actualizaciones de conexión antes de haber recibido un código de operación «Stop» . |
2 «Stop» | Ninguno | Escriba con respuesta y espere una notificación de estado adicional a través de la función AudioStatusPoint . | 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 poder reproducir el audio nuevamente. |
3 «Status» |
| escribir sin respuesta | 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:
|
Punto de estado de audio
Campo de informe de estado para el punto de control de audio
| Códigos de operación | Descripción |
|---|---|
| 0 | Estado correcto |
| -1 | Comando desconocido |
| -2 | Parámetros ilegales |
Anuncios del servicio ASHA GATT
El UUID del servicio debe estar en el paquete de publicidad. Ya sea en el anuncio o en el cuadro de respuesta de escaneo, los periféricos deben tener datos de servicio:
| Desplazamiento de bytes | Nombre | Descripción |
|---|---|---|
| 0 | Longitud del anuncio | >= 0x09 |
| 1 | Tipo de anuncio | 0x16 (Datos de servicio - UUID de 16 bits) |
| 2-3 | UUID de servicio | 0xFDF0 (pequeño endian) Nota: Esta es una identificación temporal. |
| 4 | Versión del protocolo | 0x01 |
| 5 | Capacidad |
|
| 6-9 | HiSyncID truncado | Cuatro bytes menos significativos de HiSyncId . Estos bytes deberían ser la parte más aleatoria del ID. |
Los periféricos deben tener un tipo de datos 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 colocan el nombre y los tipos de datos del servicio ASHA en el mismo tipo de cuadro (ADV o SCAN RESP), entonces los dos tipos de datos ("Nombre local completo" y "Datos de servicio para el servicio ASHA") aparecerán en el mismo cuadro. Esto permite que el escáner del dispositivo móvil obtenga ambos datos en el mismo resultado del 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 descubra 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 los encargados de garantizar que estén sincronizados. La reproducción en los dispositivos periféricos izquierdo y derecho debe sincronizarse en el tiempo. Ambos dispositivos periféricos deben reproducir muestras de audio de la fuente al mismo tiempo.
Los dispositivos periféricos pueden sincronizar su tiempo utilizando un número de secuencia antepuesto a cada paquete de la carga útil de audio. La central garantiza que los paquetes de audio que deben 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 temporización del paquete de audio .
La central ayuda proporcionando activadores a los dispositivos binaurales cuando es posible que sea necesario realizar la sincronización. Estos activadores 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 hay una operación de conexión, desconexión o 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 del paquete de audio
Empaquetar cuadros de audio (bloques de muestras) en paquetes permite que el audífono derive la sincronización a partir de los anclajes de sincronización de la capa de enlace. Para simplificar la implementación:
- Un cuadro 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, entonces 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 un cuadro, independientemente del tiempo del cuadro o del intervalo de conexión.
- Un byte de secuencia antepondrá las tramas de audio. El byte de secuencia deberá contar con envoltura y permitir que el periférico detecte discrepancias en el búfer o desbordamiento insuficiente.
- Una trama de audio siempre cabe en un único paquete LE. La trama de audio se enviará como un paquete L2CAP independiente. 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 las retransmisiones. Tenga en cuenta que el paquete de audio puede ser 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 dar cierta flexibilidad a la central, no se especifica la longitud del paquete G.722. La longitud del paquete G.722 puede variar en función del intervalo de conexión que establezca la central.
El formato de octeto de salida G.722 hace referencia a la Rec. ITU-T G.722 (09/2012) sección 1.4.4 "Multiplexor"
Para todos los códecs que admite un periférico, el periférico deberá admitir los parámetros de conexión siguientes. Esta es una lista no exhaustiva de configuraciones que la central puede implementar.
| Códec | tasa de bits | Intervalo de conexión | Longitud CE (1M/2M 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 una transmisión de audio, la central consulta los periféricos y establece un códec de denominador común. La configuración de la transmisión continúa a través de la siguiente secuencia:
- Se lee PSM y, opcionalmente, RenderDelay. Estos valores pueden ser almacenados en caché por la central.
- Se abre el canal CoC L2CAP: el periférico otorgará 8 créditos inicialmente.
- 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 conexión antes de la conexión CoC en el paso anterior.
- Tanto el host central como el periférico esperan hasta que se complete el evento de actualización.
- 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 AudioControlPoint. La central espera una notificación de estado exitosa del comando previo de«Start»del periférico antes de transmitir. Esta espera le da tiempo al periférico para preparar su proceso 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 pueda ser distinta de cero. - 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 «Stop» para cerrar la transmisión de audio. Después de este comando, no es necesario que el periférico esté disponible en cada evento 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 del GATT.
El periférico no emitirá actualización de conexión a la central. Para ahorrar energía, la central podrá emitir una actualización de conexión al periférico cuando no esté transmitiendo audio.