Como Resolvi o Problema de Alternar Áudio no Ubuntu (E o que Aprendi sobre a Arquitetura do Linux)

Patrik Rufino — Sat, 01 Aug 2026 17:27:21 +0000

Se você já tentou usar conectados mais de um dispositivo de saída de audio no Linux, talvez já tenha se deparado com o desafio de manter os 2 conectados e alternar entre eles.

No meu caso tenho um headseat conectado no painel traseiro da placa-mãe (naquela famosa saída P2 / Jack de 3,5 mm verde) e uma caixinha de som na saída do gabinete (no painel frontal). Quando estou no meu ambiente de lazer Windows...alterno de maneira simples entre as saídas de som.
No Ubuntu, porém, as coisas não foram tão simples.

Neste artigo, quero compartilhar como foi o meu processo para resolver esse problema, as pesquisas frustradas no Google e a "virada de chave" que me fez entender como o Linux realmente gerencia o hardware de áudio.

1. A Pesquisa Clássica e o Primeiro Obstáculo

A minha jornada começou com buscas bem comuns no Google:

"Como usar dois dispositivos de áudio no Ubuntu"
"Como alternar entre headseat e caixa de som sem desconectar o cabo no Linux"
"Ubuntu som não sai na caixa de som quando o headseat tá plugado"

A primeira resposta que os fóruns dão é sempre a mesma: "Vá em Configurações -> Som e mude o Dispositivo de Saída".

Tão óbivio, né?

Eu já fazia isso, selecionava o headseat (Line Out) e... nada de som. Mas ai com mais calma, notei que o indicador gráfico de volume (a barrinha no painel) se mexia como se o som estivesse tocando normalmente, mas headseat continuava mudo. A única forma de fazer o headseat funcionar era desconectar o cabo da caixa de som no gabinete.

2. A Falsa Promessa do Pavucontrol

Pesquisando mais um pouco, encontrei outra dica recorrente em tópicos do Reddit e do fórum do Ubuntu: "Instala o Pavucontrol (Controle de Volume do PulseAudio), que ele te dá controle total sobre as portas".

Instalei:

sudo apt install pavucontrol

Abri o aplicativo e lá estavam as duas portas físicas listadas com precisão: Headphones e Line Out. Tentei trocar por lá... e o problema persistiu! O áudio ia para para a caixa, mas quando eu mandava para o headseat, o som simplesmente sumia.

Nesse ponto, me fiz a seguinte pergunta:

"Se a interface gráfica mostra que o som está tocando e o indicador de volume mexe, o sistema operacional ACHA que está enviando áudio. Se o som não chega no headset, onde é que ele está ficando preso?"

3. O Diagnóstico: Entendendo a Pilha de Áudio do Linux

Procurando entender o motivo dessa contradição, acabei caindo no artigo Sound System na Arch Wiki (que é praticamente a bíblia de documentação no ecossistema Linux). Foi lendo sobre a arquitetura que a ficha caiu: o gerenciamento de som no Linux não é um bloco único, mas sim uma pilha dividida em camadas.

[ Sua Aplicação: Navegador / Jogo / Spotify ]
                     ↓
[ Interface Gráfica: GNOME Settings / Pavucontrol ]  <-- (Disse que estava tudo OK)
                     ↓
[ Servidor de Áudio: PipeWire / PulseAudio ]         <-- (Estava enviando o som)
                     ↓
[ Camada do Kernel: ALSA (Drivers da Placa) ]       <-- (O BLOQUEIO ESTAVA AQUI!)

O GNOME (Interface) e o PipeWire (Servidor de Áudio) trabalham na camada do usuário. O PipeWire pegava o áudio do aplicativo e tentava entregar para a porta certa. Por isso o gráfico de volume mexia!

O ALSA (Advanced Linux Sound Architecture) é a camada mais baixa, que fica dentro do Kernel do Linux e conversa direto com o chip da placa de som (Realtek, AMD, Intel).

Navegando mais a fundo no artigo sobre a Advanced Linux Sound Architecture na Arch Wiki e na documentação do Kernel sobre o driver HD-Audio, entendi o que estava acontecendo: o ALSA possui uma instrução chamada Auto-Mute Mode.

O que é o Auto-Mute?

Historicamente, o ALSA foi desenhado com foco em notebooks. Em um notebook, quando você espeta um headseat, você quer que os alto-falantes internos fiquem mudos na hora. O ALSA faz isso direto no chip de som: se ele detecta o pino conectado na tomada do headseat, ele corta a energia/sinal da saída da caixa de som.

No meu PC desktop, o ALSA achou que meu headseat deveria ser mutado só porque espetei um outro dispositivo no painel frontal

4. A Solução que funcionou pra mim

Com o diagnóstico correto em mãos, sair do problema foi surpreendentemente simples.

Passo 1: Abrindo o mixer do ALSA Abri o terminal (Ctrl + Alt + T) e chamei a ferramenta de texto do ALSA:

alsamixer

Passo 2: Desativando o bloqueio Apertei a tecla F6 para escolher a minha placa de som dedicada/integrada (no meu caso, a HD-Audio Generic / Ryzen).

Usei a seta para a direita até achar a coluna chamada Auto-Mute Mode.

Usei a seta para baixo para mudar de Enabled para Disabled.

Ficando assim:

Apertei Esc para sair.

E a mágica aconteceu: No mesmo segundo, ao alternar entre o headseat e a caixa pelas configurações normais do Ubuntu, o som passou a trocar instantaneamente, sem precisar tirar nenhum cabo do PC.

Passo 3: Salvando a alteração no Kernel Como o alsamixer altera o estado na memória temporária, e no meu caso queria para salvar essa configuração permanentemente no arquivo do sistema (/var/lib/alsa/asound.state), descobri outro comando:

sudo alsactl store

Conclusão

O que parecia uma falha do Ubuntu ou falta de drivers adequados tratava-se, na verdade, de um comportamento do Kernel trabalhando exatamente como foi projetado — só que aplicado ao cenário errado (um Desktop em vez de um Notebook).

Compreender a separação entre a interface gráfica, o servidor de som e a camada de hardware do Kernel foi a chave para chegar ao "momento Eureka" sem precisar recorrer a gambiarras físicas.``

Mas e por aí? Você já passou por alguma dor de cabeça parecida com áudio no Linux,