- La baja calidad de audio del códec SBC estándar no se debe solo a las limitaciones del códec, sino también a restricciones conservadoras en el stack Bluetooth y en la configuración de los audífonos; incluso los dispositivos existentes tienen margen de mejora mediante cambios de software
- Los stacks Bluetooth comunes suelen negociar audio estéreo a 44.1 kHz en 328 kbps, pero al forzar Dual Channel se puede llegar a unos 617 kbps con el mismo bitpool 53
- El parche para Android 8.1 y 9 agrega SBC Dual Channel a la configuración de dispositivos Bluetooth como una opción de HD Audio, y usa 551 kbps para dispositivos EDR de 3 Mb/s y 452 kbps para dispositivos EDR de 2 Mb/s
- Los valores de 551 kbps y 452 kbps se eligieron considerando la eficiencia de transmisión Bluetooth de 5 slots; si se aumenta más el bitpool, baja la cantidad de frames agrupados y crece la posibilidad de cortes en malas condiciones inalámbricas
- Los usuarios de LineageOS, Resurrection Remix y crDroid pueden activar SBC de alto bitrate con una casilla en la configuración, y los usuarios de Linux pueden obtener bitrates SBC más altos y soporte para la familia aptX mediante un parche de PulseAudio
Por qué SBC puede sonar con baja calidad
- Algunos usuarios de audífonos inalámbricos experimentan pérdida de calidad y falta de agudos con el códec SBC, compatible con todos los dispositivos de audio Bluetooth
- Una opción es comprar dispositivos y audífonos compatibles con aptX o LDAC, pero esos códecs requieren costos de licencia que pueden elevar el precio del dispositivo
- La causa principal de la baja calidad de SBC son las restricciones artificiales de los stacks Bluetooth actuales y de la configuración de los audífonos, y los dispositivos existentes pueden evitarlas mediante modificaciones de software
Parámetros de SBC y bitrate
- SBC negocia varios parámetros durante la etapa de configuración de la conexión
- Tipo y cantidad de canales de audio: Joint Stereo, Stereo, Dual Channel, Mono
- Cantidad de bandas de frecuencia: 4 u 8
- Cantidad de bloques de audio por paquete: 4, 8, 12, 16
- Método de asignación de bits de cuantización: Loudness, SNR
- bitpool mínimo y máximo usado para la cuantización: normalmente 2..53
- El decodificador debe soportar todas estas combinaciones de parámetros, pero el codificador puede implementar solo algunas
- Los stacks Bluetooth existentes suelen negociar la combinación Joint Stereo, 8 bands, 16 blocks, Loudness, bitpool 2..53, con la cual el audio estéreo de 44.1 kHz se codifica a 328 kbps
- bitpool es el valor que cambia el bitrate de codificación: cuanto más alto es, mayor es el bitrate y la calidad
- La correspondencia exacta entre el valor de bitpool y el bitrate solo aplica dentro de un perfil específico
- El tipo de canal, la cantidad de bandas de frecuencia y la cantidad de bloques de audio también afectan mucho el bitrate
- A diferencia de Stereo o Joint Stereo, Dual Channel codifica cada canal por separado y usa un bitpool individual para cada canal
- Si se fuerza Dual Channel en lugar de Joint Stereo, el bitrate casi se duplica hasta unos 617 kbps incluso con el mismo bitpool 53
Especificación A2DP y restricciones de los stacks actuales
- La specification v1.2 de A2DP, vigente entre 2007 y 2015, exigía que el decodificador soportara todos los valores de bitpool que no superaran el bitrate máximo
- Este perfil limita el bitrate máximo a 320 kb/s en mono y a 512 kb/s en modos de 2 canales
- La nueva especificación no menciona límites de bitrate
- Se asume que los audífonos modernos con soporte EDR lanzados después de 2015 pueden soportar hasta 730 kbps
- Todos los stacks Bluetooth probados —Linux PulseAudio, Android, Blackberry y macOS— imponen restricciones artificiales al parámetro de bitpool máximo
- Casi todos los audífonos también limitan el valor máximo de bitpool a 53
- Con un stack Bluetooth modificado, la mayoría de los dispositivos funcionó a 551 kbps sin cortes ni ruido, pero los stacks Bluetooth estándar no negocian este bitrate en condiciones normales
Parche para el stack Bluetooth de Android
- Todos los stacks Bluetooth compatibles con A2DP deben soportar el modo Dual Channel, pero no hay una forma para que un usuario común lo fuerce
- Los parches para Android 8.1 y Android 9 agregan Dual Channel al stack y al menú de desarrollador, y lo tratan como una opción de códec HD Audio en la configuración del dispositivo Bluetooth, al igual que aptX, AAC y LDAC
- Enlaces de los parches
- Esta casilla activa o desactiva el modo Dual Channel y usa los siguientes bitrates según el dispositivo
- Dispositivos EDR de 3 Mb/s: 551 kbps
- Dispositivos EDR de 2 Mb/s: 452 kbps
- El conjunto de parches se integró en los siguientes firmwares alternativos
- LineageOS 15.1: desde el 31 de marzo de 2019
- LineageOS 16.0: desde el 13 de mayo de 2019
- Resurrection Remix: desde el 14 de mayo de 2019
- crDroid: desde el 13 de mayo de 2019
Por qué se eligieron 551 kbps y 452 kbps
- La transmisión Bluetooth por división de tiempo está diseñada para enviar paquetes grandes de tamaño fijo de forma eficiente
- La cantidad máxima de slots que se puede enviar en una transmisión es de 5, y aunque existen modos de transmisión de 1 slot y 3 slots, no hay modos de 2 slots ni de 4 slots
- La cantidad de datos que se puede enviar en una transmisión de 5 slots es la siguiente
- Conexión de 2 Mbps: hasta 679 bytes
- Conexión de 3 Mbps: hasta 1021 bytes
- La cantidad máxima de datos en una transmisión de 3 slots es la siguiente
- Conexión de 2 Mbps: 367 bytes
- Conexión de 3 Mbps: 552 bytes
- Si se envían datos mayores que 367 o 552 bytes y menores que 679 o 1021 bytes, igual se necesitan 5 slots, lo que reduce la eficiencia de transmisión
- Al codificar audio de 44.1 kHz con SBC Dual Channel, bitpool 38, 16 blocks y 8 frequency bands, se obtienen frames de audio de 164 bytes y un bitrate de 452 kbps
- El payload de audio debe envolverse con los protocolos de transporte L2CAP y AVDTP, y en ese proceso se descuentan 16 bytes de overhead del payload de audio
- En EDR 2 Mb/s DH5, una transmisión de audio de 5 slots puede contener 4 frames de audio
679 - 4(L2CAP) - 12(AVDTP/RTP) - 1(SBC header) - (164*4) = 6- En el paquete quedan 6 bytes libres
- Un solo paquete contiene hasta 11.7 ms de datos de audio y se transmite en 3.75 ms
- Con aumentar apenas el bitpool, ya no entran 4 frames de audio en una sola transmisión y hay que enviarlos de a 3
- Disminuye la eficiencia de transmisión
- Se reduce la cantidad de audio incluida en un paquete
- Aumenta la posibilidad de cortes de audio en malas condiciones inalámbricas
- 551 kbps para EDR 3 Mb/s se eligió con el mismo principio
- Con bitpool 47, 16 blocks per frame y 8 frequency bands, el tamaño de frame es de 200 bytes
- En una transmisión se pueden agrupar hasta 5 frames, es decir, 14.6 ms de música
- El cálculo de parámetros SBC es complejo y es fácil equivocarse al hacerlo manualmente, por lo que se ofrece una herramienta web de cálculo
Diferencias de calidad de audio entre aptX y SBC
- A diferencia de la creencia común de que aptX siempre es mejor que SBC, en algunos casos aptX puede ofrecer menor calidad de audio que el SBC estándar de 328 kbps
- SBC asigna dinámicamente bits de cuantización a las bandas de frecuencia y reparte bits desde las frecuencias bajas hacia las altas
- Si usa todo el bitrate en frecuencias bajas y medias, las frecuencias altas se recortan o se silencian
- aptX es un códec de bitrate fijo que siempre cuantiza las bandas de frecuencia con la misma cantidad de bits
- 352 kbps a 44.1 kHz
- 384 kbps a 48 kHz
- aptX no puede mover bits hacia las frecuencias que los necesitan; no recorta frecuencias, pero agrega ruido de cuantización, reduce el rango dinámico del audio y a veces puede generar ruido
- SBC, en cambio, descarta las zonas silenciosas; comparado con SBC a 328 kbps, aptX tiene en promedio menos distorsión en música con un rango amplio de frecuencias
- En música con un rango de frecuencias estrecho y un rango dinámico amplio, SBC a 328 kbps a veces puede ser mejor que aptX
- En un ejemplo de grabación de piano, la mayor parte de la energía está entre 0 y 4 kHz y continúa hasta 10 kHz
- SBC a 328 kbps recortó periódicamente por completo el rango por encima de 16 kHz
- aptX introdujo más distorsión en el espectro de frecuencias audible para las personas
- SBC a 328 kbps produjo menos distorsión en el rango de 0 a 10 kHz y recortó el resto de las frecuencias
- SBC a 485 kbps fue suficiente para preservar todo el rango de frecuencias sin recortarlo
- Se ofrecen archivos con el audio original y los archivos codificados con SBC/aptX
- Al usar SBC de alto bitrate, en la mayoría de los casos se puede obtener un sonido mejor que con aptX, y en audífonos compatibles con EDR 3 Mb/s, SBC a 551 kbps suena muy parecido a aptX HD
Opciones de bitrate más alto
- El conjunto de parches de Android incluye una opción adicional para aumentar el bitrate en dispositivos EDR de 2 Mb/s
- Si se establece el valor
persist.bluetooth.sbc_hd_higher_bitrate en 1, el bitrate puede subir de 452 kbps a 595 kbps
- Esta opción puede reducir la estabilidad de transmisión en entornos inalámbricos congestionados
# setprop persist.bluetooth.sbc_hd_higher_bitrate 1
- El parche de bitrate extremo actualmente solo está integrado en LineageOS 15.1 y no está integrado en LineageOS 16.0
Dispositivos compatibles y herramienta de comparación
- SBC Dual Channel es compatible con casi todos los audífonos, parlantes y unidades principales para auto
- Como el estándar exige que todos los dispositivos decodificadores soporten este modo, funciona en la mayoría de los dispositivos
- Hay una pequeña cantidad de dispositivos que presentan problemas en este modo, pero son casos muy raros
- La información sobre dispositivos compatibles puede consultarse en las siguientes comunidades
- También se ofrece un servicio web que codifica audio en tiempo real en SBC, aptX y aptX HD desde el navegador
- btcodecs.valdikss.org.ru/sbc-encoder
- Permite comparar el sonido de varios perfiles SBC y otros códecs en audífonos o parlantes con cable, sin transmitir realmente por Bluetooth
- Los parámetros de codificación pueden modificarse directamente incluso durante la reproducción de audio
Intento de integración en AOSP y cómo usarlo
- Se contactó a los desarrolladores del stack Bluetooth de Google para pedir que incluyeran el parche en AOSP, la rama principal de Android, pero no hubo respuesta
- El parche subido al Gerrit code review system for Android tampoco recibió comentarios de personas relacionadas con el desarrollo de Android
- El conjunto de parches de Gerrit corresponde a una de las revisiones iniciales antiguas, y puede actualizarse si algún desarrollador muestra interés
- Los usuarios de LineageOS, Resurrection Remix y crDroid pueden mejorar la calidad de audio Bluetooth activando la casilla en la configuración del dispositivo Bluetooth
- Los usuarios de Linux pueden instalar el parche de PulseAudio de Pali Rohár para usar bitrates SBC más altos
- Este parche también agrega soporte para los códecs aptX, aptX HD y FastStream
1 comentarios
Opiniones de Hacker News
Esto es excelente: SBC tiene soporte amplio y parece una extensión natural del estándar existente
Personalmente, el problema no es si es SBC o LDAC/AAC, sino que HFP es pésimo. En cuanto se activa el micrófono, se siente como volver a los 90, y sería genial si de verdad pudiéramos tener audio Bluetooth bidireccional bien hecho
O quizá sea AVRCP, pero en cualquier caso suena terrible
Este artículo no trata de Bluetooth en general, sino que profundiza bastante en un bug escondido dentro del stack Bluetooth de Android
Lo que el autor no reconoce en absoluto es que el hardware subyacente es muy diverso. Android funciona sobre muchísimos chipsets Bluetooth, así que aunque el parche parezca funcionar en su hardware, no hay garantía de que haga lo mismo en otros teléfonos Android
También influye lo que el dispositivo esté haciendo en ese momento. Si estás transmitiendo video por Wi‑Fi y enviando audio a audífonos en un chipset compartido BT+Wi‑Fi, el dispositivo tiene que repartir recursos entre el uso de Wi‑Fi y Bluetooth. Por eso, el audio almacenado localmente y el audio en streaming no necesariamente reciben los mismos parámetros de códec
Hay demasiados matices en este tema que el autor no tomó en cuenta, así que hay que leerlo con cuidado
Eso permite usar tasas de bits más altas sin superar el bitpool máximo que imponen Android y el receptor Bluetooth
Aun así, la negociación entre fuente y receptor sigue ocurriendo, y si alguno de los dos no soporta SBC de canal dual, vuelve a una modalidad compatible. Todos los dispositivos que yo mantenía lo soportaban, y algunos altavoces baratos que probé en ese momento no, así que negociaban una sesión con joint stereo
En Windows, Alternative A2DP Driver ofrece esta función. Permite ajustar parámetros de SBC y también usar AAC o aptX
En mi experiencia funcionó bien, y también ayuda a usar LDAC en los Sony XM4. Es tipo versión de prueba, pero el precio es bajo
He notado que en modo de alta calidad el alcance de Bluetooth se reduce, lo cual parece una señal de que realmente cambia el códec o al menos algo, y no es placebo
No tengo ninguna relación con https://www.bluetoothgoodies.com/a2dp/
Normalmente se documenta que el rango audible humano llega hasta 20KHz, aunque algunas personas jóvenes pueden oír frecuencias un poco más altas
Como referencia, en Linux también se puede activar audio SBC de mayor bitrate mediante algo llamado SBC XQ. De forma similar, también se puede usar mSBC para mejorar el audio de headset
Claro, aun así no se acerca en nada a niveles como SBC o aptX
Ojalá Google ya hubiera integrado algo así. Muchos audífonos y otros dispositivos soportan códecs de mejor calidad, pero no son universales, y la mejora del audio bidireccional sigue siendo especialmente insuficiente
También quisiera saber cómo comprobar qué está usando actualmente mi headset
Recuerdo haber usado antes un PulseAudio parcheado que exponía la configuración adecuada, pero luego escuché que “se integró al mainstream” y nunca pude encontrar la configuración ni información sobre el uso real
Ojalá alguien hiciera un perfil de audio Bluetooth que pudiera hacer buffering con mucha anticipación
Por ejemplo, si reproduces una canción de 1 minuto, toda la canción debería cargarse en buffer. Claro, si pausas o cambias el volumen, el buffer tendría que descartarse
Con un buffer largo, el teléfono podría entrar en reposo más seguido para ahorrar energía, y también aguantar mejor una conexión inalámbrica deficiente
Aunque fueran solo 1 o 2MB de RAM, los audífonos tendrían que gastar batería valiosa manteniendo esa RAM activa
Por lo poco que he trabajado con apps de audio, también parece que el soporte a nivel de aplicación sería complicado
Así que esto parece más una función que productos individuales podrían diseñar e incluir, con una opción en la app para que el usuario la active o desactive, que un problema del protocolo
Probé esta función en LineageOS y, sinceramente, era muy buena. Permitía enviar audio de mayor calidad a equipos como un estéreo de auto que no soporta códecs de terceros, y también ayudaba bastante con audífonos
La experiencia de usuario necesita pulirse, pero la función en sí es excelente
Estaría bien poner 2019 en el título. Habla de “todos los stacks Bluetooth actuales”, pero estas cosas ya estaban implementadas desde hace tiempo en PulseAudio y PipeWire
Tengo mis dudas de que Dual Channel a 551kbps dé una calidad perceptiblemente mejor que 328kbps en Joint Stereo. Puede que simplemente esté usando más bits para codificar información redundante
Al menos en la mayoría de la música; podría haber excepciones, como canciones con pistas grabadas deliberadamente distintas entre izquierda y derecha
Como pregunta relacionada, me pregunto si hay alguna forma de mejorar Bluetooth HFP en macOS
En Linux uso el mismo headset con mSBC y la calidad es bastante buena, pero en macOS es totalmente pésimo y cae a calidad de línea telefónica/mono. Me pregunto si ya existe algún hack para hacerlo funcionar bien en Darwin
Antes de ver este artículo, ni siquiera sabía que estaba usando SBC. Lineage 18.1 no muestra esa casilla en la UI aunque conectes un dispositivo compatible con SBC. Magia -