Los dispositivos auditivos (HA) pueden tener una accesibilidad mejorada en Dispositivos móviles con Android que usan L2CAP orientado a la conexión canales (CoC) a través de Bluetooth de bajo consumo (BLE). El CoC usa un elemento elástico de varios paquetes de audio para mantener un flujo constante de audio, incluso en caso 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 al Bluetooth Core Specification versión 5 (BT). Para mantenerse alineados con las especificaciones principales, todas las arquitecturas los valores en esta página se leerán como small-endian.
Terminología
- Central: el dispositivo Android que busca anuncios por Bluetooth.
- Periférico: El audífono que envía paquetes de anuncios a través de Bluetooth.
Topología de red y arquitectura del sistema
Al usar el CoC para audífonos, la topología de red asume un central y dos periféricos, uno a la izquierda y uno a la derecha, como se ve en Figura 1: El sistema de audio Bluetooth ve como un solo receptor de audio. Si un periférico está debido a un ajuste monoaural o a una pérdida de conexión, el central mezcla el canal de audio izquierdo y derecho y transmite el audio al periférico restante. Si la central pierde conexión con ambas periféricos, la central considera el vínculo con el receptor de audio perdido. En esos casos, la central enruta el audio a otra salida.
de
Figura 1: Topología para vincular audífonos con
Dispositivos móviles Android que usan CoC a través de BLE
Cuando la central no transmite datos de audio al periférico y puede mantienen una conexión BLE, la central no debe desconectarse de la periférico. Mantener la conexión permite la comunicación de datos con el servidor GATT que reside en el periférico.
Cuando se sincronicen y conecten dispositivos auditivos, la central debe:
- Realiza un seguimiento de los periféricos izquierdo y derecho más recientes vinculados.
- Si existe una vinculación válida, supone que los periféricos están en uso. El central intentará conectarse o reconectarse con el servicio de dispositivo cuando se pierde la conexión.
- Si se borra una vinculación, supón que los periféricos ya no están en uso.
En los casos anteriores, la vinculación se refiere a la acción de registrar un conjunto de audífonos con un UUID determinado y en los designadores izquierdo/derecho del SO, no en el proceso de vinculación por Bluetooth.
Requisitos del sistema
Para implementar CoC correctamente y ofrecer una buena experiencia del usuario, el Bluetooth los sistemas de los dispositivos centrales y periféricos deben:
- implementar un controlador compatible con BT 4.2 o superior. Las conexiones de LE Secure son se recomienda.
- tener la asistencia central al menos 2 vínculos de LE simultáneos con parámetros como descritos en Paquete de audio formato y tiempo.
- Debes tener la compatibilidad con periféricos, al menos, 1 vínculo de LE con los parámetros. descritos en Paquete de audio formato y tiempo.
- tienen 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 MTU y MPS de al menos 167 bytes en CoC y poder almacenar en búfer hasta 8 paquetes.
- una extensión de longitud de datos de 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 conexiones de HCI LE
y cumplan con las
maximum_CE_Lengthy los parámetros Parámetrosminimum_CE_Length. - tiene la capacidad central de mantener la capacidad de procesamiento de datos para dos conexiones CoC de LE a dos distintos periféricos con los intervalos de conexión y la carga útil tamaños en Paquete de audio formato y tiempo.
-
hacer que el periférico configure
MaxRxOctetsy ParámetrosMaxRxTimeenLL_LENGTH_REQoLL_LENGTH_RSPpara que sean los valores obligatorios más pequeños necesarios para estas especificaciones. Esto permite que los sistemas Optimizar el programador de tiempo cuando calcula la cantidad de tiempo necesarias para recibir una trama.
Se recomienda que la central y el periférico admitan 2 MB de PHY, ya que en la especificación de BT 5.0. La central deberá admitir enlaces de audio de al menos 64 kbit/s en 1M y 2M PHY. 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ínculos y salto de frecuencia.
Servicios de ASHA GATT
Un periférico debe implementar la transmisión de audio para audífonos GATT descrito a continuación. El periférico debe anuncia este servicio en el modo detectable general para que la reconocen un receptor de audio. Cualquier operación de transmisión de LE Audio deben requerir encriptación. La transmisión de audio BLE consiste en lo siguiente: las siguientes características:
| Característica | Propiedades | Descripción |
|---|---|---|
| Propiedades ReadOnly | Lectura | Consulta ReadOnlyProperties. |
| Punto de control de audio | Escribir y escribir sin respuesta | Punto de control para la reproducción de audio. Consulta AudioControlPoint. |
| Punto de estado de audio | Leer/Notificar | Campo de informe de estado para el 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á la señal de audio transmitida, que oscila entre -48 dB y 0 dB. Parámetro de configuración -128 se debe interpretar como totalmente silenciado, es decir, el volumen más bajo sin silenciar es de -127, lo que equivale a -47.625 dB de atenuación. En el parámetro de configuración 0, un tono sinusoidal de riel a riel debe representar una entrada de 100 dBSPL equivalente en el audífono. La transmisión central se transmitirá en escala completa y usar esta variable para establecer el nivel de presentación deseado en el periférico. |
| LE_PSM_OUT | Lectura | Es el PSM que se usará para conectar el canal de audio. Se puede elegir en rango dinámico [BT Vol 3, Part A, Sec 4.22] |
Los UUID asignados al servicio y las características:
UUID de servicio: {0xFDF0}
| Característica | UUID |
|---|---|
| Propiedades ReadOnly | {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 debe implementar el servicio de información del dispositivo para que la central detecte los nombres de los fabricantes y de los dispositivos del periférico.
Propiedades ReadOnly
ReadOnlyProperties tienen los siguientes valores:
| Byte | Descripción |
|---|---|
| 0 | Versión: debe ser 0x01 |
| 1 | Consulta DeviceCapabilities. |
| 2 a 9 | Consulta HiSyncId. |
| 10 | Consulta Mapa de funciones. |
| 11-12 | RenderDelay. Es el tiempo, en milisegundos, desde que El periférico recibe una trama de audio hasta que el periférico se renderiza. el resultado. Estos bytes se pueden usar para retrasar un video hasta sincronizar con el audio. |
| 13-14 | Reservado para uso futuro. Inicializa en ceros. |
| 15-16 | ID de códecs compatibles. Esta es una máscara de bits de los ID de códecs admitidos. Un 1 en una ubicación de bits corresponde a una códec compatible. Por ejemplo, 0x0002 indica que G.722 a 16 kHz es compatible. Todos los demás bits se deben configurar en 0. |
Funciones del dispositivo
| Broca | Descripción |
|---|---|
| 0 | Lado del dispositivo (0: izquierdo, 1: derecho) |
| 1 | Indica si el dispositivo es independiente y recibe datos mono, o si el El dispositivo es parte de un conjunto (0: monoaural; 1: binaural) |
| 2 | El dispositivo es compatible con el sistema CSIS (0: no compatible, 1: compatible) |
| 3-7 | Reservado (configurado en 0) |
ID de HiSync
Este campo debe ser único para todos los dispositivos binaurales, pero debe ser lo mismo para el conjunto izquierdo y derecho.
| Byte | Descripción |
|---|---|
| 0-1 | Es el ID del fabricante. Es el Empresa Identificadores asignados por BTSIG. |
| 2-7 | Es el ID único que identifica el conjunto de audífonos. Se debe establecer este ID a la misma en el periférico izquierdo y en el derecho. |
Mapa de atributos
| Broca | Descripción |
|---|---|
| 0 | Se admite la transmisión de salida de audio LE CoC (Sí/No). |
| 1-7 | Reservado (configurado en 0) |
ID de códecs
Si el bit está configurado, entonces ese códec en particular es compatible.
| Número de bits | Códec y tasa de muestreo | Tasa de bits requerida | Latencia de fotogramas | Obligatoria en la instalació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 |
|
Se reservaron entre 2 y 15 personas. 0 también está reservado. |
||||
Punto de control de audio
Este punto de control no se puede usar cuando el LE CoC está cerrado. Consulta Iniciar y detener una transmisión de audio para la descripción del procedimiento.
| Código de operación | Argumentos | Subprocedimiento de GATT | Descripción |
|---|---|---|---|
1 «Start» |
|
Escribe con respuesta y espera una notificación de estado adicional mediante AudioStatusPoint. |
Le indica al periférico que restablezca el códec e inicie el
reproducción del fotograma 0. El campo códec indica el ID de códec que se usará.
para esta reproducción.
Por ejemplo, el campo del códec es "1" para G.722 a 16,000 Hz. El campo de bits de tipo de audio indica los tipos de audio presentes en las novedades:
El periférico no debe solicitar actualizaciones de conexión antes de un Se recibió el código de operación «Stop».
|
2 «Stop» |
Ninguno | Escribe con respuesta y espera una notificación de estado adicional mediante AudioStatusPoint. | Indica al periférico que deje de renderizar audio. Un audio nuevo de la secuencia de configuración debe iniciarse luego de esta parada para 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 dispositivo
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: OK |
| -1 | Comando desconocido |
| -2 | Parámetros no permitidos |
Anuncios del servicio ASHA GATT
El UUID de servicio debe estar en la paquete de anuncios. En el anuncio o en el análisis de respuesta, los periféricos deben tener datos de servicio:
| Desplazamiento de bytes | Name | Descripción |
|---|---|---|
| 0 | Longitud del anuncio | >= 0 x 09 |
| 1 | Tipo de anuncio | 0x16 (datos de servicio: UUID de 16 bits) |
| De 2 a 3 | UUID de servicio |
0xFDF0 (little-endian) Nota: Este es un ID temporal. |
| 4 | Versión del protocolo | 0 × 01 |
| 5 | Capacidad |
|
| 6-9 | HiSyncID truncado | 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 nombre local completo. tipo de datos que indica el nombre del audífono. Este nombre usarse en la interfaz de usuario del dispositivo móvil para que el usuario pueda seleccionar el dispositivo correcto. El nombre no debe indicar el lado 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 de la misma tipo de marco (ADV o SCAN RESP), luego los dos tipos de datos ("Complete Local Name") y "Datos de servicio para el servicio ASHA") en el mismo marco. Esto permite que el escáner del dispositivo móvil obtenga ambos con el mismo resultado del análisis.
Durante la vinculación inicial, es importante que los periféricos publicar anuncios a una velocidad suficiente que permita al dispositivo móvil descubrir los periféricos y vincularse con ellos.
Sincroniza los dispositivos periféricos izquierdo y derecho
Para funcionar con Bluetooth en dispositivos móviles Android, dispositivos periféricos son responsables de garantizar la sincronización. La reproducción de los dispositivos periféricos izquierdo y derecho deben sincronizarse tiempo. Ambos dispositivos periféricos deben reproducir muestras de audio desde el al mismo tiempo.
Los dispositivos periféricos pueden sincronizar su tiempo usando una secuencia antepuesto a cada paquete de la carga útil de audio. La base de datos garantiza que los paquetes de audio que deben reproducirse al mismo tiempo de cada periférico tienen el mismo número de secuencia. La secuencia aumenta en uno después de cada paquete de audio. Cada 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 cada tamaño de paquete de audio y tasa de muestreo son fijos. por cada conexión, los dos periféricos pueden deducir la tiempo de juego. Para obtener más información sobre el paquete de audio, consulta Formato del paquete de audio y los tiempos de respuesta.
La central ayuda proporcionando activadores a los dispositivos binaurales cuando la sincronización que tenga que ocurrir. Estos activadores informan a cada periférico del estado de su dispositivo periférico vinculado siempre que haya una operación que puede afectar la sincronización. Los activadores son los siguientes:
-
Como parte del comando
«Start»de AudioControlPoint, el estado de conexión actual del otro lado de la red y dispositivos. -
Cuando haya una conexión, desconexión o
la operación de actualización del parámetro de conexión
en un periférico,
se envía el comando
«Status»de AudioControlPoint a del otro lado de los dispositivos binaurales.
Formato y sincronización del paquete de audio
Empaquetar tramas de audio (bloques de muestras) en paquetes permite que el la sincronización del instrumento se obtiene de los anclajes de sincronización de la capa de vínculo. 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 tasa de muestreo es de 16 kHz, la trama de audio debe contener 320 muestras.
- Las tasas de muestreo en el sistema están restringidas a múltiplos de 8 kHz a tener siempre un número entero de muestras en un fotograma, sin importar la latencia de fotogramas o el intervalo de conexión.
- Un byte de secuencia debe anteponer las tramas de audio. El byte de la secuencia contará con el ajuste y permitirá que el periférico detectar el desajuste o el subdesbordamiento del búfer.
-
Una trama de audio siempre debe caber en un único paquete LE. El audio
debe enviarse como un paquete L2CAP independiente. El tamaño de la LE
Las PDU de LL deben cumplir con lo siguiente:
tamaño de carga útil de audio + 1 (contador de secuencias) + 6 (4 para el encabezado L2CAP y 2 para SDU) - Un evento de conexión siempre debe ser lo suficientemente grande para contener 2 audios paquetes y 2 paquetes vacíos para que una ACK reserve el ancho de banda para retransmisiones. Ten en cuenta que el paquete de audio puede fragmentarse el control 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 algo de flexibilidad a la central, la longitud del paquete G.722 no es especificada. La longitud del paquete G.722 puede cambiar en función de la conexión que establece la central.
El formato de octeto de salida de G.722 hace referencia a la Rec. ITU-T G.722 (9/2012) Sección 1.4.4 "Multiplexador"
Para todos los códecs que admite un periférico, este debe admiten los parámetros de conexión que se indican a continuación. Esta lista no es exhaustiva de configuraciones que la central puede implementar.
| Códec | Tasa de bits | Intervalo de conexión | Longitud CE (1 M/2 M PHY) | Tamaño de la carga útil de audio |
|---|---|---|---|---|
| G.722 a 16 kHz | 64 kbit/s | 20 ms | 5000/3750 us | 160 bytes |
Cómo iniciar y detener una reproducció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. Las novedades configuración, continúa con la siguiente secuencia:
- PSM y, de forma opcional, RenderDelay. Estos valores pueden almacenarse en caché por la central.
- El canal CoC L2CAP está abierto; el periférico debe otorgar 8 créditos al principio.
- Se emite una actualización de conexión para cambiar el vínculo a los parámetros. necesario para el códec elegido. La central puede actualizar la conexión antes de la conexión CoC en el paso anterior.
- Tanto el host central como el periférico esperan la actualización. completar el evento.
-
Reinicia el codificador de audio y restablece el recuento de secuencias de paquetes a 0.
Un comando
«Start»con los parámetros relevantes es emitida en el objeto AudioControlPoint. La central espera una notificación de estado correcta del comando«Start»anterior desde el periférico antes de la transmisión. Esta espera le da 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 todos los eventos de conexión, aunque la configuración la latencia de la réplica puede ser distinta de cero. - El periférico toma el primer paquete de audio de su cola interna. (secuencia número 0) y la reproduce.
La central emite el comando «Stop» para cerrar la reproducción de audio. Después de este comando, no es necesario que el periférico esté disponible en todos los de conexión. Para reiniciar la transmisión de audio, sigue la secuencia anterior, iniciando del paso 5. Cuando la central no es transmitiendo audio, debe mantener una conexión LE para GATT de Google Cloud.
El periférico no debe emitir una actualización de conexión a la central. Para ahorrar energía, la central puede emitir una actualización de conexión a la periférico cuando no está transmitiendo audio.