Soporte para headsets HSP/HFP en Ubuntu y Debian

¡Aviso! A finales de 2022, GNOME, Ubuntu y Debian cambiaron a Pipewire como su servidor de audio predeterminado. PipeWire resuelve muchos de los problemas con el hardware y los códecs de Bluetooth. Incluye una capa de compatibilidad con PulseAudio (pipewire-pulse), permitiendo que las aplicaciones existentes aprovechen las mejoras sin realizar cambios y sin inconvenientes.

Vengo usando pipewire junto con wireplumber session manager desde la versión 0.3.x, por lo que si aún está utilizando pulseaudio y sigue con problemas con bluetooth, la mejor opción es migrarlo. Hay muchas guías en línea, pero esta de Baeldung es IMHO la mejor.

Esto significa que la mayor parte de la información de este artículo es obsoleta, pero lo mantendré solo a fines de referencia.

Hace unos meses me obsequiaron un set de trabajo remoto que incluye unos auriculares bluetooth denominados simplemente “EC717”.

La verdad que me vienen muy bien, pues estaba utilizando el manos libres del celular, y no es lo mismo en calidad ni comodidad.

Sin embargo, encontré imposible hacerlos funcionar en Ubuntu 20.04 y en Debian 10, dos de las plataformas que utilizo habitualmente. En realidad sí funcionan para escuchar música, con el perfil A2DP, pero no funcionan como micrófono para videollamadas, con lo cual pierde bastante el sentido de ser un “set de trabajo remoto”. Al intentar establecer el perfil de a2dp_sink a headset_head_unit, obtengo este error:

W: [pulseaudio] module-bluez5-device.c: Refused to switch profile to headset_head_unit: Not connected

Este problema está documentado ampliamente en un montón de bugs y tickets de pulseaudio en bugs.freedesktop.org (93898, 97316, 73325) y en el nuevo gitlab.freedesktop.org (84, 122, 742, 776, 960)

Básicamente, no hay soporte completo para la variedad de HandSet Profile / Hands Free Profile / HSP&HFP profiles mediante los cuales se coordinan los canales de audio y control en Bluetooth. En realidad lo había, pero cambios en la arquitectura de Bluez y PulseAudio hicieron que desaparezcan. Y esto afecta de forma variada a algunos headset que implementan uno solo de dichos perfiles.

James Bottomley estuvo trabajando en 2017 en la incorporación de soporte para las versiones de pulseaudio 11, 12 y 13, pero lamentablemente esos parches no llegaron a incorporarse a la rama estable de la biblioteca pulseaudio cuando los publicó, y recién fueron incorporados hace pocos días, con lo cual no figuran ni de casualidad en las releases actuales de las distribuciones modernas.

Afortunadamente, él ha segmentado dos ramas de trabajo en las cuales marca prolijamente cuales son los cambios a incorporar para poder hacer andar este tipo de headsets con pulseaudio 12 y pulseaudio 13 , y a partir de ellos pude modificar y compilar dos versiones del paquete pulseaudio-module-bluetooth con soporte para HSP/HFP tanto en Debian como en Ubuntu:

• pulseaudio-module-bluetooth (13.99.1-1ubuntu3.10) con soporte para HFP & HSP para Ubuntu.
• pulseaudio-module-bluetooth (12.2-4+deb10u1) con soporte para HFP & HSP para Debian

Por cierto, y antes de que se quejen, el perfil HSP/HFP según la especificación Bluetooth es monocanal y en 8 khz (Volume 2, Section 6.12, de la especificación Bluetooth Core 2.0), por lo cual la calidad de audio es similar a la de un teléfono de línea (bueno, que en espíritu eso es HSP). En resumen, se escucha feo como en un teléfono analógico. Si quieren escuchar música, establezcan perfil A2DP, pero con ese perfil no es posible utilizar el headset como micrófono. Las versiones más nuevas del parche incorporan soporte para múltiples codecs que mejoran la calidad de audio, pero desde luego estas mejoras sólo están disponibles en hardware más moderno y de mejor calidad.

Por mi parte, también opté por hacer un passthru mediante python3-bluez y sources/sinks virtuales de pulseaudio, un script de unas 600 líneas, de forma tal de dialogar directamente con el headset y pasar el audio como entradas y salidas nuevas en el stack de la biblioteca de sonido, pero la latencia que incorporaba al sonido lo hacía inusable. Los parches de Bottomley, en cambio, funcionan perfecto.

Finalmente, respecto a la calidad del código, si estuvieron trabajando en cuestiones de SCSI, Secure Boot, TPMs y UEFI, hay una muy alta probabilidad de que estén utilizando y se hayan cruzado con código de James. Va mi agradecimiento por todos sus aportes.