O microfone não funciona no Linux: como testá-lo e resolver o problema

No Linux, um microfone que não funciona está, na maioria das vezes, silenciado e não avariado. O canal de captura ALSA vem desativado em muitas distribuições, pelo que a cápsula funciona, mas o controlador não transmite nada. Uma fonte predefinida incorreta ou uma aplicação confinada a uma sandbox explica a maioria dos restantes casos. O sinal percorre uma pilha de camadas: o controlador do kernel ALSA, depois o PipeWire ou o PulseAudio, e, por fim, a própria aplicação. Qualquer camada pode interromper o sinal, e o resultado é sempre o mesmo: silêncio. A correção adequada depende inteiramente da camada em que ocorre o bloqueio. Este guia identifica essa camada e, em seguida, corrige-a através de passos gráficos e no terminal. Comece por realizar um teste rápido ao microfone ou utilize o medidor de entrada do ambiente de trabalho para verificar o hardware. Em seguida, verifique se a sua distribuição utiliza o PipeWire ou o PulseAudio, uma vez que os comandos abaixo variam consoante essa resposta.

O microfone do Linux não funciona: lista de verificação para resolução rápida

✓	Faça o teste com o nosso teste de microfone ou com o medidor de entrada de som do ambiente de trabalho.
✓	Desative o silenciamento do canal Capture em alsamixer e aumente o seu nível.
✓	Defina a entrada correta em pavucontrol (ou wpctl no PipeWire).
✓	Confirme se o seu utilizador está no grupo audio.
✓	Reinicie o áudio: systemctl --user restart pipewire pipewire-pulse ou pulseaudio -k.

Teste o seu microfone do Linux em menos de um minuto

Confirme se o microfone capta som antes de alterar qualquer configuração. A solução para «sem sinal» difere completamente da solução para «há sinal, mas ninguém me consegue ouvir». Um medidor de entrada em tempo real fornece a resposta mais rápida e fiável, pois reage à sua voz em tempo real. Um ciclo de gravação e reprodução pode ocultar erros na seleção do dispositivo, por isso comece por utilizar um medidor. Abra o nosso teste de microfone online e permita o acesso quando o navegador o solicitar. Agora fale normalmente. Se o indicador de nível se mover enquanto fala, o microfone, o controlador e o servidor de som estão todos a funcionar corretamente. O problema reside, então, a um nível superior, no encaminhamento ou numa aplicação específica. Se o medidor permanecer estável, o sinal está bloqueado ou foi selecionada a entrada errada.

Teste o seu microfone →

O seu ambiente de trabalho também disponibiliza o microfone de forma nativa. No GNOME, abra Definições › Som › Entrada e selecione o seu dispositivo; a barra de Nível de Entrada deve mover-se à medida que fala. No KDE Plasma, abra Definições do Sistema › Áudio e observe o medidor ao lado do dispositivo de gravação. Suponha que a barra se move aqui, mas que uma aplicação continua sem captar qualquer som. Provou, assim, que a falha é específica da aplicação e não do sistema em geral; por isso, avance para as secções sobre encaminhamento e permissões abaixo. A tabela indica os locais gráficos onde o seu ambiente de trabalho revela o microfone e o que a leitura em cada um deles confirma.

Onde procurar	Caminho	O que isso confirma
Medidor de entrada do GNOME	Definições › Som › Entrada	Se o sistema recebe um sinal e de que dispositivo
Painel de áudio do KDE	Definições do Sistema › Áudio	O dispositivo de gravação ativo e o seu encaminhamento por aplicação
Controlo de volume	pavucontrol › Dispositivos de Entrada	Estado de silenciamento, ganho e porta de hardware selecionada
Separador Gravação	pavucontrol › Gravação	Qual a aplicação que captura a partir de qual dispositivo, em tempo real

Conheça o seu servidor de som antes de proceder à resolução de problemas

O áudio no Linux está organizado em camadas, e a correção adequada depende da camada em que a falha se encontra. Na base está o ALSA, o controlador ao nível do kernel que comunica com a placa de som. Acima deste, funciona um servidor de som que mistura fluxos e os encaminha entre aplicações. Dois servidores dominam este cenário. As distribuições modernas incluem o PipeWire. O Fedora foi o primeiro a adotá-lo, e o Ubuntu utiliza-o por predefinição desde a versão 22.10. O PipeWire executa uma camada de compatibilidade denominada pipewire-pulse, pelo que as ferramentas mais antigas continuam a funcionar sem alterações. As versões mais antigas e algumas configurações conservadoras ainda executam o PulseAudio. Ambos os servidores assentam no ALSA, e um canal silenciado no ALSA silenciará qualquer um deles.

Identifique o seu servidor antes de perder tempo na ferramenta errada. Execute wpctl status num terminal. Uma listagem clara de sinks e sources significa que o PipeWire está ativo. Se o comando não estiver presente, é muito provável que esteja no PulseAudio; confirme com pactl info. Isto é importante porque os comandos divergem. O PipeWire é gerido por wpctl, enquanto o PulseAudio utiliza pactl. A ferramenta gráfica pavucontrol funciona com ambos, uma vez que o pipewire-pulse responde às mesmas chamadas. A tabela abaixo resume as ferramentas principais e a função de cada uma.

Ferramenta	Tipo	O que faz
pavucontrol	Gráfica	Desativa o silenciamento das entradas, define o ganho, seleciona a porta e apresenta as rotas de gravação por aplicação
alsamixer	Terminal (TUI)	Controla a placa ALSA em modo bruto: silencia e ativa a captura, e ajusta o ganho de hardware
arecord / aplay	Terminal	Lista os dispositivos de captura e grava ou reproduz um ficheiro diretamente através do ALSA
wpctl	Terminal	Lista os dispositivos do PipeWire, define a fonte predefinida e silencia ou reativa o som

Por que razão um microfone que funciona continua a ficar em silêncio no Linux

Um canal de captura ALSA silenciado é o principal culpado

ALSA controla cada canal de captura de forma independente, e um deles pode ser silenciado por baixo de todos os outros. Quando isso acontece, o medidor do ambiente de trabalho indica zero, independentemente do volume do software que se aumente. Esta única condição causa mais microfones «avariados» no Linux do que qualquer falha de hardware. O problema é que, muitas vezes, isso não é visível no misturador gráfico. A solução encontra-se no alsamixer, um misturador de terminal que acede diretamente à placa de som. Inicie-o e, em seguida, prima F6 para selecionar a sua placa de som. Prima F4 para alternar para a vista de captura. Destaque o canal Capture com as setas do teclado. Se aparecer MM por baixo da barra, significa que está silenciado; prima M para o ativar. Um canal de captura também tem de estar ativado. Prima Space no item selecionado até que apareça CAPTURE a vermelho e, em seguida, aumente o nível com a seta para cima. Muitos portáteis também apresentam aqui um controlo Internal Mic Boost, que vem definido para zero de fábrica. Aumentar este valor reativa um microfone que parecia não funcionar.

Fonte predefinida incorreta e encaminhamento defeituoso

O servidor de som escolhe uma fonte predefinida, e nem sempre escolhe aquela que pretende. Ligue uns auscultadores USB, uma webcam com microfone incorporado ou um dispositivo de captura HDMI, e o servidor poderá promovê-lo imediatamente. Os erros de encaminhamento também se escondem no interior de aplicações individuais. O PipeWire e o PulseAudio permitem que cada programa grave a partir de um dispositivo diferente, definido por fluxo. Uma aplicação pode, portanto, estar direcionada para uma fonte que não produz nada, enquanto a configuração predefinida do sistema funciona. O separador Gravação em pavucontrol revela isto diretamente, listando todas as aplicações que estão atualmente a capturar e o dispositivo que utilizam. Suspeite primeiro de um problema de encaminhamento sempre que o microfone funcionar num programa, mas não noutro. Os auscultadores Bluetooth acrescentam uma complicação adicional. Um auscultador com o perfil A2DP de alta qualidade não possui qualquer microfone. O sistema tem de o mudar para o perfil HSP/HFP antes de o microfone de haste aparecer, e a qualidade de áudio diminui quando isso acontece.

Permissões, grupos e aplicações em sandbox

O controlo de acesso bloqueia o microfone de formas que não geram qualquer mensagem de erro. Historicamente, um utilizador tinha de pertencer ao grupo audio para aceder aos dispositivos de som. A maioria dos ambientes de trabalho modernos gere isto através da sessão, mas uma instalação mínima ou de servidor pode ainda assim exigi-lo. O sandboxing é o problema mais recente e de maior dimensão. As aplicações empacotadas como Flatpak ou Snap são executadas dentro de uma camada de confinamento que pode negar o acesso ao microfone, mesmo quando o resto do sistema funciona. A aplicação recebe então silêncio, sem qualquer mensagem de erro. Pode verificar e conceder estas permissões através de Flatseal, um editor gráfico para portais Flatpak, ou a partir do terminal com flatpak permissions. Os navegadores adicionam a sua própria camada separada por cima. Um site tem de ser permitido no navegador, independentemente do estado do sistema. Os nossos guias Firefox e Chrome abordam essa solicitação no navegador em pormenor.

Resolução do problema, começando pela causa mais comum

Siga estas soluções por ordem. Não passe diretamente para as mais drásticas. A sequência é deliberada. Resolve primeiro a maioria dos casos, com o mínimo de perturbação. A ativação do som e o encaminhamento, em conjunto, são responsáveis pela maioria das falhas do microfone Linux. Só então é que a sequência avança para o reinício do servidor de som. Após cada alteração, volte ao teste do microfone ou ao medidor de entrada do seu ambiente de trabalho. Verifique novamente se existe sinal antes de prosseguir, para que saiba sempre qual foi o passo que fez a diferença.

Desativar o silenciamento e ajustar o encaminhamento com o pavucontrol

Instale e abra primeiro o pavucontrol, pois este programa corrige as falhas mais comuns de forma gráfica. Aceda ao separador Dispositivos de Entrada. Localize o seu microfone e confirme se o botão de silenciamento ao lado da barra de nível não está ativado. Aumente o volume de entrada se este estiver baixo. Verifique o menu suspenso Porta, uma vez que os portáteis costumam apresentar tanto um microfone interno como uma tomada para auscultadores sob um único dispositivo. Agora, abra o separador Gravação enquanto a sua aplicação estiver ativa. Cada aplicação listada tem um seletor de dispositivo à direita. Indique explicitamente à aplicação problemática o microfone correto. Esta simples reatribuição resolve muitos relatos do tipo «funciona em todo o lado, menos aqui». As aplicações de conferência também têm o seu próprio seletor, pelo que deve definir o dispositivo também nelas. Os nossos guias para Zoom e Discord abordam esses painéis passo a passo.

Ative a captura em alsamixer e, em seguida, teste a partir do terminal

Aceda a alsamixer quando o misturador gráfico apresentar um medidor plano. Siga os passos para ativar o som e a captura descritos acima: F6 para a placa, F4 para a captura e, em seguida, M e Space no canal de captura. Com o canal ativado, verifique o caminho do hardware diretamente através do ALSA. Execute arecord -l para listar todos os dispositivos de captura detetados pelo kernel. Se o seu microfone não constar aqui, a falha deve-se a um problema de controlador ou de ligação, e não a uma questão de configurações. Se aparecer, grave um pequeno excerto e reproduza-o com arecord -d 5 test.wav && aplay test.wav. O facto de ouvir a sua voz confirma que o caminho ALSA funciona, o que restringe a falha ao servidor ou à aplicação. No PipeWire, execute o mesmo procedimento com wpctl status para ler o ID da fonte e, em seguida, wpctl set-default <id> e wpctl set-mute <id> 0.

Reinicie o servidor de som quando o medidor permanecer congelado

Suponha que o canal esteja com o silenciamento desativado, que a fonte correta esteja selecionada e que o medidor continue sem se mover. O servidor de som provavelmente ficou bloqueado. Este é um estado conhecido após a suspensão, após a troca a quente de uma interface USB ou após uma atualização do controlador. O reinício do servidor força a reconstrução de todo o gráfico de áudio sem necessidade de reiniciar o sistema. No PipeWire, execute systemctl --user restart pipewire pipewire-pulse wireplumber. No PulseAudio, execute pulseaudio -k, e o daemon será reiniciado automaticamente. O áudio será interrompido brevemente durante este processo. Considere isto como o botão de reinicialização para uma pilha bloqueada, e não como um passo de rotina. A matriz abaixo relaciona os sintomas comuns com a sua causa habitual e a solução mais rápida.

Sintoma	Causa provável	Solução
Medidor do ambiente de trabalho sem variação, em todos os dispositivos	Canal de captura silenciado em ALSA	Desative o silenciamento e ative a captura em alsamixer (M, seguido de Space)
Funciona numa aplicação, mas não noutra	Encaminhamento por aplicação para a fonte errada	Reatribua o dispositivo em pavucontrol › Gravação
O microfone deixou de funcionar após ligar uns auscultadores	A fonte predefinida foi transferida para um novo dispositivo	Defina a fonte em wpctl set-default ou pavucontrol
Falta o microfone dos auscultadores Bluetooth	O dispositivo está no perfil A2DP	Altere-o para HSP/HFP na lista de perfis do pavucontrol
Apenas uma aplicação ouve silêncio	Flatpak ou a área restrita do Snap bloqueia o microfone	Conceda acesso em Flatseal ou através de flatpak permissions
O sinal só regressa após cada reinício	O servidor de som ficou bloqueado após a suspensão	Reinicie o pipewire e o wireplumber, ou execute pulseaudio -k

Manter o microfone do Linux a funcionar de forma fiável

Existem alguns hábitos que ajudam a manter o microfone a funcionar assim que este volta a funcionar. Mantenha o sistema atualizado, uma vez que o PipeWire e o WirePlumber lançam frequentemente correções relacionadas com o encaminhamento e o Bluetooth. Fixe o microfone que pretende como fonte predefinida, para que uns auscultadores recém-ligados não possam ocupar silenciosamente o slot. Verifique periodicamente as suas permissões em Flatpak e conceda acesso ao microfone apenas às aplicações que dele necessitem. Quando o microfone tiver de funcionar num navegador, numa aplicação de ambiente de trabalho e no terminal, teste-o em cada um desses locais. Um microfone que grava na perfeição com o comando arecord pode ainda assim ser bloqueado num nível superior, dentro de uma sandbox ou de um separador do navegador. O comportamento também varia consoante a distribuição e o ambiente de trabalho; assim, uma correção do Fedora pode encontrar-se num menu diferente no Ubuntu. Se alternar entre máquinas, o nosso guia Chromebook aborda as mesmas verificações em ChromeOS.

Perguntas frequentes

Como posso saber se o meu sistema utiliza PipeWire ou PulseAudio?

Execute wpctl status num terminal. Uma listagem de sinks e sources significa que o PipeWire está em funcionamento. Se o comando não estiver presente, execute pactl info e verifique a linha Server Name. O Fedora e o Ubuntu 22.10, ou versões mais recentes, utilizam o PipeWire por predefinição; as versões mais antigas utilizam o PulseAudio.

O meu microfone funciona com arecord, mas não nas minhas aplicações. Porquê?

O facto de a captura em arecord funcionar comprova que o caminho de hardware ALSA está correto. A falha reside no servidor de som ou na aplicação. Abra o separador Gravação em pavucontrol e indique à aplicação a fonte correta. Se a aplicação for um Flatpak, verifique a permissão do microfone em Flatseal.

Porque é que o microfone dos meus auscultadores Bluetooth não aparece?

O modo A2DP de alta qualidade não suporta microfone. Os auscultadores têm de mudar para o perfil HSP ou HFP para que o microfone de haste fique disponível. Abra pavucontrol, localize o dispositivo na lista de configuração ou de perfis e selecione o perfil dos auscultadores. Tenha em conta que a qualidade de áudio poderá diminuir ao fazê-lo.

Como posso ativar o microfone a partir do terminal?

No ALSA, abra alsamixer, prima F4 para aceder à vista de captura, selecione Capture e prima M para ativar o som. No PipeWire, localize o ID da fonte com wpctl status e, em seguida, execute wpctl set-mute <id> 0. Um canal de captura ALSA silenciado é a causa mais comum de uma entrada sem som.

Como posso reiniciar o áudio do Linux sem reiniciar o sistema?

No PipeWire, execute systemctl --user restart pipewire pipewire-pulse wireplumber. No PulseAudio, execute pulseaudio -k e o daemon reinicia-se automaticamente. O áudio é interrompido durante um segundo enquanto o servidor reconstrói o seu gráfico. Utilize esta opção apenas após as verificações de reativação do som e de encaminhamento terem falhado.