Opciones de micrófono/A2DP de Bluetooth faltantes: explicación de perfiles de controladores

El modelo mental: perfiles, roles y por qué las opciones desaparecen

Cuando la gente dice “mi auricular Bluetooth”, normalmente se refieren a “una pequeña computadora que puede hablar varios dialectos Bluetooth, a veces al mismo tiempo, a menudo mal.”
Tu sistema operativo entonces elige qué dialecto usar según lo que crea que quieres: salida de alta calidad, audio bidireccional, ahorro de energía, o “lo que no crashee hoy”.

Dos verdades clave

• La reproducción estéreo de alta calidad (A2DP) y el micrófono del auricular (HSP/HFP) suelen ser perfiles distintos.
  Muchos auriculares no pueden hacer salida estéreo de alta calidad y entrada de micrófono simultáneamente sobre Bluetooth clásico.
• La selección de perfil es política, no destino.
  Algo en tu sistema (BlueZ + servidor de audio + daemon de políticas) decide qué perfil activar.
  Si esa política falla, las opciones desaparecen de la interfaz como si nunca hubieran sido compatibles.

Qué suele significar “faltante”

“A2DP ausente” o “micrófono ausente” rara vez significa que el auricular carece de la función. Más a menudo:

• El perfil no se expone porque la pila de audio carece de un módulo/plugin de códec.
• El demonio Bluetooth está activo, pero el servidor de audio no negoció el perfil.
• Problemas de firmware/controlador impiden configurar el transporte (ves que se conecta, pero los endpoints de audio fallan).
• La política te dejó fijado en el perfil equivocado porque una aplicación pidió micrófono una vez.
• El soporte manos libres está presente pero deshabilitado por falta de backend de telefonía (común en Linux).

Una cita que debería estar en la pared de cualquiera que depure esto:
“La esperanza no es una estrategia.” — General Gordon R. Sullivan

Esa es tu misión aquí: reemplazar la esperanza por un diagnóstico repetible.

Datos interesantes y breve historia (que realmente ayuda al depurado)

1. A2DP llegó para estandarizar el audio estéreo. El audio Bluetooth temprano estaba orientado mayoritariamente a manos libres; el soporte para “música” maduró después, y eso se nota en la división actual.
2. SBC es obligatorio para A2DP, no “el mejor códec”. Si obtienes SBC, puede que simplemente sea el único códec común negociado—no una prueba de que tu sistema sea “baja calidad”.
3. HSP/HFP fueron diseñados para voz de banda estrecha. La vía “headset” históricamente asumía voz de ~8 kHz. La voz de banda ancha llegó después y aún es desigual entre dispositivos.
4. El audio Bluetooth en Linux solía ser una característica de PulseAudio añadida encima de BlueZ. Configuraciones antiguas usaban módulos separados; las modernas dependen de PipeWire/WirePlumber y plugins SPA.
5. BlueZ evita intencionalmente ser un “servidor de audio”. Proporciona la plomería Bluetooth; tu servidor de audio elige perfiles, códecs y enrutamiento.
6. mSBC (banda ancha) para HFP es una tierra de negociación minada. Algunos auriculares declaran soporte y luego se comportan mal. Resultado: “micrófono ausente” o “se conecta pero no hay audio.”
7. LE Audio (LC3) es un mundo nuevo, no un parche. Cambia transporte y capacidades. En Linux mejora rápido, pero no esperes soporte uniforme entre distribuciones y kernels todavía.
8. Algunos dongles USB Bluetooth se envían con combinaciones de firmware poco probadas. La misma familia de chips puede comportarse distinto según la versión de firmware; “funciona en mi portátil” no es garantía.

Broma #1: Bluetooth es la única tecnología de radio que puede ser bloqueada por el cuerpo humano y por la política corporativa al mismo tiempo.

Guía de diagnóstico rápido: comprobar primero/segundo/tercero

Cuando faltan opciones, quieres localizar el cuello de botella rápido: hardware/controlador, demonio Bluetooth, servidor de audio o política.
Haz estas comprobaciones en orden. No improvises.

Primero: confirma que el sistema ve el controlador y que está sano

• Si el controlador está bloqueado, ningún perfil importará.
• Si el firmware falla al cargar, obtendrás conexiones inestables y endpoints faltantes.

Segundo: confirma que BlueZ puede ver los servicios del auricular

• Buscas UUIDs anunciados que correspondan a perfiles de audio.
• Si el auricular no anuncia HFP/HSP, no obtendrás un perfil de micrófono (salvo mediante LE Audio, que es aparte).

Tercero: confirma que el servidor de audio está en ejecución y tiene soporte Bluetooth activado

• PipeWire necesita su plugin SPA de Bluetooth; PulseAudio necesita sus módulos Bluetooth.
• WirePlumber (u otro gestor de sesión) toma decisiones de política que ocultan/muestran perfiles.

Cuarto: revisa el perfil negociado y por qué se eligió

• Si tienes A2DP pero no micrófono: estás en el perfil de música.
• Si tienes micrófono pero no A2DP: muy probablemente estás en HSP/HFP (o la política te bloqueó allí).
• Si no tienes ninguno: fallo al crear transportes o plugins faltantes.

Quinto: busca errores de códec y transporte en los registros

• Errores que mencionen SBC/aptX/LDAC, o “transport acquire”, apuntan a la integración de la pila de audio.
• Errores que mencionen timeouts HCI apuntan a problemas de controlador/firmware/radio.

Realidad de los perfiles: A2DP vs HSP/HFP vs LE Audio (y qué significa realmente “mic”)

A2DP (Advanced Audio Distribution Profile)

A2DP es para salida de audio de alta calidad. Piensa en música, vídeos, sonidos del sistema.
No está diseñado para llevar entrada de micrófono en el sentido clásico.
Así que cuando tu interfaz muestra “A2DP Sink” y te preguntas dónde fue el micrófono: no fue a ninguna parte; nunca formó parte de ese perfil.

A2DP se suele emparejar con códecs como SBC (base), y opcionalmente AAC, aptX, aptX HD, LDAC y otros según el dispositivo y soporte de la pila.
La disponibilidad de códecs afecta calidad y latencia, pero no conjura soporte de micrófono.

HSP/HFP (Headset Profile / Hands-Free Profile)

HSP/HFP son para voz bidireccional. Aquí es donde aparece la entrada de micrófono en la mayoría de auriculares Bluetooth clásicos.
El coste: la salida de audio suele bajar a mono, banda estrecha y mayor compresión. La banda ancha (mSBC) la mejora, a veces.

Si tu aplicación de reuniones requiere micrófono, tu sistema puede cambiar el auricular a HFP automáticamente.
Eso no es malicioso. Es la única forma de obtener entrada de micrófono en Bluetooth clásico para muchos auriculares.
La razón por la que la opción “A2DP” desaparece es que el sistema no puede usar ambos simultáneamente de la manera que esperas.

LE Audio (LC3) y por qué cambia la conversación

LE Audio pretende soportar flujos de audio más flexibles, mejor eficiencia y códecs modernos (LC3).
Puede mejorar experiencias bidireccionales, pero necesitas soporte en:
controlador, kernel, BlueZ, servidor de audio y firmware del auricular. Un eslabón débil y vuelves a los perfiles clásicos.

Por qué la interfaz miente (un poco)

Las interfaces de audio de escritorio tienden a presentar los perfiles como “modos de calidad”, pero en realidad son servicios distintos con transportes distintos.
Algunas interfaces ocultan perfiles que fallan al activarse, lo que hace parecer que el auricular “no lo soporta”.
Puede que sí lo soporte. Tu pila puede que no.

Broma #2: El perfil “Hands-Free” está nombrado por los administradores, porque tendrás las manos muy ocupadas arreglándolo.

Pilas de audio en Linux: PulseAudio vs PipeWire vs WirePlumber (quién decide)

En escritorios Linux modernos, normalmente tienes:

• BlueZ para gestión de dispositivos Bluetooth y endpoints de transporte.
• PipeWire como motor de audio (a menudo reemplazando PulseAudio y a veces el ruteo JACK).
• WirePlumber (u otro gestor de sesión) para aplicar políticas: qué dispositivo, qué perfil, qué rutas.

En configuraciones antiguas, podrías tener:

• PulseAudio como motor de audio con módulos Bluetooth.
• Piezas de integración opcionales que varían por distribución.

Por qué importa esto

Los perfiles faltantes suelen ser causados por el componente equivocado tomando la decisión:
BlueZ ve el dispositivo, pero PipeWire no carga el plugin Bluetooth; o WirePlumber bloquea HFP porque no encuentra un backend de telefonía; o PulseAudio carece del módulo correcto.

La política es donde “antes funcionaba” va a morir

Los demonios de política recuerdan preferencias, reaccionan a que las apps abran flujos de entrada y tratan de mantener la estabilidad.
La estabilidad es buena. La estabilidad también puede significar “atascado”.
Cuando el sistema bloquea tu auricular en HFP porque una pestaña del navegador pidió micrófono, está haciendo exactamente lo que se le indicó.

Tareas prácticas (comandos, qué significa la salida y qué hacer después)

Los comandos abajo asumen un sistema Linux con systemd. Ajusta los nombres de servicio ligeramente para tu distro.
Cada tarea incluye: comando, interpretación de salida y una decisión.

Task 1: Check whether Bluetooth is blocked (rfkill)

cr0x@server:~$ rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Significado: Si alguno de los bloqueos dice “yes”, el controlador puede existir pero no funcionará.
Decisión: Si está soft blocked, desbloquéalo. Si está hard blocked, revisa el interruptor del BIOS o la tecla del portátil.

Task 2: Verify the controller is up (bluetoothctl)

cr0x@server:~$ bluetoothctl show
Controller 24:EE:9A:12:34:56 (public)
	Name: cr0x-laptop
	Powered: yes
	Discoverable: no
	Pairable: yes

Significado: “Powered: yes” es esencial. Si “Powered: no”, nada más importa.
Decisión: Si powered es no, ejecuta bluetoothctl power on y luego averigua por qué estaba apagado (política, ahorro de energía).

Task 3: Confirm kernel sees the Bluetooth HCI and drivers loaded

cr0x@server:~$ lsmod | grep -E 'btusb|bluetooth'
btusb                  69632  0
bluetooth             851968  22 btrtl,btintel,btbcm,btusb

Significado: Para controladores USB típicamente quieres btusb. Módulos faltantes pueden significar que el dongle no es soportado o está bloqueado.
Decisión: Si no aparece nada, confirma que el dispositivo existe en USB/PCI y que los módulos del kernel no están en blacklist.

Task 4: Check for firmware/driver failures in dmesg

cr0x@server:~$ dmesg -T | grep -iE 'bluetooth|btusb|firmware' | tail -n 20
[Tue Feb  4 10:12:21 2026] Bluetooth: hci0: Firmware revision 0x2b
[Tue Feb  4 10:12:21 2026] Bluetooth: hci0: Found device firmware: intel/ibt-20-1-3.sfi
[Tue Feb  4 10:12:22 2026] Bluetooth: hci0: Malformed MSFT vendor event: 0x02

Significado: Encontrar firmware es bueno. Reinicios HCI repetidos, “failed to load firmware” o timeouts apuntan a problemas de controlador/firmware.
Decisión: Si falta firmware, instala el paquete de firmware de tu distro. Si los timeouts persisten, prueba otro dongle o actualiza kernel/firmware.

Task 5: Verify BlueZ service health

cr0x@server:~$ systemctl status bluetooth --no-pager
● bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled)
     Active: active (running)
       Docs: man:bluetoothd(8)
   Main PID: 842 (bluetoothd)

Significado: Si no está activo, el emparejado puede “funcionar a medias” vía estados cacheados, pero los endpoints de audio no se comportarán.
Decisión: Si falló, revisa los logs y reinicia; arregla la configuración o dependencias faltantes.

Task 6: Inspect BlueZ logs for profile/transport errors

cr0x@server:~$ journalctl -u bluetooth -b --no-pager | tail -n 40
Feb 04 10:21:08 cr0x-laptop bluetoothd[842]: Endpoint registered: sender=:1.62 path=/MediaEndpoint/A2DPSink/sbc
Feb 04 10:21:08 cr0x-laptop bluetoothd[842]: Endpoint registered: sender=:1.62 path=/MediaEndpoint/A2DPSink/aac
Feb 04 10:22:11 cr0x-laptop bluetoothd[842]: src/service.c:btd_service_connect() a2dp-sink profile connect failed for 88:C9:E8:AA:BB:CC: Protocol not available

Significado: “Endpoint registered” sugiere que el servidor de audio registró endpoints A2DP con BlueZ. “Protocol not available” suele significar soporte de transporte faltante o fallo de negociación.
Decisión: Si los endpoints nunca se registran, enfócate en la integración PipeWire/PulseAudio Bluetooth. Si la conexión falla, enfócate en incompatibilidad de códec/perfil o en política.

Task 7: Confirm PipeWire is running (common on modern desktops)

cr0x@server:~$ systemctl --user status pipewire --no-pager
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled)
     Active: active (running)

Significado: Si PipeWire no está en ejecución, la UI de perfiles estará vacía o engañosa.
Decisión: Inícialo/habilítalo, o si usas PulseAudio intencionalmente, asegúrate de que PulseAudio esté en ejecución y PipeWire no esté medio instalado.

Task 8: Confirm WirePlumber is running (policy engine)

cr0x@server:~$ systemctl --user status wireplumber --no-pager
● wireplumber.service - Multimedia Service Session Manager
     Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled)
     Active: active (running)

Significado: Sin un gestor de sesión, los dispositivos pueden aparecer pero no enrutar ni aplicarseles perfiles.
Decisión: Si está inactivo, inícialo; si usas un gestor alternativo, confirma que esté instalado y configurado.

Task 9: List PipeWire audio devices and see available profiles

cr0x@server:~$ wpctl status
PipeWire 'pipewire-0' [1.2.7, cr0x@server, cookie:123456]
 └─ Clients:
        34. WirePlumber                        [1.2.7]

Audio
 ├─ Devices:
 │      52. Bluetooth Headset                 [bluez5]
 ├─ Sinks:
 │      78. Bluetooth Headset                 [vol: 0.62]
 ├─ Sources:
 │      81. Bluetooth Headset                 [vol: 1.00]

Significado: Que el dispositivo esté presente es bueno. Si el dispositivo existe pero falta la fuente, la ruta del micrófono no se creó (probablemente HFP/HSP no está activo o está bloqueado).
Decisión: Si solo existe sink, revisa si HFP está deshabilitado o no soportado. Si ninguno existe, puede que BlueZ esté conectado pero PipeWire no creó nodos.

Task 10: Inspect device details for profile state

cr0x@server:~$ wpctl inspect 52 | sed -n '1,120p'
id 52, type PipeWire:Interface:Device
	media.class = "Audio/Device"
	device.name = "bluez_card.88_C9_E8_AA_BB_CC"
	device.description = "Bluetooth Headset"
	bluez5.profile = "a2dp-sink"
	bluez5.address = "88:C9:E8:AA:BB:CC"

Significado: Estás explícitamente en a2dp-sink. Por eso el micrófono podría estar ausente o inutilizable.
Decisión: Si necesitas el micrófono, cámbiate a un perfil HFP/HSP (si está disponible) o usa un dispositivo de micrófono separado.

Task 11: Switch profiles (PipeWire/WirePlumber)

cr0x@server:~$ wpctl set-profile 52 handsfree-head-unit
Profile set

Significado: Si tiene éxito, deberías ver aparecer un nodo fuente y A2DP desaparecer o degradarse.
Decisión: Si falla, el perfil no está disponible; confirma que el auricular anuncia HFP/HSP y que tu pila lo soporta.

Task 12: Check available profiles the system believes exist

cr0x@server:~$ pactl list cards short
52	bluez_card.88_C9_E8_AA_BB_CC	module-bluez5-device.c

Significado: Incluso en sistemas PipeWire, las herramientas de compatibilidad de PulseAudio pueden mostrar tarjetas.
Decisión: Usa este nombre de tarjeta para consultar perfiles y puertos vía pactl list card.

Task 13: List card profiles (what’s actually selectable)

cr0x@server:~$ pactl list card bluez_card.88_C9_E8_AA_BB_CC | sed -n '/Profiles:/,/Active Profile:/p'
Profiles:
	a2dp-sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 40, available: yes)
	headset-head-unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 30, available: yes)
Active Profile: a2dp-sink

Significado: Este es el golpe maestro. Te dice si el sistema cree que HSP/HFP existe.
Decisión: Si HSP/HFP muestra “available: no”, el auricular puede no anunciarlo, o la política lo deshabilitó, o falta el backend.

Task 14: Switch profile with pactl (works via PipeWire-Pulse too)

cr0x@server:~$ pactl set-card-profile bluez_card.88_C9_E8_AA_BB_CC headset-head-unit

Significado: Si el micrófono aparece después de esto, el “micrófono faltante” era solo “perfil equivocado”.
Decisión: Decide si aceptas salida de calidad de auricular durante llamadas. Si no, usa un micrófono dedicado y mantén A2DP.

Task 15: Check whether the headset advertises the right UUIDs (bluetoothctl)

cr0x@server:~$ bluetoothctl info 88:C9:E8:AA:BB:CC
Device 88:C9:E8:AA:BB:CC (public)
	Name: Bluetooth Headset
	Paired: yes
	Trusted: yes
	Connected: yes
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
	UUID: AV Remote Control         (0000110e-0000-1000-8000-00805f9b34fb)

Significado: “Audio Sink” se alinea con A2DP. “Handsfree” se alinea con HFP. Si los UUIDs Handsfree/Headset están ausentes, tu perfil de micrófono puede no aparecer nunca.
Decisión: Si los UUIDs no están, deja de culpar a Linux y comienza a sospechar del modo del auricular (algunos tienen toggles “gaming” vs “phone”) o de peculiaridades del fabricante.

Task 16: Reset a flaky pairing (remove and re-pair cleanly)

cr0x@server:~$ bluetoothctl
[bluetooth]# disconnect 88:C9:E8:AA:BB:CC
Successful disconnected
[bluetooth]# remove 88:C9:E8:AA:BB:CC
Device has been removed
[bluetooth]# scan on
Discovery started
[bluetooth]# pair 88:C9:E8:AA:BB:CC
Pairing successful
[bluetooth]# trust 88:C9:E8:AA:BB:CC
Changing 88:C9:E8:AA:BB:CC trust succeeded
[bluetooth]# connect 88:C9:E8:AA:BB:CC
Connection successful

Significado: Esto borra servicios cacheados antiguos y puede arreglar casos de “perfil desapareció tras una actualización”.
Decisión: Si re-emparejar restaura perfiles, tu problema era corrupción de estado o descubrimiento de servicios obsoleto, no un controlador faltante.

Task 17: Watch realtime logs while switching profiles

cr0x@server:~$ journalctl --user -u pipewire -u wireplumber -f
Feb 04 10:31:42 cr0x-laptop wireplumber[1290]: bluez5: activating profile headset-head-unit
Feb 04 10:31:42 cr0x-laptop pipewire[1210]: bluez5-device: transport acquire 88:C9:E8:AA:BB:CC
Feb 04 10:31:42 cr0x-laptop pipewire[1210]: spa.bluez5: Failed to set codec configuration: Not supported

Significado: “Failed to set codec configuration” a menudo significa que el auricular y la pila discrepan sobre un códec de voz (mSBC vs CVSD) o que las capacidades están mal reportadas.
Decisión: Forza un códec más simple si es posible (deshabilita mSBC en la configuración), actualiza BlueZ/PipeWire, o acepta que el HFP de ese auricular está roto en esta pila.

Task 18: Verify you’re not running conflicting audio servers

cr0x@server:~$ ps -ef | grep -E 'pipewire|pulseaudio' | grep -v grep
cr0x      1210    1090  0 10:18 ?        00:00:02 /usr/bin/pipewire
cr0x      1211    1090  0 10:18 ?        00:00:01 /usr/bin/pipewire-pulse

Significado: Esto es normal en configuraciones PipeWire (PipeWire proporcionando compatibilidad PulseAudio).
Si también ves un demonio pulseaudio independiente, podrías tener una guerra de territorios.
Decisión: Elige una pila. No ejecutes ambas a menos que disfrutes diagnosticando dispositivos fantasma.

Task 19: Check PulseAudio Bluetooth modules (for older PulseAudio systems)

cr0x@server:~$ pactl list modules short | grep -E 'bluez|bluetooth'
28	module-bluetooth-policy
29	module-bluetooth-discover

Significado: Si estos módulos no están cargados, puedes emparejar pero no obtener tarjetas/perfiles de audio.
Decisión: Cárgalos (temporalmente) o corrige tu configuración de PulseAudio para cargarlos al inicio.

Task 20: Check codec availability hints (PipeWire properties)

cr0x@server:~$ wpctl inspect 52 | grep -iE 'a2dp|codec|bluez5'
	bluez5.profile = "handsfree-head-unit"
	bluez5.codec = "CVSD"

Significado: Ver CVSD implica que estás en un perfil de voz con códec básico. Eso no es “malo”, es “predecible”.
Decisión: Si mSBC rompe las llamadas, prefiere la estabilidad de CVSD. La calidad del audio no vale cuando el micrófono se cae a mitad de frase.

Task 21: Check Bluetooth adapter power management state (common flake source)

cr0x@server:~$ cat /sys/module/bluetooth/parameters/disable_ertm
N

Significado: Algunos dispositivos tienen problemas con ciertos modos de enlace; parámetros como toggles ERTM pueden afectar la estabilidad (según kernel/versión).
Decisión: No cambies parámetros del kernel a ciegas. Solo modifica si puedes reproducir y revertir, idealmente en un entorno controlado.

Task 22: Validate the ALSA side is not the bottleneck (for non-Bluetooth mics)

cr0x@server:~$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: Webcam [USB Webcam], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Significado: Si el micrófono del auricular es inestable, usar un micrófono USB/webcam puede ser una solución práctica.
Decisión: En reuniones, prioriza la fiabilidad: mantén A2DP para salida y usa un dispositivo de captura dedicado.

Errores comunes: síntoma → causa raíz → solución

1) Síntoma: “A2DP desapareció; solo aparece Headset/HFP”

• Causa raíz: Una app abrió un flujo de entrada, la política cambió a HFP y se quedó allí.
• Solución: Cambia el perfil de vuelta a A2DP con wpctl set-profile o pactl set-card-profile. Luego niega permisos de micrófono a apps que no lo necesiten.

2) Síntoma: “Opción de micrófono completamente ausente”

• Causa raíz: El auricular no anuncia UUIDs HSP/HFP en el modo actual, o el backend HFP está deshabilitado en tu pila.
• Solución: Revisa bluetoothctl info para ver los UUIDs. Si faltan, cambia el modo/firmware del auricular. Si están presentes, revisa la configuración de PipeWire/WirePlumber para habilitar HFP.

3) Síntoma: “Conectado, pero no hay sonido por A2DP”

• Causa raíz: Falla la adquisición del transporte; desajuste en la negociación de códec; o el servidor de audio no registró endpoints en BlueZ.
• Solución: Revisa journalctl -u bluetooth y los logs de PipeWire. Confirma que los endpoints estén registrados. Intenta cambiar el códec (o volver a SBC) y re-emparejar.

4) Síntoma: “El sonido funciona, el micrófono funciona, pero la calidad es terrible”

• Causa raíz: El códec de voz HSP/HFP (CVSD) es de banda estrecha por diseño, y la salida suele ser mono.
• Solución: Usa A2DP para salida y un micrófono separado; o intenta banda ancha (mSBC) si es estable; o adopta hardware LE Audio de extremo a extremo.

5) Síntoma: “El cambio de perfil falla: Not supported / Protocol not available”

• Causa raíz: Falta un plugin/módulo de audio Bluetooth, o desajuste de versión entre BlueZ y el servidor de audio.
• Solución: Verifica que el plugin SPA de Bluetooth de PipeWire esté instalado; asegura que los servicios estén en ejecución; actualiza a un conjunto compatible (kernel/BlueZ/PipeWire). Reinicia si se actualizaron componentes en medio de la sesión.

6) Síntoma: “Funciona tras reiniciar, se rompe tras suspensión”

• Causa raíz: Bugs en la gestión de energía del controlador; carreras al reconectar el dispositivo; estado de transporte obsoleto.
• Solución: Reinicia servicios de audio de usuario (systemctl --user restart pipewire wireplumber) y alterna Bluetooth. Si es frecuente, prueba un kernel/firmware más reciente o un adaptador distinto.

7) Síntoma: “El auricular se conecta al portátil pero el micrófono nunca aparece en las apps de reuniones”

• Causa raíz: Permisos sandbox de la app o ajustes del portal; el dispositivo de entrada existe pero no está seleccionado; o la app solo lista dispositivos ALSA en algunos modos.
• Solución: Verifica que la fuente exista con wpctl status. Selecciónala explícitamente en la app. Revisa los prompts de permisos y la configuración.

Listas de verificación / plan paso a paso

Checklist A: “Necesito A2DP para música y no me importa el micrófono del auricular”

1. Configura el perfil a A2DP: pactl set-card-profile ... a2dp-sink.
2. Elige un micrófono separado: micrófono de webcam o USB; confirma con arecord -l.
3. En las apps de reuniones, selecciona explícitamente el micrófono separado.
4. Quita el permiso de micrófono para pestañas del navegador y apps de chat “útiles”.

Orientación con opinión: esta es la configuración más fiable para llamadas de trabajo con Bluetooth clásico hoy.
No es elegante. Es estable.

Checklist B: “Necesito el micrófono del auricular para llamadas, acepto menor calidad de salida”

1. Confirma que el auricular anuncia UUIDs Handsfree/Headset con bluetoothctl info.
2. Cámbiate al perfil de auricular: wpctl set-profile ... handsfree-head-unit.
3. Observa los logs al cambiar; si aparecen errores de códec, prefiere la estabilidad de CVSD sobre las aspiraciones mSBC.
4. Prueba primero en un grabador simple (no en la reunión del navegador) para aislar problemas de la app.

Checklist C: “Faltan perfiles; los necesito de vuelta”

1. Comprueba que el controlador esté sano: rfkill list, bluetoothctl show, líneas de firmware en dmesg.
2. Comprueba la salud y logs de BlueZ: systemctl status bluetooth, journalctl -u bluetooth.
3. Comprueba servicios de audio: systemctl --user status pipewire wireplumber.
4. Comprueba perfiles de la tarjeta: pactl list card ....
5. Elimina y vuelve a emparejar el dispositivo para refrescar el descubrimiento de servicios.

Checklist D: “Funciona en un portátil, no en otro”

1. Compara versiones de kernel y BlueZ (las mismas versiones principales importan).
2. Compara versiones de PipeWire/WirePlumber y si los plugins Bluetooth están instalados.
3. Compara el adaptador Bluetooth (interno vs dongle) y los logs de firmware.
4. No ignores el entorno radio: puertos USB 3 y interferencias a 2.4 GHz pueden degradar la estabilidad.

Tres micro-historias corporativas desde la vida en producción

Micro-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó un “auricular estándar” para una plantilla híbrida. La lista de compra decía “Bluetooth, cancelación de ruido, soportado en Linux.”
Fue el optimismo corporativo habitual: si empareja, funciona.

En el primer día de una semana con reuniones generales, una oleada de tickets apareció: “Mi micrófono falta.” La gente podía oír la reunión, pero nadie podía hablar.
La primera respuesta del equipo de TI fue culpar al cliente de conferencias. Sensato, excepto que el bug se reproducía en tres apps distintas.

La suposición equivocada: pensaron que A2DP implicaba capacidad de micrófono. Habían estandarizado en salida “High Fidelity” y nunca validaron audio bidireccional.
Las imágenes de escritorio estaban configuradas para preferir A2DP y no cambiar automáticamente a HFP porque el modo HFP del auricular anterior era inestable.

La solución fue tediosa pero efectiva: documentar el trade-off, proporcionar un script de un clic para cambiar de perfil y enviar un micrófono USB barato a equipos que hacían muchas llamadas.
Para un subconjunto de usuarios, eligieron auriculares por cable porque la latencia y el cambio de perfil los estaban matando.

Después, actualizaron la prueba de aceptación de hardware: “¿Puedes grabar 30 segundos de audio desde el micrófono del auricular mientras está conectado, sin bucear manualmente en la UI?”
Al procurement no le gustó. A operaciones sí.

Micro-historia 2: La optimización que salió mal

Otra organización intentó “optimizar la batería” en portátiles siendo agresiva con la gestión de energía.
Hicieron un cambio de configuración de flota que afinó el comportamiento de suspensión y apagó radios rápidamente cuando estaban inactivos.

La consecuencia no intencionada: las reconexiones Bluetooth tras suspensión empezaron a competir con el arranque de la sesión de usuario.
BlueZ reconectaba el auricular, pero PipeWire/WirePlumber perdía el timing del descubrimiento de servicios inicial.
Los usuarios veían un dispositivo conectado con perfiles faltantes, o el perfil A2DP aparecía pero no lograba adquirir transporte.

Los ingenieros intentaron arreglarlo añadiendo bucles de reinicio (“si falla, reinicia servicios”). Eso lo empeoró.
Ahora, durante los primeros minutos tras despertar, el sistema estaba en thrash: reconectando, desmantelando, re-registrando endpoints y ocasionalmente dejando el auricular en un estado roto.

La solución fue… dejar de ser ingeniosos. Relajaron la política de apagado de radio y añadieron una pequeña y determinista demora antes de aplicar la política de ruteo a dispositivos de audio Bluetooth recién conectados.
También añadieron observabilidad: logs capturados alrededor de cambios de perfil, no solo “Bluetooth conectado.”

La vida de la batería siguió siendo aceptable. La fiabilidad de las reuniones mejoró drásticamente. Y la cola de tickets dejó de parecer un ataque de denegación de servicio.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa con cultura SRE estricta trató la “imagen de escritorio” como un producto. La versionaron, la probaron y lanzaron actualizaciones en anillos.
No emocionante. Tampoco común.

Cuando empezaron la migración de PulseAudio a PipeWire, no lo hicieron con un cambio masivo.
Ejecutaron grupos piloto, capturaron la lista de auriculares Bluetooth en uso y validaron disponibilidad de perfiles para cada uno: códecs A2DP, comportamiento HFP, suspensión/reanudación.

Durante el despliegue, una actualización cambió la preferencia por defecto de códec Bluetooth. Una pequeña clase de auriculares negoció un códec “mejor” y luego se cayó a mitad de llamada.
El grupo piloto lo detectó en horas, con logs adjuntos que mostraban fallos de configuración de códec durante la activación de perfil.

La práctica aburrida: tenían una prueba de regresión que literalmente cambiaba perfiles, grababa audio y verificaba que los nodos existieran en PipeWire.
Usaron los mismos comandos que estás usando en este artículo. No hay magia. Solo comprobaciones repetibles.

Fijaron la preferencia de códec a una línea base conocida y estable para esa clase de auriculares y avanzaron solo después de verificar la estabilidad.
Nadie escribió un post triunfal. El helpdesk se mantuvo en silencio. Esa es la condición real de victoria.

Preguntas frecuentes

1) ¿Por qué mi micrófono del auricular desaparece cuando elijo “High Fidelity (A2DP)”?

Porque A2DP es para reproducción, no captura de micrófono. Para auriculares Bluetooth clásicos, la captura de micrófono típicamente requiere HSP/HFP, que suele reemplazar A2DP.

2) ¿Por qué A2DP desaparece cuando activo el micrófono?

Cambiar a HSP/HFP activa un transporte distinto optimizado para voz. Muchos auriculares no pueden hacer salida estéreo A2DP mientras proporcionan entrada de micrófono en Bluetooth clásico.

3) Mi auricular soporta micrófono en mi teléfono. ¿Por qué no en mi portátil Linux?

Los teléfonos suelen tener pilas HFP maduras y ajustes del fabricante. En Linux, el soporte HFP depende de BlueZ + servidor de audio + configuración de política. Plugins faltantes o backends deshabilitados pueden ocultar HFP por completo.

4) ¿Cómo sé si mi auricular anuncia servicios Hands-Free?

Usa bluetoothctl info <MAC> y busca UUIDs como “Handsfree” o “Headset.” Si no están, el SO no los inventará.

5) PipeWire está en ejecución. ¿Por qué aún no tengo perfiles Bluetooth?

PipeWire necesita soporte Bluetooth vía sus plugins SPA, y un gestor de sesión como WirePlumber para aplicar políticas. Si los endpoints no se registran en los logs de BlueZ, la capa de integración falta o está rota.

6) ¿Debería usar mSBC banda ancha para mejor calidad de llamada?

Si es estable en tu auricular y pila, sí. Si ves fallos de configuración de códec o caídas, usa CVSD. La fiabilidad vence la calidad teórica en reuniones reales.

7) ¿Puedo forzar al sistema a permanecer en A2DP y usar igualmente el micrófono del auricular?

Normalmente no en Bluetooth clásico. El enfoque pragmático: mantener A2DP para salida y usar un micrófono separado (USB/webcam). O migrar a hardware LE Audio de extremo a extremo.

8) ¿Por qué funciona hasta que abro una pestaña del navegador, y luego los perfiles cambian?

El navegador pidió acceso al micrófono; la política cambió a un perfil capaz de voz. Niega permisos de micrófono cuando sea posible, o cambia manualmente a A2DP después de la llamada.

9) ¿Cuál es la forma más rápida de ver qué perfil está activo?

En PipeWire: wpctl inspect al dispositivo Bluetooth y comprueba bluez5.profile. Con pactl: revisa “Active Profile” bajo pactl list card.

10) ¿Necesito reiniciar para arreglar esto?

Normalmente no. Reiniciar servicios de usuario (pipewire, wireplumber) y re-emparejar el auricular a menudo limpia el estado obsoleto. Reinicia solo si se actualizaron kernel/firmware.

Conclusión: siguientes pasos que no te hagan perder la tarde

Trata las opciones de micrófono/A2DP faltantes como un fallo de negociación, no como una maldición mística.
Primero valida el controlador y BlueZ. Luego valida el servidor de audio y la política. Luego mira qué perfil está activo y por qué.
La interfaz es el último lugar para depurar esto, no el primero.

Pasos prácticos siguientes

1. Ejecuta bluetoothctl info y confirma que el dispositivo anuncia los servicios de audio que esperas.
2. Ejecuta pactl list card o wpctl inspect y confirma qué perfiles están disponibles y cuál está activo.
3. Si necesitas fiabilidad para llamadas, elige uno:
   • A2DP para salida + micrófono separado (aburrido, efectivo), o
   • modo auricular HFP (calidad inferior, pero integrado), o
   • ruta de actualización a LE Audio (mejor en el futuro, hoy desigual).
4. Si cambiar perfiles falla, deja de alternar ajustes al azar y lee los logs mientras cambias. Las cadenas de error usualmente te dicen qué capa está rota.

El audio Bluetooth es una pila de decisiones. Haz esas decisiones explícitas y el problema de la “opción faltante” vuelve a ser ingeniería.