Antes de leer este artículo, se recomienda familiarizarse con el artículo anterior:
Algunos usuarios de auriculares inalámbricos reportan una baja calidad de sonido y una falta de agudos al utilizar el códec Bluetooth estándar SBC, que es compatible con todos los dispositivos de audio. Una recomendación común para mejorar el sonido es comprar dispositivos y auriculares que soporten los códecs aptX y LDAC. Estos códecs requieren regalías de licencia, por lo que los dispositivos que los soportan son más caros.
Resulta que la baja calidad de SBC se debe a limitaciones artificiales en los pilas Bluetooth y configuraciones de los auriculares, y esta limitación se puede eludir en cualquier dispositivo existente mediante cambios de software en el teléfono inteligente o computadora.
Códec SBC
El códec SBC tiene muchos parámetros diferentes que se acuerdan en la etapa de establecimiento de conexión. Entre ellos:
- Número y tipo de canales: Joint Stereo, Stereo, Dual Channel, Mono;
- Número de bandas de frecuencias: 4 u 8;
- Número de bloques en el paquete: 4, 8, 12, 16;
- Algoritmo de distribución de bits durante la cuantificación: Loudness, SNR;
- Valor máximo y mínimo del pool de bits utilizados durante la cuantificación (bitpool): normalmente, de 2 a 53.
El dispositivo decodificador debe soportar cualquier combinación de estos parámetros. El dispositivo codificador puede no implementar todos.
Las pilas Bluetooth existentes generalmente acuerdan el siguiente perfil: Joint Stereo, 8 bandas, 16 bloques, Loudness, bitpool 2..53. Este perfil codifica audio de 44.1 kHz con una tasa de bits de 328 kbps.
El parámetro bitpool afecta directamente la tasa de bits dentro de un perfil: cuanto más alto sea, mayor será la tasa de bits y, por lo tanto, la calidad.
Sin embargo, el parámetro bitpool no está vinculado a un perfil específico; la influencia en la tasa de bits también se ve afectada significativamente por otros parámetros: tipo de canales, número de bandas de frecuencias, número de bloques. Se puede aumentar la tasa de bits indirectamente, acordando perfiles no estándar, sin alterar el bitpool.
Fórmula para calcular la tasa de bits de SBC
Por ejemplo, el modo Dual Channel codifica los canales por separado, utilizando todo el bitpool para cada uno de los canales. Al obligar al dispositivo a utilizar Dual Channel en lugar de Joint Stereo, obtendremos casi el doble de la tasa de bits con el mismo valor máximo de bitpool: 617 kbps.
En mi opinión, el uso de un valor de bitpool no vinculado al perfil en la etapa de negociación es una deficiencia del estándar A2DP, que ha llevado a una limitación artificial de la calidad SBC. Sería más sensato acordar el bitrate en lugar de bitpool.
Estos valores fijos de Bitpool y Bitrate se originan en una tabla de valores recomendados para su uso en audio de alta calidad. Pero una recomendación no es motivo para restringirse a estos valores.
La especificación A2DP v1.2, vigente desde 2007 hasta 2015, estipula que todos los dispositivos de decodificación deben funcionar correctamente con bitrates de hasta 512 kbps:
El decodificador del SNK deberá soportar todos los posibles valores de bitpool que no superen el bitrate máximo. Este perfil limita el bitrate máximo disponible a 320 kbps para mono, y 512 kbps para modos de dos canales.
En la nueva versión de la especificación no hay limitaciones de bitrate. Se supone que los auriculares modernos, lanzados después de 2015 y que soportan EDR, pueden admitir bitrates de hasta ≈730 kbps.
Por alguna razón, los stacks de Bluetooth de Linux (PulseAudio), Android, Blackberry y macOS que he comprobado tienen limitaciones artificiales en el valor máximo del parámetro bitpool, lo que afecta directamente al bitrate máximo. Pero este no es el mayor problema, casi todos los auriculares también limitan el valor máximo de bitpool a 53.
Como ya he podido comprobar, la mayoría de los dispositivos funcionan perfectamente con un stack de Bluetooth modificado a un bitrate de 551 kbps, sin interrupciones ni ruidos. Pero tal bitrate nunca se acordará en condiciones normales, en stacks de Bluetooth convencionales.
Modificando el stack de Bluetooth
En cualquier stack de Bluetooth que sea compatible con el estándar A2DP, hay soporte para el modo Dual Channel, pero activarlo desde la interfaz no parece posible.
¡Añadamos un interruptor a la interfaz! He hecho parches para Android 8.1 y Android 9 que añaden soporte completo para Dual Channel al stack, añaden el modo al menú de selección de modo en herramientas para desarrolladores, y manejan SBC con soporte para Dual Channel como si fuera un códec adicional, como aptX, AAC o LDAC (Android lo llama HD Audio), añadiendo una casilla en la configuración del dispositivo Bluetooth. Así es como se ve:
Al activar la casilla, el audio Bluetooth comienza a transmitirse a un bitrate de 551 kbps, si los auriculares soportan una conexión a 3 Mbps, o 452 kbit/s, si los auriculares solo soportan 2 mbit/s.
Este parche está incluido en los siguientes firmware alternativos:
- LineageOS
- Resurrection Remix
- crDroid
¿De dónde provienen 551 y 452 kbit/s?
La tecnología de partición de aire en Bluetooth está diseñada para la transmisión eficiente de grandes paquetes de tamaño fijo. La transmisión de datos ocurre en ranuras, siendo la mayor cantidad de ranuras enviadas en una transmisión — 5. También hay modos de transmisión que utilizan 1 o 3 ranuras, pero no 2 o 4. En 5 ranuras se pueden transmitir hasta 679 bytes a una velocidad de conexión de 2 mbit/s y hasta 1021 bytes a una velocidad de 3 mbit/s, y en 3 — 367 y 552 bytes, respectivamente.
Si queremos transmitir menos datos que 679 o 1021 bytes, pero más que 367 o 552 bytes, la transmisión aún ocupará 5 ranuras y los datos se transmitirán en el mismo tiempo, lo que reduce la eficiencia de la transmisión.
SBC en modo Dual Channel, con audio de 44100 Hz con parámetros de Bitpool 38, 16 bloques por marco, 8 rangos de frecuencia, codifica audio en marcos de 164 bytes, con un bitrate de 452 kbit/s.
El audio debe estar encapsulado en los protocolos de transmisión L2CAP y AVDTP, que utilizan 16 bytes de la carga útil de audio.
Así, en una transmisión Bluetooth con 5 ranuras caben 4 marcos de audio:
679 (EDR 2 mbit/s DH5) - 4 (L2CAP) - 12 (AVDTP/RTP) - 1 (encabezado SBC) - (164*4) = 6 Hemos incluido 11.7 ms de datos de audio en el paquete enviado, que se transmitirá en 3.75 ms, y nos quedaron 6 bytes no utilizados en el paquete.
Si se aumenta un poco el bitpool, ya no se podrán empaquetar 4 marcos de audio en un solo paquete. Tendremos que enviar 3 marcos a la vez, lo que reduce la eficiencia de la transmisión, disminuye la cantidad de audio transmitido en un solo paquete y resultará en interrupciones de audio más rápidas bajo malas condiciones de radio.
De la misma manera, se ajustó la tasa de bits a 551 kbit/s para EDR 3 mbit/s: con Bitpool 47, 16 bloques por marco, 8 rangos de frecuencia, se obtiene un tamaño de marco de 200 bytes, con una tasa de bits de 551 kbit/s. En un paquete se pueden incluir 5 marcos o 14.6 ms de música.
El algoritmo para calcular todos los parámetros de SBC es bastante complicado, se puede confundirse fácilmente si se cuenta manualmente, por lo que hice una calculadora interactiva para ayudar a los interesados:
¿Para qué sirve todo esto?
A pesar de la creencia común sobre la calidad de sonido del códec aptX, en algunos archivos puede ofrecer resultados peores que el SBC con la tasa de bits estándar de 328 kbit/s.
El SBC asigna dinámicamente bits de cuantificación a bandas de frecuencia, funcionando según el principio de "de abajo hacia arriba". Si se utiliza toda la tasa de bits en frecuencias bajas y medias, las frecuencias altas se "cortarán" (en su lugar habrá silencio).
aptX cuantifica las bandas de frecuencia con la misma cantidad de bits de forma constante, lo que le da una tasa de bits fija: 352 kbit/s para 44.1 kHz, 384 kbit/s para 48 kHz, y no puede "trasladar bits" a aquellas frecuencias que más los necesitan. A diferencia de SBC, aptX no "cortará" las frecuencias, sino que añadirá ruidos de cuantificación, reduciendo el rango dinámico del audio, y a veces introduciendo crujidos característicos. SBC, en cambio, "se lleva detalles" — desecha las partes más suaves.
En promedio, en comparación con SBC 328k, aptX introduce menos distorsiones en música con un amplio rango de frecuencias, pero en música con un rango de frecuencias estrecho y un amplio rango dinámico, SBC 328k a veces gana.
Consideremos un caso particular. Espectrograma de una grabación de piano:
La energía principal se encuentra en las frecuencias de 0 a 4 kHz, y se extiende hasta 10 kHz.
El espectrograma de un archivo comprimido en aptX se ve de la siguiente manera:
Así es como se ve SBC 328k.
Se puede ver que SBC 328k periódicamente desconectaba completamente el rango por encima de 16 kHz, y utilizaba toda la tasa de bits disponible en los rangos inferiores a este valor. Sin embargo, aptX introdujo más distorsiones en el espectro de frecuencias audible al oído humano, como se puede ver en el espectrograma original resta del espectrograma de aptX (cuanto más brillante, más distorsiones):
Mientras que SBC 328k arruinó menos la señal en el rango de 0 a 10 kHz, el resto fue cortado:
La tasa de bits de 485k de SBC fue suficiente para conservar todo el rango de frecuencias, sin desconectar bandas.
SBC 485k en esta composición supera significativamente a aptX en el rango de 0-15 kHz, y con una diferencia menor, pero aún notable, en 15-22 kHz (cuanto más oscuro, menos distorsiones):
.
Al cambiar a SBC de alta tasa de bits, obtendrás un sonido que a menudo supera a aptX en cualquier par de auriculares. En auriculares que soportan conexión EDR de 3 Mbit/s, una tasa de 551 kbit/s proporciona un sonido comparable al aptX HD.
¿Se puede obtener aún más?
En el parche para Android también hay una opción para aumentar aún más la tasa de bits para dispositivos EDR a 2 Mbps. Se puede aumentar la tasa de bits de 452 kbps a 595 kbps, a costa de disminuir la estabilidad de la transmisión en condiciones de radio difíciles.
Basta con establecer la variable persist.bluetooth.sbc_hd_higher_bitrate en el valor 1:
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1El parche para la tasa de bits extrema ha sido aceptado solo en LineageOS 15.1, pero no en 16.0.
Compatibilidad con dispositivos
SBC Dual Channel es compatible con prácticamente todos los auriculares, altavoces y unidades principales de automóviles. No es sorprendente, ya que el estándar exige su soporte en todos los dispositivos de decodificación. Hay un pequeño número de dispositivos en los que este modo causa problemas, pero son casos aislados.
Para más detalles sobre dispositivos compatibles, puede consultar o .
Comparación de diferencias de sonido
He creado un servicio web que codifica audio en SBC (así como aptX y aptX HD) en tiempo real, directamente en el navegador. Con él, podrá comparar el sonido de varios perfiles SBC y otros códecs, sin transmitir realmente audio por Bluetooth, en cualquier auricular o altavoz por cable, y con su música favorita, y también modificar los parámetros de codificación mientras se reproduce el audio.
Contacto con los desarrolladores de Android
He escrito a muchos desarrolladores del stack Bluetooth de Google, solicitando que consideren incluir parches en la rama principal de Android — AOSP, pero no he recibido ninguna respuesta. Mis parches en también han quedado sin comentarios por parte de alguien involucrado.
Me encantaría si pudiera facilitarme un contacto con los desarrolladores de Google para la implementación de SBC HD en Android. El parche en gerrit ya está desactualizado (es una de las primeras revisiones), y lo actualizaré si a los desarrolladores les interesan mis cambios (no me resulta fácil actualizarlo, no tengo dispositivos compatibles con Android Q).
Conclusión
Los usuarios de smartphones con ROMs LineageOS, Resurrection Remix y crDroid ya pueden disfrutar de una mejor calidad de sonido ahora mismo, solo tienen que activar la opción en la configuración del dispositivo Bluetooth. Los usuarios de Linux también pueden obtener una mayor tasa de bits SBC, instalando , que, además de todo, añade soporte para los códecs aptX, aptX HD y FastStream.
Fuente: habr.com
