LDAC, aptX / HD y SBC (mejorado) en Linux

Personalmente cada vez utilizo más auriculares inalámbricos en lugar de los cableados, a pesar de la innegable pérdida de calidad que les acompaña, en general. Supongo que con los años me he vuelto cómodo (además de viejo, claro).

Como usuario de Linux en escritorio esto ha supuesto un problema, hasta el momento. Lo habitual en este entorno es que solo esté soportado el denostado códec SBC, y además de manera incompleta, artificialmente limitada, dado que SBC puede dar mucho más de sí que esos escasos 328kbps en joint stereo, alimentados por un algoritmo de compresión perceptual bastante simple. Pero no quiero enrollarme, solo recomendar este artículo técnico sobre el audio bluetooth, donde se discuten esta y otras cuestiones relativas a códecs, perfiles, dispositivos, etc.

Audio over Bluetooth: most detailed information about profiles, codecs, and devices

El caso es que ayer me pasé un rato dándole vueltas a estas cosas y me encontré esto tan interesante:

https://github.com/EHfive/pulseaudio-modules-bt

Se trata de una versión alternativa de los módulos bluetooth de PulseAudio que ofrece compatibilidad con los códecs indicados en el título del hilo y, además, una manera sencilla de seleccionar / identificar cuál queremos utilizar en cada momento. Las mejoras también se extienden al cambio, ahora más inmediato, de perfil de A2DP a HFP, necesario cuando se desea utilizar el micro en una videoconferencia, por ejemplo. Lástima que la calidad de sonido, cuando se usa el micrófono BT, sea tan absolutamente lamentable (auris compatibles con FastStream aparte, me refiero a esos que usan un pincho USB que es detectado como un dispositivo de audio).



Estos nuevos módulos permiten además ajustar de manera muy granular los parámetros de funcionamiento del códec SBC, lo que al parecer mejora significativamente la calidad del sonido, poniendo a este códec al nivel o incluso por encima de aptX. Más información en este otro (detallado) artículo:

Bluetooth stack modifications to improve audio quality on headphones without AAC, aptX, or LDAC codecs

Los que no tengáis muchas ganas de ensuciaros las manos con estas historias, podéis comparar cómo suenan SBC, este SBC tuneado y aptX/HD en esta web, y ya si eso decidir si os apetece enredar con esta interesante posibilidad:

Bluetooth A2DP SBC/aptX online encoder

Es posible subir una pista de audio o bien utilizar alguna de las que se facilitan para hacer pruebas, codificarlas usando distintos códecs / parámetros y comparar (escuchar) el resultado final en tiempo real.

Pero volviendo a esos módulos PulseAudio mejorados, su autor también nos ofrece paquetes binarios listos para usar, por si no nos seduce mucho andar compilando cosas.

En el caso de Ubuntu (19.10, 20.04, aunque también hay un repo para 18.04, 18.10 y 19.04), su instalación es tan simple como ejecutar secuencialmente estos 3 comandos en la consola:

sudo add-apt-repository ppa:berglh/pulseaudio-a2dp
sudo apt update
sudo apt install pulseaudio-modules-bt libldac

Probablemente será necesario un pulseaudio -k final para reiniciar el servidor. Francamente, no recuerdo si yo lo tuve que hacer o no.

A partir de ese momento aparecerán nuestros auris BT, con sus distintos perfiles (ojo, que serán o no funcionales dependiente de sus capacidades), en el selector de sonido. Aquí por ejemplo unos Sennheiser HD 4.40 funcionando perfectamente en modo aptX:



Y aquí unos Sony WF-1000X3 (no admiten aptX) usando AAC:



En mi caso al menos, la mejora obtenida con ellos usando aptX o AAC en lugar del códex SBC con sus parámetros estándar es absolutamente notable.

Leí el artículo de ValdikSS hace unos meses, incluso intercambié unos correos electrónicos con el autor para intentar verificar mi teoría de que todos estos codecs no afectan a señales con bitrates más bajos que su bitrate de transimisión real, pero creo que no me entendió el fondo de la cuestión ... .

Incluso le estuve dando vueltas al protocolo A2DP pero no tengo conocimientos suficientes para sacar una conclusión: https://tsquarex.files.wordpress.com/2014/10/a2dp_spec_v12.pdf

Porque Pablo, estas pruebas que comentas que has hecho, ¿han sido partiendo de ficheros FLAC? Si pruebas con un codec que tenga un umbral de transparencia suficientemente bajo, como es Opus a 160kbps, quizás coincidas con lo que yo experimenté. Como comenté alguna vez, si en lugar de dejar en manos del codec de transmisión la calidad de la señal enviando un bitrate muy alto (como FLAC), envías un bitrate bajo pero transparente al oído, creo que se obtienen mejores resultados.
También debo decir que no todos los chipsets de bluetooth parecen ser iguales, y como bien comenta el artículo, algunos introducen modificaciones en la señal a través de DSPs, modificándola sí o sí. Me he topado alguno Pero si nos ceñimos al codec de compresión, y con implementaciones bien hechas, en mi experiencia he probado a enviar FLAC y Opus 160kbps a través de SBC estándar, encontrando diferencias a favor de Opus, que desaparecían al usar cable. En otra prueba, esta vez con Opus 160kbps y aptX y con unos auriculares que admiten tanto bluetooth como cable, no encontré diferencias entre los dos modos de transmisión, que además se pueden comparar de forma casi instantánea, simplemente activando y desactivando el bluetooth del móvil (al desactivarlo, automáticamente pasa a transmitirse por cable casi al instante).

Otra aproximación a esta idea: partiendo de FLAC codifico a Opus 1.3 160kbps (archivo A), lo "descomprimo" a WAV (se tiene que inventar el relleno) y lo vuelvo a comprimir de nuevo a Opus 1.3, esta vez a 320kbps (archivo B) y a LAME 3.99 320 kbps (archivo C), y no encuentro diferencias entre A, B o C. Creo que viene a ser el mismo escenario que planteo más arriba, los 320kbps funcionan aquí como el "ancho de banda de transmisión", y como está por encima del "enviado" (archivo A), éste se mantiene intacto al final del proceso.

Disculpa que las ideas que presento sean un tanto tangenciales a lo que comentas, que se refiere a mejoras en los codecs de transmisión, y que son muy bienvenidas porque está claro que si lo hicieran lo suficientemente bien, yo llevaría FLAC en mi tarjeta SD y me despreocuparía, y los sistemas de streaming y similares que se fueran a transmitir por bluetooth también se vería beneficiados. Por lo que veo estas mejoras solo se aplican a Linux de momento.

Un tema que me apasiona, gracias por compartirlo!

Hola,

Empiezo por el final, disculpa ninguna. Es una cuestión realmente interesante la que planteas.

A ver, yo creo que aquí no tenemos que perder de vista que SBC, aptX (también el HD), AAC, Opus... todos ellos se basan en algoritmos basados en principios psicoacústicos para pasar la tijera sobre la señal original sin que se note mucho. Algunos lo hacen extraordinariamente bien (Opus, OGG, AAC...) y otros pues no tanto, como es el caso de SBC, que está diseñado para ser muy rápido y no introducir apenas latencia. A cambio pasa lo que pasa, como sabemos, que a igual tasa de bits objetivo unos suenan mejor que otros porque son capaces de identificar mejor lo que se "escucha menos" y, tampoco nos olvidemos, reconstruir algo (más) parecido a la señal original en el momento de la descompresión.

Además, esas estrategias de "recorte" de la señal son distintas en cada caso. Eso, en mi opinión, hace complicado poder llegar a la conclusión inequívoca de que por debajo de cierta tasa de bits concreta ya la cosa da igual. Más que nada porque esa tasa de bits determinada representa niveles de calidad perceptual que no son idénticos, ni tampoco pueden medirse de manera precisa, al menos de entrada, en códecs diferentes.

Chordeater escribió:
Porque Pablo, estas pruebas que comentas que has hecho, ¿han sido partiendo de ficheros FLAC? Si pruebas con un codec que tenga un umbral de transparencia suficientemente bajo, como es Opus a 160kbps, quizás coincidas con lo que yo experimenté.

Las pruebas que yo he hecho hasta el momento han sido con OGG / 320 de Spotify, que es lo que casi siempre estoy escuchando. Se supone que SBC sin florituras debería tener una tasa de bits de 328kbps, que está ligeramente por encima... pero lo cierto es que en mi caso he notado una mejora clara tanto cuando uso unos auris con aptX (tasa de bits netamente superior) como con otros que solo soportan AAC, pero no tengo claro si en este caso funcionando a 256 o 320kbps (lo cierto es que el SBC en mi equipo también podría tener una tasa de bits inferior, tampoco lo sé con certeza).

No obstante probaré con archivos de peor calidad. Desde luego lo que dices tiene mucho sentido. Si la señal que emitimos "cabe en el compresor", lógicamente no debería notarse nada. El problema es que, como decía más arriba, lo de caber o no es difícil de medir.

Chordeater escribió:
Como comenté alguna vez, si en lugar de dejar en manos del codec de transmisión la calidad de la señal enviando un bitrate muy alto (como FLAC), envías un bitrate bajo pero transparente al oído, creo que se obtienen mejores resultados.

Es posible, sí. Sería cosa de probar (supongo que tú ya has hecho tus pruebas).

Chordeater escribió:
También debo decir que no todos los chipsets de bluetooth parecen ser iguales, y como bien comenta el artículo, algunos introducen modificaciones en la señal a través de DSPs, modificándola sí o sí.

Yo me he llevado la sorpresa de que mi cutre adaptador BT de Asus resulta que admitía y todo aptX, y eso que ya tenía uno en la cesta de Amazon.

Chordeater escribió:Pero si nos ceñimos al codec de compresión, y con implementaciones bien hechas, en mi experiencia he probado a enviar FLAC y Opus 160kbps a través de SBC estándar, encontrando diferencias a favor de Opus, que desaparecían al usar cable. En otra prueba, esta vez con Opus 160kbps y aptX y con unos auriculares que admiten tanto bluetooth como cable, no encontré diferencias entre los dos modos de transmisión, que además se pueden comparar de forma casi instantánea, simplemente activando y desactivando el bluetooth del móvil (al desactivarlo, automáticamente pasa a transmitirse por cable casi al instante).

Supongo que ese Opus 160Kbps "cabía" de sobra dentro del flujo aptX. Lo que me extraña es lo primero. Es posible que SBC genera más "artefactos" al comprimir un archivo que de entrada tiene más información (como el FLAC), en lugar de otro flujo ya previamente capado en cuanto a ciertos componentes en frecuencia (y quién sabe qué más). Quizás ahí haya que buscar la razón por la que te sonaba mejor el Opus por medio de SBC. T¡ene que ser algo así, dado que tanto el archivo FLAC como el Opus deben ser convertidos previamente a PCM mondo y lirondo antes de recodificarse en SBC.

Chordeater escribió:
Otra aproximación a esta idea: partiendo de FLAC codifico a Opus 1.3 160kbps (archivo A), lo "descomprimo" a WAV (se tiene que inventar el relleno) y lo vuelvo a comprimir de nuevo a Opus 1.3, esta vez a 320kbps (archivo B) y a LAME 3.99 320 kbps (archivo C), y no encuentro diferencias entre A, B o C. Creo que viene a ser el mismo escenario que planteo más arriba, los 320kbps funcionan aquí como el "ancho de banda de transmisión", y como está por encima del "enviado" (archivo A), éste se mantiene intacto al final del proceso.

En ese caso es lógico que no encuentres diferencias entre A y B (A "cabe" en B). Y en el caso de A-C, probablemente también lo es dado que, perceptualmente, MP3 a 320kbps debe ser mejor que Opus a 160Kbps.

Yo creo que la prueba sería:

1) Archivo A > PCM (1)
2) Archivo A > SBC > PCM (2)

Donde archivo A pueden ser FLACs, Opus, MP3, etc.

Y luego comparar PCM (1) y PCM (2) sumando las señales tras invertir una de ellas, espectralmente (Spek o similar) o, mejor, con Audio DiffMaker para obtener una métrica de su grado de similitud.