Abilitare PipeWire per audio e Bluetooth in Ubuntu 22.04 e 20.04

Su Ubuntu 22.04 PipeWire è la strada naturale per gestire audio desktop e Bluetooth A2DP/HFP; su 20.04, invece, il passaggio va trattato come un cambio controllato, perché il sistema può avere ancora PulseAudio come stack predefinito e alcune versioni richiedono pacchetti aggiuntivi o backport. Il punto non è “installare qualcosa in più”, ma sostituire in modo pulito i componenti che fanno da server audio, evitando conflitti tra daemon, socket utente e servizi di sessione.

Se l’obiettivo è avere audio stabile, profili Bluetooth moderni e una base più coerente con gli stack recenti, conviene verificare prima lo stato reale della sessione: quale server sta rispondendo, quali moduli sono caricati, se il supporto Bluetooth passa da PulseAudio o da PipeWire, e se il desktop sta usando il socket utente corretto. Saltare questa parte porta spesso al classico risultato ambiguo: Bluetooth visibile ma senza audio, microfono muto, oppure due server che si contendono la stessa periferica.

Che cosa cambia davvero con PipeWire

PipeWire non è solo “un altro server audio”. In pratica sostituisce il backend che gestisce flussi audio e, in molti casi, anche il routing multimediale. Con il pacchetto giusto, aggiunge compatibilità con PulseAudio tramite il layer pipewire-pulse, e con Bluetooth tramite il componente di supporto dedicato. Questo permette di mantenere quasi invariata l’esperienza utente, ma con una base più flessibile per video, sandbox e dispositivi wireless.

Per un desktop Ubuntu, la distinzione operativa è semplice: se il sistema continua a esporre il socket PulseAudio classico, molte app si comporteranno come prima; se invece il socket è preso da PipeWire, l’ecosistema userà il compat layer. La differenza si vede subito con un controllo dello stato utente e con i pacchetti installati.

Verifica iniziale: capire chi sta gestendo l’audio

Prima di toccare i pacchetti, conviene raccogliere un quadro minimo. Su una macchina con sessione grafica attiva, questi controlli bastano per capire se sei già su PipeWire, su PulseAudio, o in una situazione ibrida.

1. Verifica i pacchetti installati:

dpkg -l | egrep 'pipewire|pulseaudio|wireplumber|bluez'

Atteso: su Ubuntu 22.04 dovresti vedere pipewire, pipewire-pulse, wireplumber e bluez. Su 20.04, se il passaggio è già stato fatto, la stessa combinazione può esserci, ma non è garantita di default.

2. Controlla quale server risponde al socket utente:

pactl info | egrep 'Server Name|Server String'

Atteso con PipeWire: la stringa server contiene PulseAudio (on PipeWire ...) o una variante equivalente. Se vedi il server PulseAudio classico, il sistema non è ancora migrato.

3. Controlla i servizi utente:

systemctl --user status pipewire pipewire-pulse wireplumber

Atteso: i tre servizi sono active (running). Se uno è in errore, la causa è quasi sempre un conflitto con PulseAudio, un socket non migrato, oppure una sessione utente non ricaricata dopo il cambio.

Ubuntu 22.04: migrazione lineare, con pochi margini di errore

Su 22.04 l’operazione è normalmente semplice, perché PipeWire è già parte della dotazione standard del desktop. Il problema tipico non è installarlo, ma far sì che prenda il posto di PulseAudio senza lasciare residui di configurazione o servizi avviati in parallelo.

La sequenza minima è questa:

1. Installa i pacchetti necessari.

2. Rimuovi o disabilita il supporto PulseAudio desktop se presente come servizio utente.

3. Riavvia la sessione grafica o il sistema.

4. Verifica audio, microfono e Bluetooth.

Comandi consigliati:

sudo apt update
sudo apt install pipewire pipewire-pulse wireplumber libspa-0.2-bluetooth bluez
systemctl --user --now disable pulseaudio.service pulseaudio.socket 2>/dev/null || true
systemctl --user --now enable pipewire.service pipewire-pulse.service wireplumber.service
systemctl --user restart pipewire pipewire-pulse wireplumber

Il comando di disabilitazione di PulseAudio può fallire se il servizio non esiste: in quel caso non è un errore, ma solo un segnale che il sistema era già in un assetto diverso. L’importante è che, dopo il riavvio della sessione, pactl info riporti PipeWire come backend.

Se usi GNOME, spesso basta disconnettersi e rientrare. Se vuoi essere più netto, riavvia la macchina. In ambienti con più utenti o con audio condiviso via sessione grafica remota, il riavvio della sola sessione può lasciare processi vecchi ancora vivi; in quel caso il reboot è più pulito e riduce falsi positivi.

Ubuntu 20.04: cambio controllato, perché la base è più vecchia

Su Ubuntu 20.04 la questione cambia. La release è nata con PulseAudio come scelta predefinita e, a seconda di aggiornamenti installati e flavor desktop, PipeWire può essere disponibile ma non sempre allineato all’esperienza moderna. Qui il rischio non è tanto il kernel, quanto la coesistenza tra pacchetti vecchi e nuovi e la presenza di configurazioni utente ereditate.

La regola pratica è questa: prima installi, poi disabiliti il vecchio stack, poi verifichi. Non fare il contrario, perché rischi di restare senza audio nella sessione corrente fino al re-login.

Sequenza consigliata:

1. Installa i pacchetti PipeWire e Bluetooth.

2. Se PulseAudio è attivo come servizio utente, fermalo e disabilitalo.

3. Abilita i servizi PipeWire e WirePlumber.

4. Ricarica la sessione grafica.

5. Verifica il routing audio e la presenza dei profili Bluetooth.

sudo apt update
sudo apt install pipewire pipewire-pulse wireplumber libspa-0.2-bluetooth bluez
systemctl --user stop pulseaudio.service pulseaudio.socket 2>/dev/null || true
systemctl --user disable pulseaudio.service pulseaudio.socket 2>/dev/null || true
systemctl --user enable --now pipewire.service pipewire-pulse.service wireplumber.service

Se wireplumber non è disponibile nei repository della tua installazione 20.04, allora hai un gap reale di packaging: non va inventata una soluzione. In quel caso la chiusura corretta è verificare i repository abilitati con apt-cache policy wireplumber e, se serve, valutare backport o upgrade del sistema. Senza il componente di sessione giusto, PipeWire parte ma non gestisce bene policy, profili e automazione dei device.

Bluetooth: perché l’audio funziona solo a metà

Molti passaggi a PipeWire falliscono non sull’audio interno, ma sul Bluetooth. Il motivo è quasi sempre uno di questi: stack Bluetooth non aggiornato, profilo A2DP non negoziato, backend audio ancora agganciato a PulseAudio, oppure permessi/sessione utente non coerenti.

La verifica minima parte dal demone Bluetooth di sistema:

systemctl status bluetooth
bluetoothctl show

Atteso: il servizio è active (running) e l’adattatore è visibile. Se l’adattatore non compare, PipeWire non c’entra ancora: il problema è a monte, a livello di driver, firmware o blocco radio.

Per i dispositivi già associati, controlla i profili disponibili:

pactl list cards short
pactl list cards | egrep 'bluez|Profiles|Active Profile'

Con PipeWire correttamente configurato, dovresti vedere profili come a2dp-sink e, se supportati, profili mani libere. Se vedi solo profili limitati, il problema può essere nel codec disponibile o nella versione del supporto Bluetooth.

Per il pairing e la fiducia del dispositivo, la parte utile resta bluetoothctl:

bluetoothctl
power on
agent on
default-agent
scan on
pair XX:XX:XX:XX:XX:XX
trust XX:XX:XX:XX:XX:XX
connect XX:XX:XX:XX:XX:XX

Non è un passaggio “PipeWire-specific”, ma serve a separare il problema di connessione da quello di routing audio. Se il device si connette ma non compare come sorgente/uscita audio, il guasto è nel layer audio, non nel layer radio.

Controlli pratici quando l’audio resta muto

Se dopo la migrazione l’audio non esce, fai diagnosi per layer, non per sintomi generici. La catena utile è: servizio utente → socket audio → device → profilo Bluetooth → app.

1. Verifica che PipeWire sia vivo:

systemctl --user status pipewire pipewire-pulse wireplumber

KO tipico: uno dei servizi è in crash o in loop di restart. In quel caso guarda il log utente:

journalctl --user -u pipewire -u pipewire-pulse -u wireplumber --since -30m

2. Verifica che l’app stia parlando col backend giusto:

pactl info

Se Server Name non cita PipeWire, stai ancora usando PulseAudio o un socket non allineato.

3. Verifica che la scheda audio o il device Bluetooth abbia un profilo attivo:

pactl list short cards
pactl list short sinks
pactl list short sources

Se il device esiste ma non c’è sink utile, prova a forzare il profilo A2DP con il nome della card individuato da pactl list short cards:

pactl set-card-profile <card-name> a2dp-sink

Questo comando è reversibile: puoi tornare al profilo precedente dalla stessa interfaccia o con un nuovo set-card-profile. Il blast radius è limitato alla sessione audio dell’utente corrente.

Persistenza dei servizi: evitare che il fix sparisca al reboot

Un errore classico è sistemare l’audio nella sessione corrente senza rendere persistente la configurazione. Su sistemi desktop, il punto delicato è il livello utente: i servizi devono essere abilitati per il profilo della sessione, non solo installati a livello di sistema.

Controllo utile:

systemctl --user is-enabled pipewire pipewire-pulse wireplumber

Atteso: enabled. Se uno dei servizi è disabled, l’installazione c’è ma l’avvio automatico al login no. In quel caso, abilita i servizi e poi riconnetti la sessione:

systemctl --user enable pipewire.service pipewire-pulse.service wireplumber.service

Se usi un ambiente desktop che carica ancora moduli PulseAudio legacy, verifica che non ci siano autostart residui o override in ~/.config/systemd/user/. Un file utente può vincere sulla configurazione di sistema e tenere vivo il vecchio daemon anche quando pensi di averlo rimosso.

Quando tenere PulseAudio e quando no

In un desktop moderno la risposta è semplice: se vuoi Bluetooth e audio desktop coerenti, ha senso passare a PipeWire. Tenere PulseAudio ha senso solo se hai vincoli applicativi precisi, pacchetti vecchi o una macchina non aggiornata dove PipeWire non è supportato in modo pulito. Mischiare i due stack nella stessa sessione, invece, è quasi sempre una cattiva idea.

Il criterio operativo è questo: o il socket utente è gestito da PipeWire, o non lo è. Le configurazioni ibride “a metà” producono sintomi intermittenti che sembrano casuali ma non lo sono: un giorno funziona il microfono, il giorno dopo il Bluetooth, poi sparisce la selezione del sink. Quasi sempre c’è un residuo di configurazione o un servizio duplicato.

Checklist finale per Ubuntu 22.04 e 20.04

1. Pacchetti: pipewire, pipewire-pulse, wireplumber, libspa-0.2-bluetooth, bluez.

2. Stato servizi: systemctl --user status pipewire pipewire-pulse wireplumber deve essere tutto running.

3. Backend attivo: pactl info deve indicare PipeWire.

4. Bluetooth: bluetoothctl deve vedere l’adattatore e la card audio deve offrire profili coerenti.

5. Persistenza: i servizi devono risultare enabled nella sessione utente.

Se uno di questi punti fallisce, non forzare modifiche casuali: fermati sul layer che ha dato KO e usa journalctl --user per capire se il problema è nel servizio, nel socket o nel profilo del device. È il modo più rapido per evitare di trasformare una migrazione audio in un guasto più ampio della sessione grafica.

In pratica: su Ubuntu 22.04 il passaggio a PipeWire è quasi sempre una sostituzione ordinata; su 20.04 è un cambio controllato che va verificato con più attenzione, soprattutto se il sistema è rimasto fermo per anni o ha pacchetti misti. La differenza la fa la disciplina operativa: controlli prima, modifica minima, verifica dopo.

Assunzione: i comandi sono eseguiti in una sessione desktop Ubuntu con privilegi sudo disponibili e repository standard attivi; se mancano wireplumber o i pacchetti Bluetooth, il gap va chiuso verificando prima i repository con apt-cache policy.