Echar a andar un headset¹ Bluetooth es uno de los mayores dolores de cabeza que se pueden encontrar actualmente en una distribución Linux, como queda demostrado si se echa un vistazo a la cantidad de mensajes en foros solicitando ayuda o al tamaño de la sección dedicada a ello del wiki de Arch Linux². Y ahora yo también puedo decirlo de primera mano ya que lo he sufrido en mis carnes.

Hay que decir que el soporte de Bluetooth en Linux siempre ha sido un poco "magia negra". Si hace poco me quejaba de la escasa documentación de PulseAudio, el caso de la pila de Bluetooth es mucho peor si cabe. Y para ahondar aún más en el problema, una buena parte de poca información que hay por ahí ha quedado desfasada, como le pasa a la página del wiki de Debian sobre Bluetooth.

Así que, para contar esta historia tengo que empezar explicando que el soporte de Bluetooth en Linux se compone de dos partes:

• espacio kernel: en los fuentes del kernel se implementan los drivers de acceso al hardware (a los diferentes chipsets como los de Broadcom o Atheros) y también algunos protocolos de bajo nivel. El kernel exporta una serie de dispositivos hci0, hci1, hci2, ... muy parecidos a los dispositivos eth0, eth1, ... que exportan los dispositivos de red.

• espacio de usuario: el resto de los protocolos de alto nivel, así como las herramientas de configuración y demás las implementa BlueZ.

No voy a contar aquí cómo funciona Bluetooth (para eso está la Wikipedia), pero sí que haré un símil para que se entienda fácilmente. Así como la pila de red está formada por un montón de protocolos, desde protocolos de nivel 1 y 2 que se implementan normalmente en el propio hardware —la tarjeta de red— hasta protocolos de alto nivel como SMTP, HTTP y demás, Bluetooth también está formado por una serie de protocolos unos encima de otros. Al fin y al cabo, Bluetooth no es más que otro tipo de red, sólo que una especialmente diseñada para distancias cortas, y donde el consumo energético es una importante restricción.

En Bluetooth hay una serie de protocolos de bajo nivel —que no nos interesan en esta descripción— y luego están el equivalente a los protocolos de alto nivel —a los SMTP y HTTP de la pila de red— que en Bluetooth se llaman perfiles (profiles), y que son los que permiten que un dispositivo funcione para una tarea u otra. En este artículo mencionaré perfiles como A2DP o HSP, ambos relacionados con el audio (que es lo que nos incumbe aquí), pero hay muchos otros. También quiero señalar que cuando un dispositivo Bluetooth es algo simple como unos cascos o un ratón, estos protocolos se implementan en hardware o firmware, por lo que no son actualizables y en concreto los perfiles estarán limitados a lo que venga de fábrica.

En cambio cuando tenemos un aparato complejo, como un ordenador o un smartphone, uno se puede permitir implementar una parte de la pila de Bluetooth en software en vez de en hardware, y esta parte normalmente son los perfiles (o sea, los protocolos de alto nivel). Esa es la parte de la que esencialmente se encarga BlueZ, por sí mismo o con ayuda de otras partes del sistema operativo.

En el caso de unos auriculares o un micrófono Bluetooth —o ambos como es el caso de un headset— BlueZ colabora con el subsistema de sonido (ALSA, PulseAudio, ...) para traernos audio hasta nuestras orejas (o llevar nuestra voz).

Bluez 5 y PulseAudio 5.0 y 6.0

Cuando en Navidades de 2012 salió BlueZ 5 se produjeron un par de cambios relevantes en este software. El primero fue que BlueZ 5 eliminó el soporte para ALSA y empezó a utilizar exclusivamente PulseAudio como subsistema al que derivar las tareas de audio. Los usuarios de BlueZ que hasta ese momento habían usado ALSA no tenían más remedio que migrar a PulseAudio o quedarse anclados en BlueZ 4. Por otro lado, en BlueZ 5 los perfiles HSP (para headsets) y HFP (para manos libres telefónicos), que hasta ese momento se implementaban internamente fueron eliminados en favor de una implementación externa (concretamente por el demonio de PulseAudio uno y el software telefónico oFono el otro):

Remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice (e.g. oFono which already supports this)

Por si fueran pocos cambios, BlueZ 5 introdujo el uso de una nueva herramienta de configuración, bluetoothctl, en vez de la variada colección que había que usar en las versiones previas. Toda la documentación que había hasta el momento en foros y wikis para configurar BlueZ quedó obsoleta de un plumazo³. Es lo que le pasa a la mencionada página de Debian, por ejemplo.

Al mover BlueZ parte de su funcionalidad a PulseAudio, había que actualizar también éste. Pero hasta Marzo de 2014 no aparece la primera versión de PulseAudio con soporte para BlueZ 5, la 5.0, que sólo trae soporte para el perfil A2DP:

PulseAudio now supports BlueZ 5, but only the A2DP profile, which means that in case of headsets, only playback is available, the headset microphone can't be used. BlueZ 4 is still the only way to make the headset and hands-free profiles work.

No es hasta PulseAudio 6.0 aparecida en Febrero de 2015 que no se añade soporte para los perfiles HSP y HFP (y éste último exclusivamente mediante oFono). Esto significa que si usas la combinación BlueZ 5 junto con PulseAudio 5.0 sólo tienes soporte para la parte de auriculares de tu headset y no para el micrófono, mientras que si usas BlueZ 5 junto con PulseAudio 6.0 tienes —o deberías tener— soporte para ambos.

Me diréis que no tiene sentido usar PulseAudio 5.0 teniendo la versión 6.0 disponible, pero es que Debian Jessie lleva PulseAudio 5.0, ya que cuando apareció la versión 6.0 de PulseAudio la distribución estaba en un estado de freeze profundo y ya no se podía actualizar el paquete. Debian Stretch, la actual testing, sí que lleva PulseAudio 6.0, aunque ya veremos que eso no significa que se terminen los problemas.

Configurando el kernel para Bluetooth

Ahora que ya hemos visto el panorama general es hora que pasemos a la parte práctica y a los detalles sucios. Para los que no se quieren manchar las manos hay asistentes gráficos tipo Blueman o Bluedevil, aunque ya os adelanto que si hay problemas no os van a servir para solucionarlos si no entendéis lo que está pasando por debajo.

Lo primero que tuve que hacer en mi caso es compilar un kernel con soporte para Bluetooth. Los que uséis los kernels estándar de vuestra distribución es de suponer que ya vienen con todo compilado, incluso con aquello que nunca usaréis.

El soporte para BNEP es para hacer tethering, así que no lo he incluído. El HIDP sí, por si alguna vez uso un teclado o ratón Bluetooth (en realidad es para enlazar con la parte de dispositivos de entrada HID). Le he puesto además soporte para LE porque mi dongle soporta Bluetooth 4.0.

La opción Bluetooth device drivers da acceso al submenú donde escoger qué drivers (módulos) incluir:

Los dongles USB para equipos de sobremesa y los integrados en los laptops suelen utilizar el módulo btusb, que es el HCI USB driver en este caso, pero algunos portátiles usan otros módulos dependiendo el hardware que lleven. En mi caso comprobé qué hardware tenía, y si tenía soporte, consultando los datos USB del dongle:

$ lsusb
...
Bus 003 Device 001: ID 0a5c:21e8 Broadcom Corp. BCM20702A0 Bluetooth 4.0
...

Con el VendorID:ProdID (0a5c:21e8) me fue fácil encontrar que se había añadido soporte para este dispositivo en el módulo de btusb desde el kernel 3.4 ⁴. Pero resulta que en mi fichero drivers/bluetooth/btusb.c del kernel 4.0.5 no encontraba los números en cuestión. No fue hasta que encontré este commit (github) que me dí cuenta de lo que había pasado: para no tener que añadir cada ProdID nuevo a la tabla de identificadores a partir de ese cambio todos los dispositivos Broadcom (VendorID=0a5c) se tratan como uno solo.

El nuevo kernel con el soporte de Bluetooth compilado y el driver btusb se veía así en dmsg tras arrancar el sistema operativo:

[   39.005283] Bluetooth: Core ver 2.20
[   39.005293] NET: Registered protocol family 31
[   39.005295] Bluetooth: HCI device and connection manager initialized
[   39.005297] Bluetooth: HCI socket layer initialized
[   39.005299] Bluetooth: L2CAP socket layer initialized
[   39.005303] Bluetooth: SCO socket layer initialized

Y enchufando el USB dongle:

[ 2996.695737] usb 3-1: new full-speed USB device number 2 using xhci_hcd
[ 2996.826020] usb 3-1: New USB device found, idVendor=0a5c, idProduct=21e8
[ 2996.826026] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2996.826029] usb 3-1: Product: BCM20702A0
[ 2996.826031] usb 3-1: Manufacturer: Broadcom Corp
[ 2996.826033] usb 3-1: SerialNumber: ------------
[ 2996.869091] usbcore: registered new interface driver btusb
[ 2996.869309] bluetooth hci0: Direct firmware load for brcm/BCM20702A0-0a5c-21e8.hcd failed with error -2
[ 2996.869313] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e8.hcd not found

Las dos últimas líneas me preocupaban, así que estuve investigando y llegué al siguiente commit "btusb: Add Broadcom patch RAM support" (github):

After hardware reset, some BCM Bluetooth adapters obtain their initial firmware from OTPROM chip. Once this initial firmware is running, the firmware can be further upgraded over HCI interface with .hcd files provided by Broadcom. This is also known as "patch RAM" support. This change implements that.

If the .hcd file is not found in /lib/firmware, BCM Bluetooth adapter continues to operate with the initial firmware.

Antes he dicho que los dispositivos de capacidad reducida (como es el caso de este dongle) tienden a implementar Bluetooth en hardware o firmware, por lo que luego no se pueden actualizar. Parece que Broadcom ha intentado superar esta limitación haciendo que el driver que lo controla le mande al dispositivo una versión más moderna del firmware cuando lo inicializa. Esos firmwares más modernos son proporcionados por el fabricante en forma de ficheros (en el caso de Broadcom con extensión .hcd) para que el driver los lea y envíe.

El fichero de firmware que buscaba el driver para mi hardware (brcm/BCM20702A0-0a5c-21e8.hcd) no aparecía ni en el paquete firmware-linux-free (esperable dada la actitud de Broadcom hacia el software libre) ni en el más general repositorio git de firmwares en kernel.org (menos esperable) que contiene firmwares no libres pero sí con permiso de distribución. Tampoco aparecía ninguna referencia a drivers para Linux en el CD que viene con el dongle.

Lo que era más preocupante: buscando por ese nombre de fichero en la Web, encontré que se necesitaba el firmware de marras para hacer funcionar los perfiles HSP y HFP. Pero como en ese momento estaba en Debian Jessie con PulseAudio 5.0 (que ya he dicho que carece de soporte para estos perfiles) me dije que de momento podía probar a ver si funcionaba sin el fichero de firmware. Aunque este otro comentario en la lista de correo de linux-bluetooth:

Anyhow, one minor thing that bugs me is this:

[193452.790194] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e8.hcd not found

While I want the firmware loading available for all Broadcom controllers, I do think we might have to mark some of them as firmware absolutely required since otherwise they will not work. And in that case we should print the error. Otherwise we might just silently not print anything. Thoughts?

parecía dar a entender que en el caso de mi dongle el firmware era imprescindible para que funcionara correctamente. De hecho, lo que en ese hilo se sugiere es implementar que, en los casos en que se sabe positivamente que el firmware es necesario, si no se encuentra el fichero correspondiente el driver emita un error y no inicialice el dispositivo. Pero desde que se había escrito ese mensaje (8 de mayo de 2014) no se había hecho nada en esa línea, y el driver seguía simplemente emitiendo un aviso cuando no encontraba el fichero de firmware (como en mi caso).

A pesar de los malos augurios, me lancé primero a intentar hacer funcionar el headset sin firmwares binarios propietarios opacos.

Configurando Bluetooth en el espacio de usuario

Tener el kernel con el driver cargado es sólo la mitad del trabajo. Ahora es cuando BlueZ, la parte de espacio de usuario, entra en escena. Lo primero es instalarlo, e instalar también el módulo de integración con PulseAudio:

# aptitude install bluez pulseaudio-module-bluetooth
Se instalarán los siguiente paquetes NUEVOS:     
  bluez libsbc1{a} pulseaudio-module-bluetooth

La versión de BlueZ que lleva Debian Jessie es la 5.23, que es la misma que de momento lleva Stretch, aunque en el instante que escribo esto la versión más reciente de upstream es la 5.31.

La parte fundamental de BlueZ es bluetoothd, un demonio del sistema que es el que se encarga de gestionar los interfaces Bluetooth existentes, y de hablar con los dispositivos que se pongan dentro de su alcance para presentarlos a otros servicios según qué perfiles soporten⁵. Por ejemplo, en mi caso quiero que si un dispositivo Bluetooth —mi headset— entra en el alcance de mi dongle, bluetoothd interrogue al headset para descubrir que soporta los perfiles A2DP y/o HSP, y a partir de ello informe a PulseAudio que hay disponibles dos nuevos dispositivos: los auriculares a los que enviar audio y el micrófono del que recibirlo.

Por lo tanto es obvio que si queremos que los dispositivos Bluetooth funcionen, debemos asegurarnos que bluetoothd esté ejecutándose de contínuo. En Debian, el demonio lo tiene que haber arrancado el sistema de init que uséis (System V o systemd), y el servicio debe estar en marcha. Por ejemplo, en systemd:

# systemctl status bluetooth.service 
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled)
   Active: active (running) since mar 2015-05-30 18:43:12 CEST; 36min ago
     Docs: man:bluetoothd(8)
 Main PID: 3731 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─3731 /usr/lib/bluetooth/bluetoothd

may 30 18:43:12 ******** bluetoothd[3731]: Bluetooth daemon 5.23
may 30 18:43:12 ******** bluetoothd[3731]: Starting SDP server
may 30 18:43:12 ******** bluetoothd[3731]: kernel lacks bnep-protocol support
may 30 18:43:12 ******** bluetoothd[3731]: System does not support network plugin
may 30 18:43:12 ******** bluetoothd[3731]: Failed to open RFKILL control device
may 30 18:43:12 ******** bluetoothd[3731]: Bluetooth management interface 1.9 initialized

Si usáis System V init los mensajes de log estarán en /var/log/daemon.log. Dos aclaraciones con respecto a lo que pueden parecer errores:

1. Recordad que quité el soporte de BNEP de la configuración de mi kernel (por eso tampoco tengo soporte del plugin de network)
2. Un dongle enchufado a un USB evidentemente no tiene botones para encender/apagar el Bluetooth como existen en los portátiles. Por eso no hay un dispositivo RFKILL que abrir (vamos, que no es un error).

Es hora de conectar el dongle a un puerto USB y ver qué pasa:

bluetoothd[3731]: Sap driver initialization failed.
bluetoothd[3731]: sap-server: Operation not permitted (1)

Olvidad de momento estos errores que aparecen en los logs (más adelante explicaré por qué aparecen y cómo quitarlos) y centrémonos en ver si el dispositivo Bluetooth está en marcha. Para ello usaremos una herramienta de bajo nivel de las que vienen con BlueZ: hciconfig. Esta herramienta es el equivalente a ifconfig pero para dispositivos HCI Bluetooth:

$ hciconfig
hci0:   Type: BR/EDR  Bus: USB
    BD Address: XX:XX:XX:XX:XX:XX  ACL MTU: 1021:8  SCO MTU: 64:1
    UP RUNNING 
    RX bytes:1504 acl:0 sco:0 events:180 errors:0
    TX bytes:29730 acl:0 sco:0 commands:179 errors:0

Como podéis observar, ahora tengo un dispositivo hci0, así que el dongle ha sido reconocido por el kernel y está funcionando. El dongle tiene una dirección de red única similar a la de las tarjetas de red Ethernet⁶ que yo he preferido ocultar, por lo que aparece como XX:XX:XX:XX:XX:XX.

Aunque hemos usado hciconfig para ver que el dispositivo está ahí, no lo vamos a emplear para configurarlo como se hacía antiguamente. En BlueZ 5 es el demonio bluetoothd el que controla los dispositivos HCI (hci0, hci1, etc). Los usuarios le dan órdenes a bluetoothd mediante la herramienta bluetoothctl y éste hace lo que haga falta con el dispositivo en cuestión, almacenando el estado si fuera necesario:

$ bluetoothctl
[NEW] Controller XX:XX:XX:XX:XX:XX ******** [default]
[bluetooth]#

El prompt de bluetoothctl está esperando comandos que pasarle a bluetoothd. help os dará una lista de los comandos disponibles. Por ejemplo, si hciconfig hubiera mostrado el dispositivo como DOWN en vez de UP RUNNING, podríamos ordenar levantarlo con un power on. En mi caso ya está levantado, así que no es necesario a pesar de lo que diga el Arch Wiki. Los siguientes comandos de esa lista en cambio sí son necesarios, aunque es suficiente con ejecutarlos una única vez (la primera), ya que bluetoothd guarda su estado y los recordará:

[bluetooth]# agent on
Agent registered
[bluetooth]# default-agent
Default agent request successful

Ahora el dongle está listo, pero todavía no está buscando activamente a otros dispositivos Bluetooth que pueda haber en su radio de alcance. Estar activo significa gastar energía, y en Bluetooth el ahorro de energía es una prioridad. Así que debemos decirle explícitamente al dispositivo HCI que active la búsqueda de otros dispositivos Bluetooth:

bluetooth]# scan on
Discovery started
[CHG] Controller XX:XX:XX:XX:XX:XX Discovering: yes
[bluetooth]#

En este momento enciendo el headset y espero hasta que me reconoce el nuevo dispositivo a través de la conexión Bluetooth (paciencia, le cuesta un poco). Cuando aparece:

[NEW] Device YY:YY:YY:YY:YY:YY Energy BT5+
[bluetooth]#

es que el dongle ha encontrado un nuevo dispositivo —el headset—, y además nos dice la dirección de red de éste (que yo he ocultado bajo YY:YY:YY:YY:YY:YY).

Por motivos de seguridad, no es buena idea permitir que cualquier dispositivo sin identificar establezca una conexión sin más con nuestro sistema. Imaginaos el cachondeo que sería que cualquiera con un teclado Bluetooth pudiera conectarlo a nuestro ordenador desde la habitación de al lado y teclear lo que le diera la gana como si fuéramos nosotros⁷. El usuario tiene de alguna forma que dar el visto bueno al dispositivo remoto que se quiere conectar, y esto se hace mediante el emparejado (pair) de los dos dispositivos:

[bluetooth]# pair YY:YY:YY:YY:YY:YY
Attempting to pair with YY:YY:YY:YY:YY:YY
[CHG] Device YY:YY:YY:YY:YY:YY Connected: yes
[CHG] Device YY:YY:YY:YY:YY:YY UUIDs:
    00001108-0000-1000-8000-00805f9b34fb
    0000110b-0000-1000-8000-00805f9b34fb
    0000110c-0000-1000-8000-00805f9b34fb
    0000110e-0000-1000-8000-00805f9b34fb
    0000111e-0000-1000-8000-00805f9b34fb
    00001200-0000-1000-8000-00805f9b34fb
[CHG] Device YY:YY:YY:YY:YY:YY Paired: yes
Pairing successful
[CHG] Device YY:YY:YY:YY:YY:YY Connected: no

El emparejado ha funcionado, aunque luego el dispositivo se ha desconectado (puede ser simplemente por el ahorro de energía).

Como no queremos estar emparejando manualmente el headset cada vez que lo encendamos, le vamos a indicar a bluetoothd que en adelante cuando vuelva a encontrar al dispositivo YY:YY:YY:YY:YY:YY se fíe de él y haga el pair automáticamente sin que nosotros le digamos nada. Esto se consigue mediante el comando trust:

bluetooth]# trust YY:YY:YY:YY:YY:YY
[CHG] Device YY:YY:YY:YY:YY:YY Trusted: yes
Changing YY:YY:YY:YY:YY:YY trust succeeded

Estoy diciendo que bluetoothd guarda toda esta información, pero es mejor que lo veáis por vosotros mismos: está en /var/lib/bluetooth/ (acceso como root). Por cierto, si por cualquier causa queréis purgar el paquete bluez para empezar desde cero, tendréis que borrar manualmente el contenido de ese directorio porque el paquete Debian no lo hace cuando se desinstala (Bug #511608).

Ahora es cuando finalmente conectamos con el headset:

[bluetooth]# connect YY:YY:YY:YY:YY:YY
Attempting to connect to YY:YY:YY:YY:YY:YY
Failed to connect: org.bluez.Error.Failed

¡¡Error!! Tranquilos, está todo bajo control. Quería mostraros el que creo que es el punto en el que mucha gente se atasca. Veamos lo que dicen los logs:

may 30 19:32:04 ******** bluetoothd[3731]: a2dp-sink profile connect failed for YY:YY:YY:YY:YY:YY: Protocol not available

Lo de "a2dp-sink" es una buena pista de la causa del problema. ¿Os acordáis que cuando instalé el paquete bluez instalé también pulseaudio-module-bluetooth? Pues lo que pasa es que el módulo en cuestión no está cargado en el proceso de PulseAudio que ya está lanzado. Podríamos parar y reiniciar el servicio para que lea la nueva configuración, pero me cuesta menos decirle a PulseAudio que cargue el módulo:

$ pactl load-module module-bluetooth-discover 
20
$ pactl list short modules | grep bluetooth
20  module-bluetooth-discover

¿Alguién más piensa como yo que el paquete pulseaudio-module-bluetooth debería encargarse de ello automáticamente si el servicio PulseAudio está ya en marcha?

Volviendo a los logs, ahora muestran una cosa bien distinta:

may 30 19:41:29 ******** bluetoothd[3731]: Endpoint registered: sender=:1.42 path=/MediaEndpoint/A2DPSource
may 30 19:41:29 ******** bluetoothd[3731]: Endpoint registered: sender=:1.42 path=/MediaEndpoint/A2DPSink

El demonio bluetoothd ha sido capaz de registrar dos objetos D-Bus, uno para los auriculares del headset (/MediaEndpoint/A2DPSink) y otro para el micrófono (/MediaEndpoint/A2DPSource), que son los que empleará PulseAudio para enviar/recibir audio. Esto sucede en cuanto se enchufa el dongle, no hace falta que esté encendido el headset o cualquier otro dispositivo con perfiles A2DP y/o HSP.

Si encendemos ahora el headset y entramos en bluetoothctl veremos que bluetoothd ha establecido automáticamente la conexión sin que le hayamos tenido que decir nada (si no fuera así, ejecutad el comando connect YY:YY:YY:YY:YY:YY manualmente, ahora no debería dar error; también puede ser un buen momento para parar el scan con un scan off si no tenemos más dispositivos que emparejar). Y en los logs aparece:

may 30 19:44:41 ******** bluetoothd[3731]: /org/bluez/hci0/dev_YY_YY_YY_YY_YY_YY/fd0: fd(18) ready
may 30 19:44:41 ******** bluetoothd[3731]: Can't open input device: No such file or directory (2)
may 30 19:44:41 ******** bluetoothd[3731]: AVRCP: failed to init uinput for YY:YY:YY:YY:YY:YY

La primera línea (otro objeto exportado a través de D-Bus) nos confirma que la conexión con el pair remoto se ha establecido. Para las otras dos líneas de error he encontrado una solución en el wiki de Gentoo: compilar el kernel con estas opciones:

Device Drivers  --->
   Input device support  --->
      [*]   Miscellaneous devices  --->
         <M>   User level driver support

/dev/uinput es un driver para crear dispositivos de entrada virtuales en /dev/input/ desde espacio de usuario. bluetoothd crea un nuevo dispositivo de entrada /dev/input/eventN (siendo N un número correlativo) cuando enciendo el headset, y en los logs del kernel aparece:

input: YY:YY:YY:YY:YY:YY as /devices/virtual/input/input17

AVRCP es un perfil para mandos a distancia de video y de audio, pero ignoro exactamente cuál es el propósito de este dispositivo de input en ese contexto.

En busca del firmware perdido

Me había costado, pero tras hacer todo lo anterior por fin había conseguido que funcionara el headset en Debian Jessie. Y colorín colorado, este cuento se ha acabado. Excepto que no se ha acabado, porque como no me puedo quedar quieto, hace un par de semanas salté a Stretch, con el desastroso resultado de que el headset me dejó de funcionar. :-(

He dicho "me dejó de funcionar" pero en realidad lo que pasaba era lo siguiente: cuando se enviaba audio a PulseAudio y el headset estaba encendido, la aplicación que enviaba el audio (exaile, mplayer, etc) se quedaba "clavada" (la reproducción del audio —y del video también en el caso de mplayer— no avanzaba). En el caso de exaile, si intentaba parar la canción la aplicación se quedaba absolutamente congelada. Si apagaba el headset (lo que conmutaba el audio al sink de ALSA), las aplicaciones volvían a la vida y el sonido empezaba a reproducirse normalmente.

Como las diferencias entre Debian Jessie y Debian Stretch son todavía pequeñas, y el cambio fundamental es que Stretch había actualizado PulseAudio de la 5.0 a la 6.0, lo que hice fue probar a hacer un downgrade de los 7 paquetes de PulseAudio que tenía instalados, sustituyendo las versiones 6.0-2 por las 5.0-13 de Jessie.⁸ El resto de paquetes eran los de Stretch, incluyendo BlueZ (que en este caso da igual porque todavía es exactamente el mismo que el de Jessie). Con los paquetes 5.0-13 el headset volvía a funcionar sin problemas, lo que me permitía acotar el problema a los cambios que había introducido PulseAudio 6.0.

¿Y qué era lo más significativo que había introducido PulseAudio 6.0? Si habéis seguido atentamente las explicaciones del principio ya sabréis la respuesta: el soporte de perfiles HSP y HFP, ¡por algo solté todo el rollo! Y hay otro momento en esta historia en que también se mencionan dichos perfiles: cuando hablé sobre si necesitaba o no cargar el firmware propietario de Broadcom en el driver, y de los bugs que supuestamente éste arreglaba (relacionados con HSP/HFP). Llegados a este punto, el sentido común dictaba que era conveniente probar a cargar el firmware a ver si arreglaba algo.

Sólo restaba encontrar el firmware adecuado, lo que ha sido una pequeña odisea en sí misma. En la página del vendedor de dongles que afirmaba que se necesitaba el firmware para hacer funcionar los perfiles HSP/HFP (que no es la marca de mi dongle pero que debe ser un revendedor análogo porque es clavadito al mío) ofrecía para descargar el siguiente fichero:

-rw-r--r-- 1 ****** ****** 34700 feb 24  2014 fw-0a5c_21e8.hcd

Buscando por el mismo nombre de fichero, encontré otra versión que tenía un tamaño diferente (28758 bytes) lo que me dejaba la duda de cuál era el más reciente. Tampoco me hacía mucha gracia usar un blob opaco descargado de un sitio random de Internet, pero en la página oficial de Broadcom no hay disponible un driver para descargar del que poder extraerlo. Lo más que hay es un ejecutable para detectar qué dispositivo Bluetooth tienes y aparentemente descargarse el driver adecuado, pero como era previsible no funciona con wine (no es capaz de pasar de la fase de detección):

(Tampoco funcionó el truco de sacar los strings del ejecutable a ver si entre ellos aparecía la URL desde la que se descargaban los drivers).

Una alternativa que encontré era seguir estas instrucciones para obtener un .hcd a partir de los drivers de Windows. En éstos existen una serie de ficheros .hex (que parecen simplemente una versión hexadecimal del firmware) a partir de los cuales se puede generar el .hcd correspondiente usando la herramienta hex2hcd. BlueZ trae esta herramienta (que por cierto en la versión 5.28 ha sido reescrita) pero Debian a día de hoy no la empaqueta (Bug 780015) por lo que si queremos usarla hay que bajarse el fichero hex2hcd.c y compilarlo a mano.

El problema de este método alternativo es encontrar cuál es el .hex adecuado, porque hay decenas de ficheros de este tipo en los drivers de Windows. Hay que buscar la cadena VendorID y ProdID (en mi caso 0A5C:21E8) en los distintos ficheros *.INF hasta dar con la sección relevante, donde aparecerá algún nombre de fichero como éste: BCM20702A1_001.002.014.0187.0188.hex. Ese fichero (de tamaño 43432 bytes) es concretamente el que encontré en el CD de drivers que acompañaba a mi dongle. Para añadir más confusión, el .hcd generado a partir del mismo tenía un tamaño distinto al de los otros:

-rw-r--r-- 1 ****** ****** 21756 jun 24 16:43 fw-0a5c_21e8-BCM20702A1_001.002.014.0187.0188.hcd
-rw-r--r-- 1 ****** ****** 34700 feb 24  2014 fw-0a5c_21e8.hcd
-rw-r--r-- 1 ****** ****** 28758 jun 24 16:45 otro-fw-0a5c_21e8.hcd

De todas formas, el fichero .hex extraido del CD de drivers era de 2011, por lo que tenía pinta de ser una versión más antigua del firmware.

Al final me encontré en una página de soporte de Lenovo unos drivers Broadcom para Windows de 2013, y en ellos un fichero llamado BCM20702A1_001.002.014.0889.0896.hex de 57399 bytes, que convertido a .hcd me daba un fichero exactamente igual que el firmware de 28758 bytes que ya me había bajado antes. Esta es la versión que estoy usando:

usb 3-1.6: new full-speed USB device number 5 using ehci-pci
usb 3-1.6: New USB device found, idVendor=0a5c, idProduct=21e8
usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-1.6: Product: BCM20702A0
usb 3-1.6: Manufacturer: Broadcom Corp
usb 3-1.6: SerialNumber: ------------
Bluetooth: hci0: BCM: chip id 63
Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000
Bluetooth: hci0: BCM20702A1 (001.002.014) build 0896

La última línea es la del "patch RAM", y ya véis su semejanza al nombre del fichero .hex utilizado para generarlo.

Lo que no he podido encontrar es un .hex más moderno de un driver más reciente que se corresponda con el .hcd de 34700 bytes.

Perfiles, perfiles everywhere

Una vez puesto el firmware en el path en el que lo busca el driver del kernel, enciendo el headset y el sonido se escucha ¡Por fin! Pero es un sonido de una calidad bajísima y con mucha "fritura"⁹.

Después de estar un buen rato cavilando qué estaba mal (le estaba echando la culpa a la versión del firmware), por fin caigo: esa debe ser la calidad para perfiles HSP/HFP. Lo único que tengo que hacer es cambiar el perfil:

$ pactl list cards
Card #3
    Name: bluez_card.YY_YY_YY_YY_YY_YY
    Driver: module-bluez5-device.c
    Owner Module: 28
    Properties:
        device.description = "Energy BT5+"
        device.string = "YY:YY:YY:YY:YY:YY"
        device.api = "bluez"
        device.class = "sound"
        device.bus = "bluetooth"
        device.form_factor = "headset"
        bluez.path = "/org/bluez/hci0/dev_YY_YY_YY_YY_YY_YY"
        bluez.class = "0x240404"
        bluez.alias = "Energy BT5+"
        device.icon_name = "audio-headset-bluetooth"
        device.intended_roles = "phone"
    Profiles:
        headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: yes)
        a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)
        off: Apagado (sinks: 0, sources: 0, priority: 0, available: yes)
    Active Profile: headset_head_unit
    Ports:
        headset-output: Headset (priority: 0, latency offset: 0 usec)
            Part of profile(s): headset_head_unit, a2dp_sink
        headset-input: Headset (priority: 0, latency offset: 0 usec)
            Part of profile(s): headset_head_unit

La sección que nos interesa es la de "Profiles:". Véis que me está detectando dos perfiles (tres si contáis el perfil "off"). Pero el perfil correspondiente al HSP/HFP tiene más prioridad (20) que el de A2DP (10), así que se selecciona por defecto si no le decimos nada. Para cambiar el perfil usamos el siguiente comando, indicando tarjeta y perfil a activar:

$ pactl set-card-profile 3 a2dp_sink

Si no queremos indicar el número de tarjeta (que cambia cada vez que se enciende y apaga el headset) podemos usar el nombre (que permanece constante pero es más largo):

$ pactl set-card-profile bluez_card.YY_YY_YY_YY_YY_YY a2dp_sink

El perfil naturalmente tiene que estar disponible (available: yes) o nos devolverá un error bastante críptico (algo así como "Error de Entrada/Salida").

Si todo ha ido bien, ahora el estado de la tarjeta que corresponde al headset tendrá el nuevo perfil activo (Active Profile):

$ pactl list cards
[ ... ]
Profiles:
    headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: yes)
    a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)
    off: Apagado (sinks: 0, sources: 0, priority: 0, available: yes)
Active Profile: a2dp_sink

Y ahora el audio volverá a oirse con gran calidad con PulseAudio 6.0. ¡¡Hurra!!

(Sí, me podría haber ahorrado la etapa completa de la búsqueda del firmware, ya que lo único que necesitaba para que el headset volviera a funcionar en PulseAudio 6.0 era cambiar el perfil a a2dp_sink. Los bugs que corrige el firmware parece que se limitan al perfil HSP/HFP en este caso —o tal vez no, pero no he notado la diferencia—. Lo único que puedo decir es que es fácil hablar a toro pasado :-P).

PulseAudio recuerda el perfil activo de cada tarjeta, así que no hace falta estar seleccionandolo en cada arranque del demonio. Si lo que queremos es volver a pasar al perfil HSP/HFP (por ejemplo para usar el micrófono) hay que volver a cambiar el perfil activo:

$ pactl set-card-profile 3 headset_head_unit

Observad que a2dp_sink tiene 1 sink y 0 sources, mientras que headset_head_unit tiene 1 sink y 1 source. Los sinks (sumideros) corresponden en terminología PulseAudio a las salidas de audio, mientras que las sources (fuentes) corresponden a las entradas. El perfil de alta fidelidad A2DP no tiene entradas, por lo que no se puede usar el micrófono con este perfil. Si queremos usar la entrada de audio no nos queda más remedio que seleccionar el perfil HSP/HFP.¹⁰

Hay otra forma más visual de escoger el perfil usando la pestaña "Configuración" de pavucontrol (PulseAudio Volume Control). Aquí he preferido usar pactl para mostraros detalles de bajo nivel (como las prioridades o la disponibilidad) que son útiles si hay problemas. pavucontrol puede ser más atractivo, pero sólo nos permite seleccionar el perfil sin darnos información adicional:

Con tanta prueba y tanto cambio, en algún momento me ha pasado que un perfil me aparecía como no disponible:

$ pactl list cards
[ ... ]
Profiles:
    a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: no)
    headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: yes)
    off: Apagado (sinks: 0, sources: 0, priority: 0, available: yes)

Este tipo de estados no deberían ocurrir (y mucho menos que uno aparezca como disponible y el otro no), pero al estar jugando con los firmwares y demás tampoco me extraña que de repente haya una discrepancia entre los datos de estado almacenados por bluetoothd y los de PulseAudio. Comprobad con bluetoothctl que la conexión está establecida, y si no es así tratad de establecerla con un connect YY:YY:YY:YY:YY:YY. Si la conexión no se establece es cuando hay que empezar a investigar.

Otra posibilidad de recuperación más drástica que se me ocurre es tratar que ambos demonios olviden el estado que tienen almacenado del dispositivo, y empezar de nuevo todo el proceso de configuración desde cero. bluetoothctl tiene el comando remove para borrar un dispositivo remoto, lo que nos permite reemparejarlo de nuevo, pero no he encontrado ningún método equivalente en PulseAudio. Lo único que se me ocurre es hacerlo a las bravas: parar el demonio y borrar los ficheros donde guarda el estado en .config/pulse/*, pero este método tiene el serio inconveniente de borrar el estado de todo (tarjetas, volúmenes, etc). Si alguien sabe un método mejor estaría bien conocerlo.

Últimos retoques

No se me ha olvidado que dije que iba a explicar el origen de estos mensajes de error y cómo deshacerse de ellos:

bluetoothd[3731]: Sap driver initialization failed.
bluetoothd[3731]: sap-server: Operation not permitted (1)

SAP son las siglas de SIM Access Profile, otro perfil más de Bluetooth (y ya van...). Aunque un ordenador raramente va a tener acceso a una tarjeta SIM de teléfono, BlueZ es también la pila Bluetooth usada en Android¹¹. Así que los desarrolladores de BlueZ han incluido este perfil que permite "exportar" la SIM vía Bluetooth a otro dispositivo (sea cual sea la utilidad de algo así).

El soporte de SAP en BlueZ es experimental, pero los mantenedores del paquete en Debian han decidido compilar BlueZ con el flag --enable-experimental, y por eso SAP está incluido en la versión de bluetoothd de Jessie y Stretch y por eso aparecen esos mensajes. Lo que no sería mayor problema si no fuera porque mucha gente los confunde con el motivo por el que su dispositivo Bluetooth no funciona, mandándoles tras una pista falsa.

La solución más sencilla es pasar de estos mensajes ya que son inofensivos. Pero si nos resultan realmente irritantes, hay una manera de hacerlos desaparecer: decirle bluetoothd que desactive el plugin de SAP pasándole el parámetro --noplugin=sap en el arranque del demonio. Esto es más fácil o más difícil dependiendo del sistema de arranque que utilicéis. Por ejemplo, en systemd hay que modificar la unidad bluetooth.service para añadir el parámetro a la línea de ExecStart (solo que en systemd se supone que no hay que modificar los ficheros de unidades suministrados por los packagers sino añadir un fichero de unidad nuevo bajo /etc/systemd/system/ que toma precedencia; consultad la documentación más reciente de systemd en Debian para estar seguros).

Me dan ganas de abrir un bug en el BTS para que sean los propios Debian maintainers los que lo añadan por defecto.

Conclusiones

El protocolo Bluetooth, al intentar cubrir tantos dispositivos diferentes y tantos casos de uso, no es precisamente simple. La implementación en Linux lo empeora con una escasísima documentación y con cambios significativos a lo largo del tiempo. Si a esto le añadimos su interacción con otras piezas problemáticas como PulseAudio, y lo aderezamos todo con bugs hardware sólo solucionables mediante ficheros binarios "mágicos" difíciles de encontrar, entonces uno entiende por qué hay tantísimos problemas con algo que debería ser aparentemente más sencillo.

He dedicado mucho tiempo a poner el headset en marcha —y a escribir este artículo también—. Me podría haber ahorrado algo de trabajo si hubiera sido más espabilado, pero al final hubiera tenido que hacerlo igualmente si quería usar el micrófono. Y me queda también el consuelo de que me ha servido para terminar aprendiendo un montón de cosas de Bluetooth y PulseAudio por el camino. ;-)

:wq