Il microfono non funziona su Linux: come verificarlo e risolverlo

Su Linux, un microfono che non funziona è molto più spesso semplicemente disattivato piuttosto che guasto. Il canale di acquisizione ALSA viene fornito disabilitato in molte distribuzioni, pertanto la capsula funziona mentre il driver non inoltra alcun segnale. Una sorgente predefinita errata o un’applicazione confinata in una sandbox spiegano la maggior parte dei casi rimanenti. Il segnale percorre una pila a più livelli: il driver del kernel ALSA, poi PipeWire o PulseAudio, infine l’applicazione stessa. Qualsiasi livello può interromperne il passaggio, e il risultato è sempre lo stesso silenzio. La soluzione corretta dipende interamente dal livello in cui si verifica il blocco. Questa guida identifica tale livello, per poi risolverlo con procedure sia grafiche che da terminale. Inizi con un rapido test del microfono o con l’indicatore di livello di ingresso sul desktop per verificare il funzionamento dell’hardware. Successivamente, verifichi se la Sua distribuzione utilizza PipeWire o PulseAudio, poiché i comandi riportati di seguito variano a seconda della risposta.

Il microfono non funziona su Linux: lista di controllo per una risoluzione rapida

✓	Esegua il test con il nostro test del microfono o con l’indicatore di livello dell’ingresso audio sul desktop.
✓	Abiliti l’audio del canale Capture in alsamixer e ne aumenti il livello.
✓	Imposti l’ingresso corretto in pavucontrol (o wpctl su PipeWire).
✓	Verifichi che il Suo utente faccia parte del gruppo audio.
✓	Riavvii l’audio: systemctl --user restart pipewire pipewire-pulse o pulseaudio -k.

Verifichi il funzionamento del microfono su Linux in meno di un minuto

Verifichi che il microfono rilevi il suono prima di modificare qualsiasi impostazione. La soluzione al problema “nessun segnale” è completamente diversa da quella per “c’è segnale, ma nessuno mi sente”. Un indicatore di livello in tempo reale fornisce la risposta più rapida e attendibile, poiché reagisce alla Sua voce in tempo reale. Un ciclo di registrazione e riproduzione può nascondere errori nella selezione del dispositivo, quindi inizi con un indicatore di livello. Apra il nostro test del microfono online e conceda l’accesso quando richiesto dal browser. Ora parli normalmente. Se l’indicatore di livello si muove mentre parla, il microfono, il driver e il server audio funzionano correttamente. Il problema si trova quindi a un livello superiore, nel routing o in un’app specifica. Se l’indicatore rimane fermo, il segnale è bloccato oppure è stato selezionato l’ingresso sbagliato.

Verifichi il microfono →

Anche il Suo desktop espone il microfono in modo nativo. Su GNOME, apra Impostazioni › Audio › Ingresso e selezioni il Suo dispositivo; la barra del livello di ingresso dovrebbe muoversi mentre parla. Su KDE Plasma, apra Impostazioni di sistema › Audio e osservi l’indicatore accanto al dispositivo di registrazione. Supponiamo che la barra si muova in questo caso, ma che un’applicazione continui a non rilevare alcun suono. In tal caso, ha dimostrato che il problema è specifico dell’applicazione piuttosto che a livello di sistema, quindi passi alle sezioni relative all’instradamento e alle autorizzazioni riportate di seguito. La tabella illustra le posizioni grafiche in cui il desktop mostra il microfono e ciò che il valore visualizzato in ciascuna di esse conferma.

Dove cercare	Percorso	Cosa conferma
Indicatore di ingresso GNOME	Impostazioni › Audio › Ingresso	Se il sistema riceve un segnale e da quale dispositivo
Pannello audio KDE	Impostazioni di sistema › Audio	Il dispositivo di registrazione attivo e il suo instradamento per ciascuna app
Controllo del volume	pavucontrol › Dispositivi di ingresso	Stato di silenziamento, guadagno e porta hardware selezionata
Scheda Registrazione	pavucontrol › Registrazione	Quale app acquisisce da quale dispositivo, in tempo reale

Conoscere il proprio server audio prima di procedere alla risoluzione dei problemi

L’audio su Linux è strutturato a livelli e la soluzione corretta dipende dal livello in cui si verifica il problema. Alla base si trova ALSA, il driver a livello di kernel che comunica con la scheda audio. Al di sopra di esso opera un server audio che mixa i flussi e li instrada tra le applicazioni. Due server sono predominanti. Le distribuzioni moderne includono PipeWire. Fedora è stata la prima ad adottarlo, mentre Ubuntu lo utilizza di default a partire dalla versione 22.10. PipeWire utilizza un livello di compatibilità denominato pipewire-pulse, in modo che gli strumenti meno recenti continuino a funzionare senza modifiche. Le versioni precedenti e alcune configurazioni più tradizionali utilizzano ancora PulseAudio. Entrambi i server si basano su ALSA, e un canale disattivato in ALSA blocca il segnale per entrambi.

Identifichi il proprio server prima di perdere tempo con lo strumento sbagliato. Esegua il comando wpctl status in un terminale. Un elenco pulito di sink e sorgenti indica che PipeWire è attivo. Se il comando non è presente, molto probabilmente si trova su PulseAudio; confermi con pactl info. Ciò è importante perché i comandi divergono. PipeWire è gestito con wpctl, mentre PulseAudio utilizza pactl. Lo strumento grafico pavucontrol funziona con entrambi, poiché pipewire-pulse risponde alle stesse richieste. La tabella sottostante riassume gli strumenti principali e le rispettive funzioni.

Strumento	Tipo	Funzione
pavucontrol	Grafico	Riattiva gli ingressi, imposta il guadagno, seleziona la porta e mostra i percorsi di registrazione per ciascuna applicazione
alsamixer	Terminale (TUI)	Controlla la scheda ALSA a livello raw: silenziamento dell’acquisizione, attivazione dell’acquisizione e guadagno hardware
arecord / aplay	Terminale	Elenca i dispositivi di acquisizione e registra o riproduce un file direttamente tramite ALSA
wpctl	Terminale	Elenca i dispositivi PipeWire, imposta la sorgente predefinita e attiva o disattiva il silenziamento

Perché un microfono funzionante rimane comunque silenzioso su Linux

Un canale di acquisizione ALSA disattivato è la causa principale

ALSA controlla ogni canale di acquisizione in modo indipendente, e uno di essi può essere disattivato al di sotto di tutti gli altri. Quando ciò accade, l’indicatore sul desktop segna zero indipendentemente da quanto si alzi il volume del software. Questa singola condizione causa più microfoni “guasti” su Linux rispetto a qualsiasi difetto hardware. La trappola sta nel fatto che spesso ciò non è visibile dal mixer grafico. La soluzione si trova in alsamixer, un mixer da terminale che consente di accedere alle impostazioni di base della scheda audio. Lo avvii, quindi prema F6 per selezionare la Sua scheda audio. Prema F4 per passare alla vista di acquisizione. Evidenzi il canale Capture con i tasti freccia. Se sotto la barra compare la scritta MM, significa che è disattivato; prema M per riattivarlo. Un canale di acquisizione deve inoltre essere armato. Prema Space sull’elemento selezionato finché non compare la scritta CAPTURE in rosso, quindi aumenti il livello con la freccia su. Molti laptop presentano qui anche un controllo denominato Internal Mic Boost, impostato di fabbrica su zero. Aumentandone il valore è possibile riattivare un microfono che sembrava non funzionare.

Sorgente predefinita errata e instradamento non corretto

Il server audio sceglie una sorgente predefinita, ma non sempre quella desiderata. Collegando delle cuffie USB, una webcam con microfono integrato o un dispositivo di acquisizione HDMI, il server potrebbe assegnare immediatamente tale dispositivo come sorgente. Errori di instradamento si nascondono anche all’interno delle singole applicazioni. PipeWire e PulseAudio consentono a ciascun programma di registrare da un dispositivo diverso, impostato per ogni singolo flusso. Un’app può quindi essere indirizzata verso una sorgente che non produce alcun segnale, mentre quella predefinita dal sistema funziona correttamente. La scheda Registrazione in pavucontrol lo evidenzia direttamente, elencando tutte le app attualmente in fase di acquisizione e il dispositivo che utilizzano. Si deve innanzitutto sospettare un problema di instradamento ogni volta che il microfono funziona in un programma ma non in un altro. Le cuffie Bluetooth aggiungono un’ulteriore complicazione. Una cuffia con il profilo A2DP ad alta qualità non dispone affatto di microfono. Il sistema deve commutarla sul profilo HSP/HFP prima che il microfono a braccio diventi operativo, e in tal caso la qualità audio subisce un calo.

Autorizzazioni, gruppi e applicazioni in sandbox

Il controllo degli accessi blocca il microfono senza visualizzare alcun messaggio di errore. In passato, un utente doveva appartenere al gruppo audio per poter accedere ai dispositivi audio. La maggior parte dei desktop moderni gestisce questa funzione tramite la sessione, ma un’installazione minimale o su server potrebbe ancora richiederla. Il sandboxing rappresenta il problema più recente e più complesso. Le applicazioni distribuite come Flatpak o Snap vengono eseguite all’interno di un livello di confinamento in grado di negare l’accesso al microfono anche quando il resto del sistema funziona correttamente. L’applicazione riceve quindi solo silenzio, senza alcun messaggio di errore. È possibile verificare e concedere tali autorizzazioni tramite Flatseal, un editor grafico per i portali Flatpak, oppure dal terminale con il comando flatpak permissions. I browser aggiungono un proprio livello separato. Un sito deve essere autorizzato all’interno del browser indipendentemente dallo stato del sistema. Le nostre guide Firefox e Chrome trattano in dettaglio tale richiesta all’interno del browser.

Risoluzione del problema, partendo dalla causa più comune

Esegua queste soluzioni in ordine. Non passi direttamente a quelle più drastiche. La sequenza è studiata appositamente. Risolve innanzitutto la maggior parte dei casi, con il minimo disagio. L’attivazione dell’audio e l’instradamento rappresentano insieme la causa principale dei malfunzionamenti del microfono Linux. Solo allora la sequenza passa al riavvio del server audio. Dopo ogni modifica, torni al nostro test del microfono o al misuratore di ingresso sul desktop. Verifichi nuovamente la presenza di un segnale prima di proseguire, in modo da sapere sempre quale passaggio ha fatto la differenza.

Riattivi l’audio e instradi con pavucontrol

Installi e apra innanzitutto pavucontrol, poiché questo strumento risolve graficamente i malfunzionamenti più comuni. Passi alla scheda Dispositivi di ingresso. Individui il Suo microfono e verifichi che il pulsante di silenziamento accanto alla barra del livello non sia attivato. Aumenti il volume di ingresso se risulta basso. Controlli il menu a tendina Porta, poiché i portatili spesso espongono sia un microfono interno che un jack per cuffie sotto un unico dispositivo. Ora apra la scheda Registrazione mentre la Sua app è in esecuzione. Ogni app elencata presenta un selettore di dispositivo sulla destra. Indichi esplicitamente all’app che non funziona il microfono corretto. Questa semplice riassegnazione risolve molti casi in cui l’app “funziona ovunque tranne che qui”. Anche le app di conferenza dispongono di un proprio selettore, pertanto imposti il dispositivo anche al loro interno. Le nostre guide per Zoom e Discord illustrano passo dopo passo tali pannelli.

Abiliti l’acquisizione in alsamixer, quindi effettui un test dal terminale

Passi a alsamixer quando il mixer grafico mostra un indicatore piatto. Segua i passaggi per riattivare l’audio e abilitare l’acquisizione descritti sopra: F6 per la scheda, F4 per l’acquisizione, quindi M e Space sul canale Capture. Con il canale pronto, verifichi il percorso hardware direttamente tramite ALSA. Esegua arecord -l per elencare tutti i dispositivi di acquisizione rilevati dal kernel. Se il Suo microfono non compare in questo elenco, il problema è da ricercarsi in un driver o in un collegamento, non nelle impostazioni. Se invece compare, registri un breve clip e lo riproduca con arecord -d 5 test.wav && aplay test.wav. Sentire la Sua voce conferma che il percorso ALSA funziona, il che restringe il problema al server o all’applicazione. Su PipeWire, esegua la stessa operazione con wpctl status per leggere l’ID della sorgente, quindi wpctl set-default <id> e wpctl set-mute <id> 0.

Riavvii il server audio quando l’indicatore rimane bloccato

Supponiamo che il canale non sia in modalità silenziosa, che sia selezionata la sorgente corretta e che il misuratore continui a non muoversi. Probabilmente il server audio si è bloccato. Si tratta di una condizione nota che si verifica dopo la sospensione del sistema, dopo la sostituzione a caldo di un’interfaccia USB o dopo un aggiornamento del driver. Il riavvio del server forza la ricostruzione dell’intero grafico audio senza richiedere un riavvio del sistema. Su PipeWire, esegua systemctl --user restart pipewire pipewire-pulse wireplumber. Su PulseAudio, esegua pulseaudio -k; il demone si riavvierà automaticamente. Durante questa operazione, l’audio subirà una breve interruzione. Consideri questa operazione come il pulsante di reset per uno stack bloccato, non come una procedura di routine. La tabella sottostante mette in relazione i sintomi più comuni con le loro cause tipiche e la soluzione più rapida.

Sintomo	Probabile causa	Soluzione
Indicatore del desktop piatto, tutti i dispositivi	Canale di acquisizione disattivato in ALSA	Riattivare e armare Capture in alsamixer (M, poi Space)
Funziona in un’app, ma non in un’altra	Indirizzamento per app verso la sorgente errata	Riassegnare il dispositivo in pavucontrol › Registrazione
Il microfono non funziona più dopo aver collegato le cuffie	La sorgente predefinita è stata spostata su un nuovo dispositivo	Impostare la sorgente tramite wpctl set-default o pavucontrol
Mancanza del microfono delle cuffie Bluetooth	Il dispositivo è nel profilo A2DP	Passare a HSP/HFP nell’elenco dei profili di pavucontrol
Solo un’app rileva il silenzio	Flatpak oppure la sandbox di Snap blocca il microfono	Concedere l’accesso in Flatseal o tramite flatpak permissions
Il segnale ritorna solo dopo ogni riavvio	Il server audio si è bloccato dopo la sospensione	Riavviare pipewire e wireplumber, oppure eseguire pulseaudio -k

Mantenere affidabile il funzionamento del microfono su Linux

Alcune semplici precauzioni consentono di mantenere il microfono funzionante una volta ripristinato. Mantenga il sistema aggiornato, poiché PipeWire e WirePlumber rilasciano frequentemente correzioni relative al routing e al Bluetooth. Fissi il microfono desiderato come sorgente predefinita, in modo che un auricolare appena collegato non possa sottrargli silenziosamente lo slot. Controlli di tanto in tanto le autorizzazioni su Flatpak e conceda l’accesso al microfono solo alle applicazioni che ne hanno effettivamente bisogno. Quando il microfono deve funzionare su un browser, un’applicazione desktop e il terminale, lo provi in ciascuno di questi contesti. Un microfono che registra perfettamente con arecord potrebbe comunque essere bloccato a un livello superiore, all’interno di una sandbox o di una scheda del browser. Il comportamento varia inoltre a seconda della distribuzione e del desktop, pertanto una soluzione valida per Fedora potrebbe trovarsi in un menu diverso su Ubuntu. Se passa da un computer all’altro, la nostra guida per Chromebook illustra le stesse verifiche su ChromeOS.

Domande frequenti

Come posso sapere se il mio sistema utilizza PipeWire o PulseAudio?

Esegua il comando wpctl status in un terminale. La presenza di un elenco di sink e sorgenti indica che PipeWire è in esecuzione. Se il comando non è presente, esegua pactl info e legga la riga Server Name. Fedora e Ubuntu 22.10 o versioni successive utilizzano per impostazione predefinita PipeWire; le versioni precedenti utilizzano PulseAudio.

Il mio microfono funziona con arecord ma non nelle mie applicazioni. Perché?

Il fatto che la registrazione su arecord funzioni dimostra che il percorso hardware ALSA è corretto. Il problema risiede nel server audio o nell’applicazione. Apra la scheda Registrazione in pavucontrol e imposti l’applicazione sulla sorgente corretta. Se l’applicazione è un Flatpak, verifichi l’autorizzazione per il microfono in Flatseal.

Perché il microfono delle mie cuffie Bluetooth non viene visualizzato?

La modalità A2DP ad alta qualità non supporta il microfono. L’auricolare deve passare al profilo HSP o HFP affinché il microfono a braccio sia disponibile. Apra pavucontrol, individui il dispositivo nell’elenco Configurazione o Profili e selezioni il profilo dell’auricolare. Si noti che la qualità audio potrebbe diminuire una volta effettuata questa operazione.

Come posso riattivare il microfono dal terminale?

Su ALSA, apra alsamixer, prema F4 per visualizzare la schermata di acquisizione, selezioni Capture e prema M per riattivare il microfono. Su PipeWire, individui l’ID della sorgente con wpctl status, quindi esegua wpctl set-mute <id> 0. Un canale di acquisizione ALSA disattivato è la causa più comune di un ingresso silenzioso.

Come posso riavviare l’audio di Linux senza riavviare il sistema?

Su PipeWire, esegua systemctl --user restart pipewire pipewire-pulse wireplumber. Su PulseAudio, esegua pulseaudio -k e il demone si riavvierà automaticamente. L’audio si interrompe per un secondo mentre il server ricostruisce il proprio grafico. Utilizzi questa procedura solo dopo che i controlli di riattivazione dell’audio e di instradamento hanno dato esito negativo.