Los dispositivos de audífonos (HA) pueden tener una accesibilidad mejorada en dispositivos móviles con Android mediante el uso de 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 de audífonos a costa de la latencia.
El diseño de 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 de varios bytes de esta página se deben leer como formato little-endian.
Terminología
- Central: Es el dispositivo Android que busca anuncios a través de Bluetooth.
- Periféricos: Son los audífonos que envían paquetes de anuncios a través de Bluetooth.
Topología de red y arquitectura del sistema
Cuando se usa CoC para audífonos, la topología de red supone un solo elemento central y dos periféricos, uno a la izquierda y otro a la derecha, como se ve en la Figura 1. El sistema de audio Bluetooth ve los periféricos izquierdo y derecho como un solo destino de audio. Si falta un periférico debido a un ajuste monoaural o a una pérdida de conexión, la unidad central mezcla los canales de audio izquierdo y derecho y transmite el audio al periférico restante. Si la central pierde la conexión con ambos periféricos, considera que se perdió el vínculo con el destino de audio. En esos casos, la unidad central enruta el audio a otra salida.
Figura 1: Topología para vincular audífonos con dispositivos móviles Android mediante CoC por BLE
Cuando la unidad 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 central debe cumplir con los siguientes requisitos:
- Haz un seguimiento de los periféricos izquierdo y derecho más recientes vinculados.
- Supone que los periféricos están en uso si existe una vinculación válida. La unidad central intentará conectarse o volver a conectarse con el dispositivo vinculado cuando se pierda la conexión.
- Supongamos que los periféricos ya no están en uso si se borra una vinculación.
En los casos anteriores, vinculación se refiere a la acción de registrar un conjunto de audífonos con un UUID determinado y designadores izquierdo/derecho en el SO, no al proceso de vinculación Bluetooth.
Requisitos del sistema
Para implementar correctamente el CoC y lograr una buena experiencia del usuario, los sistemas Bluetooth de los dispositivos centrales y periféricos deben cumplir con los siguientes requisitos:
- Implementar un controlador BT 4.2 o superior que cumpla con los requisitos Se recomienda usar las conexiones seguras de LE.
- Tener la compatibilidad central con al menos 2 vínculos LE simultáneos con los parámetros que se describen en Formato y sincronización de paquetes de audio
- tener compatibilidad con el periférico de al menos 1 vínculo LE con los parámetros que se describen 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 el 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 de actualización de conexión LE de HCI y cumplir con los parámetros
maximum_CE_Lengthyminimum_CE_Lengthdistintos de cero. - hacer que la unidad central mantenga el rendimiento de datos para dos conexiones de CoC LE a dos periféricos diferentes con los intervalos de conexión y los tamaños de carga útil en el formato y el tiempo de los paquetes de audio
-
hacer que el periférico establezca los parámetros
MaxRxOctetsyMaxRxTimeen las tramasLL_LENGTH_REQoLL_LENGTH_RSPpara que sean los valores mínimos requeridos necesarios para estas especificaciones Esto permite que la unidad central optimice su programador de tiempo cuando calcula la cantidad de tiempo necesaria para recibir un fotograma.
Se recomienda que el dispositivo central y el periférico admitan 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 Kbps en PHY de 1 M y 2 M. No se debe usar el PHY de largo alcance de BLE.
El 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 esté en modo detectable general para permitir que la unidad central reconozca un destino de audio. Todas las operaciones de transmisión de audio LE requerirán 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 | Write y Write without Response | Punto de control para la transmisión de audio. Consulta AudioControlPoint. |
| AudioStatusPoint | Leer/notificar | Es el campo del informe de estado del punto de control de audio. Consulta AudioStatusPoint. |
| Volumen | Escritura sin respuesta | Es un 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. La configuración de -128 se interpretará como completamente silenciada, es decir, el nivel de volumen más bajo que no está silenciado es -127, que equivale a una atenuación de -47.625 dB. En el parámetro de configuración 0, un tono sinusoidal de riel a riel transmitido debe representar una entrada de 100 dBSPL equivalente en el instrumento auditivo. La unidad central debe transmitir en escala completa nominal y usar esta variable para establecer el nivel de presentación deseado en el periférico. |
| LE_PSM_OUT | Lectura | PSM que se usará para conectar el canal de audio. Se debe elegir del rango dinámico [BT Vol 3, Part A, Sec 4.22]. |
Los UUID asignados al servicio y a 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 periférico también debe implementar el servicio de información del dispositivo para permitir que la unidad central detecte los nombres del fabricante y del dispositivo del 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 una trama de audio hasta que renderiza el resultado. Estos bytes se pueden usar para retrasar un video y sincronizarlo con el audio. |
| 13-14 | Se reserva para uso futuro. Se inicializa en ceros. |
| 15-16 | IDs de códec compatibles Esta es una máscara de bits de los IDs de códecs admitidos. Un 1 en una ubicación de bit corresponde a un codec 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 forma parte de un conjunto (0: monoaural, 1: binaural). |
| 2 | El dispositivo admite CSIS (0: no se admite, 1: se admite) |
| 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 la empresa que asigna BTSIG. |
| 2-7 | Es el ID único que identifica el conjunto de audífonos. Este ID debe establecerse de la misma manera en el periférico izquierdo y 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 bits | Códec y tasa de muestreo | Tasa de bits obligatoria | Latencia de fotogramas | Obligatorio en el centro (C) o en el perímetro (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. 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 obtener la descripción del procedimiento.
| Código de operación | Argumentos | Subprocedimiento de GATT | Descripción |
|---|---|---|---|
1 «Start» |
|
Escribe con una respuesta y espera una notificación de estado adicional a través de la característica AudioStatusPoint. |
Le indica al periférico que restablezca el códec y que inicie la reproducción del fotograma 0. El campo de códec indica el ID de códec que se usará para esta reproducción.
Por ejemplo, el campo de códec es “1” para G.722 a 16 kHz. El campo de bits de 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 haya recibido un opcode «Stop».
|
2 «Stop» |
Ninguno | Escribe con una respuesta y espera una notificación de estado adicional a través de la característica AudioStatusPoint. | Le indica al periférico que deje de renderizar audio. Se debe iniciar una nueva secuencia de configuración de audio después de esta detención para volver a renderizar el audio. |
3 «Status» |
|
Cómo escribir sin responder |
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:
|
AudioStatusPoint
Campo de informe de estado del punto de control de audio
| Códigos de operación | Descripción |
|---|---|
| 0 | Estado: OK |
| -1 | Comando desconocido |
| -2 | Parámetros ilegales |
Anuncios para el servicio GATT de ASHA
El UUID del servicio debe estar en el paquete de anuncios. En el anuncio o en la trama de respuesta de análisis, los periféricos deben tener los siguientes datos de servicio:
| Compensación 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 (endianidad baja) 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 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") deben aparecer en la misma trama. Esto permite que el escáner de dispositivos móviles 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 con 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 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 con un número de secuencia que se agrega a cada paquete de la carga útil de audio. La unidad 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 es 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 y la tasa de muestreo de cada paquete de audio 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 de paquetes de audio.
La unidad central proporciona activadores a los dispositivos binaurales cuando es posible que se deba realizar la sincronización. Estos activadores informan a cada periférico 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, 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 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:
- 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 tasa de muestreo es de 16 kHz, la trama de audio debe contener 320 muestras.
- Las tasas de muestreo en el sistema se limitan a múltiplos de 8 kHz para tener siempre una cantidad de muestras enteras en un fotograma, independientemente del tiempo de fotogramas 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 bucle invertido y permitir que el periférico detecte una discrepancia o un desbordamiento del búfer.
-
Una trama de audio siempre debe caber en un solo paquete LE. La trama de audio se debe enviar como un paquete L2CAP independiente. El tamaño de la PDU LL LE debe ser:
tamaño de la carga útil de audio + 1 (contador de secuencia) + 6 (4 para el encabezado L2CAP, 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 el ancho de banda para las retransmisiones. Ten 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 darle 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 sección 1.4.4 "Multiplexor" de la Rec. ITU-T G.722 (09/2012).
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 1M/2M) | Tamaño de la carga útil de audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5,000/3,750 μ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 lee PSM y, de manera opcional, RenderDelay. La central puede almacenar en caché estos valores.
- 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 necesarios para el códec elegido. La central puede realizar esta actualización de conexión antes de la conexión de CoC en el 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 relevantes en AudioControlPoint. La unidad central espera una notificación de estado correcta del comando«Start»anterior del 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 debería estar disponible en cada evento de conexión, aunque la latencia de la réplica actual 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 la transmisió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, comenzando desde el paso 5. Cuando la unidad central no transmite audio, debe mantener una conexión LE para los servicios de GATT.
El periférico no debe emitir una actualización de conexión a la central. Para ahorrar energía, la unidad central puede emitir una actualización de conexión al periférico cuando no se está transmitiendo audio.