Los dispositivos de audífonos (HA) pueden tener una mejor accesibilidad en dispositivos móviles con Android usando canales L2CAP orientados a la conexión (CoC) a través de Bluetooth de bajo consumo (BLE). El CoC usa 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 auditivos a expensas de la latencia.
El diseño de los CoC hace referencia a la especificación principal de Bluetooth, versión 5 (BT). Para mantener la alineación con las especificaciones principales, todos los valores multibyte de esta página se deben leer como little-endian.
Terminología
- central
- Es el dispositivo Android que analiza los anuncios a través de Bluetooth.
- periférico
- Es el audífono que envía paquetes de anuncios a través de Bluetooth.
Topología de red y arquitectura del sistema
Cuando se usa el CoC para audífonos, la topología de red supone un solo dispositivo central y dos periféricos, uno izquierdo y otro derecho, como se muestra 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, ya sea por un ajuste monoaural o por una pérdida de conexión, el dispositivo central mezcla los canales de audio izquierdo y derecho, y transmite el audio al periférico restante. Si el dispositivo central pierde la conexión con ambos periféricos, considera que se perdió la conexión con el receptor de audio. En esos casos, la unidad central dirige el audio a otra salida.
Figura 1. Topología para vincular audífonos con dispositivos móviles Android a través de CoC por BLE.
Cuando el dispositivo central no transmite datos de audio al periférico y puede mantener una conexión BLE, no debe desconectarse del periférico. Mantener la conexión permite la comunicación de datos con el servidor GATT que reside en el periférico.
Cuando se vinculan y conectan dispositivos auditivos, la unidad central debe hacer lo siguiente:
- Realiza un seguimiento de los periféricos izquierdo y derecho más recientes que se hayan vinculado.
- Se supone que los periféricos están en uso si existe una vinculación válida. El dispositivo central debe intentar conectarse o volver a conectarse con el dispositivo vinculado cuando se pierda la conexión.
- Si se borra una vinculación, se supone que los periféricos ya no están en uso.
En los casos anteriores, vinculación hace referencia a la acción de registrar un conjunto de audífonos con un UUID determinado y designadores de izquierda/derecha en el SO, no al proceso de vinculación por Bluetooth.
Requisitos del sistema
Para implementar correctamente el CoC y brindar una buena experiencia del usuario, los sistemas Bluetooth de los dispositivos central y periférico deben cumplir con los siguientes requisitos:
- Implementa un controlador compatible con BT 4.2 o versiones posteriores. Se recomienda usar LE Secure Connections.
- tener el soporte central con al menos 2 vínculos de LE simultáneos con parámetros como se describe en Formato y sincronización de paquetes de audio
- Tener compatibilidad periférica con al menos 1 vínculo LE con los parámetros descritos en Formato y sincronización de paquetes de audio
- tener un control de flujo basado en créditos de LE [BT Vol 3, Part A, Sec 10.1] Los dispositivos deben admitir un tamaño de MTU y MPS de al menos 167 bytes en CoC y poder 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
-
El dispositivo central debe admitir el comando HCI LE Connection Update y cumplir con los parámetros
maximum_CE_Lengthyminimum_CE_Lengthdistintos de cero. - hacer que el dispositivo 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.
-
El periférico debe establecer los parámetros
MaxRxOctetsyMaxRxTimeen los marcosLL_LENGTH_REQoLL_LENGTH_RSPcomo los valores más pequeños requeridos que son necesarios para estas especificaciones. Esto permite que la unidad central optimice su programador de tiempo cuando calcula la cantidad de tiempo necesario para recibir un fotograma.
Se recomienda que el dispositivo central y el periférico admitan la PHY de 2 MB, como se especifica en la especificación de BT 5.0. La unidad central debe admitir vínculos de audio de al menos 64 kbit/s en las PHY de 1 M y 2 M. No se debe usar la PHY de largo alcance de BLE.
CoC usa los mecanismos estándar de Bluetooth para la encriptación de la capa de vínculo y el salto de frecuencia.
Servicios GATT de ASHA
Un periférico debe implementar el servicio de servidor GATT de transmisión de audio para audífonos (ASHA) que se describe a continuación. El periférico debe anunciar este servicio cuando se encuentre en el modo de detección general para que el dispositivo central reconozca un receptor de audio. Todas las operaciones de transmisión de audio LE deben requerir encriptación. La transmisión de audio por BLE consta de las siguientes características:
| Característica | Propiedades | Descripción |
|---|---|---|
| ReadOnlyProperties | Lectura | Consulta ReadOnlyProperties. |
| AudioControlPoint | Escribir y escribir sin respuesta | Es el punto de control de la transmisión de audio. Consulta AudioControlPoint. |
| AudioStatusPoint | Lectura/Notificación | Es el campo de informe de estado del punto de control de audio. Consulta AudioStatusPoint. |
| Volumen | Escribir sin respuesta | Byte entre -128 y 0 que indica la cantidad de atenuación que se aplicará al audio transmitido, que va de -48 dB a 0 dB. El valor -128 se debe interpretar como completamente silenciado, es decir, el nivel de volumen más bajo que no está silenciado es -127, lo que equivale a una atenuación de -47.625 dB. En el ajuste 0, un tono sinusoidal de riel a riel transmitido debe representar un equivalente de entrada de 100 dBSPL en el audífono. La unidad central debe transmitir a escala completa nominal y usar esta variable para establecer el nivel de presentación deseado en la unidad periférica. |
| LE_PSM_OUT | Lectura | Es el PSM que se usará para conectar el canal de audio. Para ser seleccionada del rango dinámico [BT Vol 3, Part A, Sec 4.22] |
Los UUIDs asignados al servicio y las 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 GATT de ASHA, el dispositivo periférico también debe implementar el servicio de información del dispositivo para permitir que el dispositivo central detecte los nombres del fabricante y los nombres del dispositivo periférico.
ReadOnlyProperties
ReadOnlyProperties tiene los siguientes valores:
| Byte | Descripción |
|---|---|
| 0 | Versión: Debe ser 0x01. |
| 1 | Consulta DeviceCapabilities. |
| 2 a 9 | Consulta HiSyncId. |
| 10 | Consulta FeatureMap. |
| 11-12 | RenderDelay. Es el tiempo, en milisegundos, desde que el periférico recibe un fotograma de audio hasta que renderiza la salida. Estos bytes se pueden usar para retrasar un video y sincronizarlo con el audio. |
| 13-14 | Reservado para uso futuro. Se inicializa en ceros. |
| 15-16 | IDs de códec admitidos Es una máscara de bits de los IDs de códec admitidos. Un 1 en una ubicación de bits corresponde a un códec compatible. Por ejemplo, 0x0002 indica que se admite G.722 a 16 kHz. Todos los demás bits deben establecerse en 0. |
DeviceCapabilities
| Bit | Descripción |
|---|---|
| 0 | Lado del dispositivo (0: izquierdo, 1: derecho) |
| 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 admite CSIS (0: no admitido, 1: admitido). |
| 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 | Es el ID del fabricante. Son los identificadores de empresa que asigna el BTSIG. |
| 2-7 | Es el ID único que identifica el conjunto de audífonos. Este ID debe establecerse en el mismo valor en el periférico izquierdo y el derecho. |
FeatureMap
| Bit | Descripción |
|---|---|
| 0 | Se admite la transmisión de salida de audio de CoC LE (sí/no). |
| 1-7 | Reservado (establecido en 0). |
IDs de códec
Si el bit está configurado, significa que se admite ese códec en particular.
| ID / Número de bit | Códec y frecuencia de muestreo | Tasa de bits requerida | Latencia de fotogramas | Obligatorio en la posición central (C) o periférica (P) |
|---|---|---|---|---|
| 0 | Reservado | Reservado | Reservado | Reservado |
| 1 | G.722 a 16 kHz | 64 kbit/s | Variable | C y P |
|
Los números del 2 al 15 están reservados. El 0 también está reservado. |
||||
AudioControlPoint
Este punto de control no se puede usar cuando el CoC de LE está cerrado. Consulta Cómo iniciar y detener una transmisión de audio para ver la descripción del procedimiento.
| Opcode | Argumentos | Subprocedimiento GATT | Descripción |
|---|---|---|---|
1 «Start» |
|
Escribe con respuesta y espera una notificación de estado adicional a través de la característica AudioStatusPoint. |
Indica al periférico que restablezca el códec y comience la reproducción del fotograma 0. El campo del códec indica el ID del códec que se usará
para esta reproducción.
Por ejemplo, el campo del códec es "1" para G.722 a 16 kHz. El campo de bits del tipo de audio indica los tipos de audio presentes en la transmisión:
El periférico no debe solicitar actualizaciones de conexión antes de que se reciba un opcode de «Stop».
|
2 «Stop» |
Ninguno | Escribe con respuesta y espera una notificación de estado adicional a través de la característica AudioStatusPoint. | Indica al periférico que deje de renderizar audio. Después de esta detención, se debe iniciar una nueva secuencia de configuración de audio para volver a renderizar el audio. |
3 «Status» |
|
Escribir sin respuesta |
Informa al periférico conectado que hay una actualización de estado en el otro periférico. El campo connected indica el tipo de actualización:
|
AudioStatusPoint
Campo de informe de estado para el punto de control de audio
| Opcodes | Descripción |
|---|---|
| 0 | Estado: OK |
| -1 | Comando desconocido |
| -2 | Parámetros no válidos |
Anuncios del servicio GATT de ASHA
El UUID del servicio debe estar en el paquete de anuncio. En el anuncio o en el marco de respuesta de la exploración, los periféricos deben tener datos de servicio:
| Desplazamiento de bytes | Name | Descripción |
|---|---|---|
| 0 | Duración del anuncio | >= 0x09 |
| 1 | Tipo de anuncio | 0x16 (Datos de servicio: UUID de 16 bits) |
| De 2 a 3 | UUID del servicio |
0xFDF0 (little-endian) Nota: Este es un ID temporal. |
| 4 | Versión del protocolo | 0x01 |
| 5 | Capacidad |
|
| 6-9 | HiSyncID truncado | Son los cuatro bytes más significativos del HiSyncId. Estos bytes deben ser la parte más aleatoria del ID. |
Los periféricos deben tener un tipo de datos Complete Local Name 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 debe 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 de ASHA en el mismo tipo de trama (ADV o SCAN RESP), los dos tipos de datos (“Complete Local Name” y “Service Data for ASHA service”) deben aparecer en la misma trama. Esto permite que el escáner del dispositivo móvil obtenga ambos datos en el mismo resultado de análisis.
Durante la vinculación 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 y se vincule a ellos rápidamente.
Cómo sincronizar los 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 hora con un número de secuencia antepuesto a cada paquete de la carga útil de audio. El dispositivo central garantiza que los paquetes de audio que se deben reproducir 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 8 bits de longitud, 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, consulta Formato y sincronización del paquete de audio.
La unidad central ayuda proporcionando activadores a los dispositivos binaurales cuando es posible que se necesite la sincronización. Estos activadores informan a cada periférico sobre el estado de su dispositivo periférico vinculado cada vez que hay una operación que puede afectar la sincronización. Los activadores son los siguientes:
-
Como parte del comando
«Start»de AudioControlPoint, se proporciona el estado de conexión actual del otro lado de los dispositivos binaurales. -
Cada vez que hay una operación de conexión, desconexión o actualización de parámetros de conexión en un periférico, se envía el comando
«Status»de AudioControlPoint al otro lado de los dispositivos binaurales.
Formato y sincronización de paquetes de audio
El empaquetado de tramas de audio (bloques de muestras) en paquetes permite que el instrumento auditivo derive la sincronización de los anclajes de sincronización de la capa de vínculo. Para simplificar la implementación, haz lo siguiente:
- Un fotograma 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, el fotograma de audio debe contener 320 muestras.
- Las frecuencias de muestreo del sistema se restringen a múltiplos de 8 kHz para que siempre haya una cantidad entera de muestras en un fotograma, independientemente del tiempo del fotograma o del intervalo de conexión.
- Se debe anteponer un byte de secuencia a los fotogramas de audio. El byte de secuencia debe contar con un ajuste y permitir que el periférico detecte una discrepancia o un subdesbordamiento del búfer.
-
Un fotograma de audio siempre debe caber en un solo paquete LE. El marco de audio se debe enviar como un paquete L2CAP independiente. El tamaño de la PDU de LL de LE debe ser el siguiente:
tamaño de la carga útil de audio + 1 (contador de secuencia) + 6 (4 para el encabezado de L2CAP y 2 para la 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. Ten en cuenta que el paquete de audio puede fragmentarse por el controlador Bluetooth central. El periférico debe poder recibir más de 2 paquetes de audio fragmentados por evento de conexión.
Para brindar 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 establece 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 "Multiplexer"
Para todos los códecs que admite un periférico, este debe admitir los siguientes parámetros de conexión. Esta es una lista no exhaustiva de las configuraciones que puede implementar la central.
| Códec | Tasa de bits | Intervalo de conexión | Longitud de CE (PHY de 1 M/2 M) | Tamaño de la carga útil de audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 µs | 160 bytes |
Cómo iniciar y detener una transmisión de audio
Antes de iniciar una transmisión de audio, la unidad central consulta los periféricos y establece un códec de denominador común. Luego, la configuración de la transmisión continúa con la siguiente secuencia:
- Se leen PSM y, de forma opcional, RenderDelay. Estos valores pueden almacenarse en caché en el servidor central.
- Se abre el canal L2CAP de CoC: El periférico debe otorgar 8 créditos inicialmente.
- Se emite una actualización de conexión para cambiar el vínculo a los parámetros requeridos para el códec elegido. Es posible que la central realice esta actualización de conexión antes de la conexión del CoC del paso anterior.
- Tanto el host central como el periférico esperan el evento de actualización completa.
-
Reinicia el codificador de audio y restablece el recuento de secuencia de paquetes a 0.
Se emite un comando
«Start»con los parámetros pertinentes en el AudioControlPoint. El dispositivo central espera una notificación de estado correcta del comando«Start»anterior del dispositivo periférico antes de transmitir. Esta espera le da tiempo al periférico para preparar su canalización 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. - El periférico toma el primer paquete de audio de su cola interna (número de secuencia 0) y lo reproduce.
El comando "Detener" emite los problemas centrales para cerrar la reproducción de audio. Después de este comando, el periférico no necesita estar disponible en cada evento de conexión. Para reiniciar la transmisión de audio, sigue la secuencia anterior a partir del paso 5. Cuando el dispositivo central no está transmitiendo audio, debe mantener una conexión LE para los servicios GATT.
El periférico no debe emitir una actualización de conexión al dispositivo central. Para ahorrar energía, el dispositivo central puede emitir una actualización de conexión al dispositivo periférico cuando no esté transmitiendo audio.