Los dispositivos de 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 dispositivos de audífonos a expensas de la latencia.
El diseño de CoC hace referencia a la versión 5 (BT) de la especificación básica de Bluetooth . 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 usa CoC para audífonos, la topología de la red asume una única 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 solo sumidero de audio. Si falta un periférico, debido a un ajuste monoaural o una pérdida de conexión, entonces el 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 perdida la conexión con el sumidero 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 transmite datos de audio al periférico y puede mantener una conexión BLE, la central no debe desconectarse del periférico. El mantenimiento de la conexión permite la comunicación de datos con el 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.
- 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 izquierdo/derecho en el sistema operativo, no el proceso de emparejamiento de Bluetooth.
Requisitos del sistema
Para implementar adecuadamente 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.
- hacer 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 .
- 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éditos LE [BT Vol 3, Part 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 búfer 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.
- hacer que el dispositivo central admita el comando de actualización de conexión LE de
maximum_CE_Lengthy cumpla con los parámetros de longitud_CE_máxima yminimum_CE_Lengthdistintos de cero. - 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 tamaños de carga útil en formato de paquete de audio y temporización .
- haga que el periférico configure los parámetros
MaxRxOctetsyMaxRxTimeen los marcosLL_LENGTH_REQoLL_LENGTH_RSPpara que sean los valores requeridos más pequeños que son necesarios para estas especificaciones. Esto permite que la central optimice su programador de tiempo al calcular la cantidad de tiempo necesario para recibir un marco.
Se recomienda encarecidamente que la central y el periférico admitan 2 MB 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á 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 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 de detección general para permitir que la central reconozca un sumidero de audio. Cualquier operación de transmisión de audio LE requerirá encriptación. El streaming de audio BLE consta de las siguientes características:
| Característica | Propiedades | Descripción |
|---|---|---|
| Propiedades de solo lectura | Leer | Consulte Propiedades de solo lectura . |
| AudioControlPoint | Escribir y escribir sin respuesta | Punto de control para flujo de audio. Consulte Punto de control de audio . |
| Punto de estado de audio | Leer/Notificar | Campo de informe de estado del punto de control de audio. Los códigos de operación son:
|
| Volumen | Escribir sin respuesta | Byte entre -128 y 0 que indica la cantidad de atenuación que se debe aplicar a la señal de audio transmitida, que va de -48 dB a 0 dB. El ajuste -128 se interpretará como totalmente silenciado, es decir, el nivel de volumen más bajo no silenciado es -127, que equivale a una atenuación de -47,625 dB. En el ajuste 0, un tono sinusoidal de riel a riel transmitido representará un equivalente de entrada de 100 dBSPL en el audífono. El central transmitirá en escala completa nominal y utilizará esta variable para establecer el nivel de presentación deseado en el periférico. |
| LE_PSM_OUT | Leer | PSM para usar para conectar el canal de audio. Para elegir del rango dinámico [BT Vol 3, Part A, Sec 4.22] |
Los UUID asignados al servicio y características:
UUID de servicio : {0xFDF0}
| Característica | UUID |
|---|---|
| Propiedades de solo lectura | {6333651e-c481-4a3e-9169-7c902aad37bb} |
| AudioControlPoint | {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 del dispositivo del periférico.
Propiedades de solo 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 características . |
| 11-12 | RenderDelay. Este es el tiempo, en milisegundos, desde que el periférico recibe un cuadro de audio hasta que el periférico genera la salida. Estos bytes se pueden usar para retrasar un video para sincronizarlo 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 ID de códec admitidos. Una ubicación de 1 en un 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
| Un 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). |
HiSync ID
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 | Identificación única que identifica el conjunto de audífonos. Este ID debe configurarse de la misma manera tanto en el periférico izquierdo como en el derecho. |
Mapa de funciones
| Un 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, 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. | ||||
AudioControlPoint
Este punto de control no se puede utilizar cuando el LE CoC está cerrado. Consulte Inicio y detención de una transmisión de audio para ver la descripción del procedimiento.
| código de operación | Argumentos | Descripción |
|---|---|---|
1 «Start» |
| Indica al periférico que reinicie el códec y comience la reproducción del fotograma 0. El campo de 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 bit de tipo de audio indica los tipos de audio presentes en la secuencia:
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 volver a reproducir el audio. |
3 «Status» |
| 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:
|
Anuncios para el 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 un Datos de servicio:
| Compensación 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 (little-endian) Nota: Esta es una identificación temporal. |
| 4 | Versión del protocolo | 0x01 |
| 5 | Capacidad |
|
| 6-9 | HiSync ID truncado | Cuatro bytes menos significativos de HiSyncId . Estos bytes deben ser la parte más aleatoria de la identificación. |
Los periféricos deben tener un tipo de dato Nombre Local Completo que indique el nombre del audífono. Este nombre se usará en la interfaz de usuario del dispositivo móvil para que el usuario pueda seleccionar el dispositivo correcto. El nombre no deberá 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 marco (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 marco. Esto permite que el escáner de dispositivos móviles 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 los descubra rápidamente y se conecte 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 asegurarse de 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 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 disparadores a los dispositivos binaurales cuando es necesario que ocurra 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 disparadores 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 temporización del paquete de audio
Empaquetar cuadros de audio (bloques de muestras) en paquetes permite que el audífono obtenga la temporización de los anclajes de temporizació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, 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 el intervalo de conexión.
- Un byte de secuencia antepondrá las tramas de audio. El byte de secuencia contará con ajuste y permitirá que el periférico detecte la falta de coincidencia o el desbordamiento 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 controlador Bluetooth de la central puede fragmentar el paquete de audio. 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 cambiar según el 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 debe admitir los parámetros de conexión a continuación. Esta es una lista no exhaustiva de configuraciones que puede implementar la central.
| códec | tasa de bits | Intervalo de conexión | Longitud CE (1M/2M PHY) | Tamaño de la carga útil de audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20ms | 5000/3750 nosotros | 160 bytes |
Iniciar y detener una transmisión de audio
Antes de iniciar un flujo de audio, la central consulta a los periféricos y establece un códec de denominador común. La configuración de la transmisión luego procede a través de la siguiente secuencia:
- PSM y, opcionalmente, se lee 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 necesarios para el códec elegido. La central puede hacer esta actualización de conexión antes que la conexión CoC en el paso anterior.
- Tanto el host central como el periférico esperan el evento de actualización completa.
- Reinicie el codificador de audio y restablezca el conteo de secuencias de paquetes a 0. Se emite un comando de
«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 la transmisión. Esta espera le da tiempo al periférico para preparar su tubería 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 actual de la réplica no sea 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 el flujo 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 GATT.
El periférico no deberá 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.