Codex e a resolução do problema de áudio do meu notebook

O controle do portão, meu celular e um notebook POSITIVO

Hoje eu estava na casa da minha avó e, quando ela foi me deixar em casa, pedi que esperasse até eu conseguir abrir o portão. É que perdi meu controle há umas três semanas e, desde então, preciso ir até uma empresa que fica na parte de trás da rua para pegar outro emprestado.

Enfim, deixei meu celular no banco do carro, fui buscar o controle, abri o portão e voltei para pegar minhas coisas. Peguei minha bela mochila, me despedi e subi.

Foi só depois que percebi: tinha esquecido meu celular no carro.

Bem, acontece. O problema é que eu gosto de receber minha dose diária de dopamina assistindo a Reels no Instagram. E, como estava sem meu belo aparelho telefônico, só me restava o notebook.

Até aí, tudo bem. Afinal, um notebook também reproduz vídeos, tem alto-falantes e, em teoria, deveria ser perfeitamente capaz de fazer algo tão simples quanto reproduzir áudio.

Em teoria.

Meu notebook antigo quebrou há algum tempo e fui obrigado a migrar para um Positivo Vision C15. O problema é que o áudio desse negócio simplesmente não funcionava direito no Linux.

Então, como eu só queria assistir a alguns vídeos, resolvi abrir o notebook e tentar fazer o som funcionar.

A primeira voz saindo do notebook

Recorri ao Codex e expliquei que os alto-falantes não produziam som. Até então, eu conseguia ouvir pelo fone Bluetooth. Autorizei a investigação e, se precisasse, a programação também. Ele começou identificando o equipamento, a versão do Linux Mint e os componentes de áudio. Também consultou referências e o código dos drivers. Antes de alterar as configurações, salvou cópias do que encontrou.

O sistema reconhecia a placa, mas o perfil ativo, que define as entradas e saídas disponíveis, só oferecia o microfone. O alto-falante estava desligado nos controles internos e o notebook indicava um fone conectado na entrada P2. Eu não tinha conectado fone nenhum naquela entrada. Por causa daquele suposto fone, a configuração existente tornava a saída dos alto-falantes indisponível. O Codex preparou outro perfil para contornar a detecção e ajustou os controles.

Uma das primeiras alterações fez o gerenciador de áudio falhar repetidamente. Ele retirou a opção problemática e reiniciou os serviços. Nos primeiros testes, ouvi um ruído estranho, que depois cessou. Pedi que o Codex repetisse a amostra de voz e confirmei: dessa vez, o som vinha dos alto-falantes do notebook.

O Codex salvou o perfil e criou um script para reaplicar os controles quando o gerenciador de áudio iniciasse. Testou também se o script conseguia religar o alto-falante depois de desligá-lo de propósito.

Funcionava até trocar de vídeo

No Brave, o YouTube não reproduzia. No VLC, o vídeo rodava sem áudio. Ao consultar o estado do sistema, o Codex verificou que a reprodução aparecia como ativa, mas os contadores que deveriam acompanhar seu avanço estavam parados.

Desativar a captura do microfone fez o som voltar. O Codex passou a investigar um possível conflito entre entrada e saída. Reativou o microfone e mudou o formato do áudio. Cheguei a confirmar o som, mas depois precisei avisar que continuava travando. Uma tentativa de gravação chegou a produzir um arquivo só com o cabeçalho, sem áudio gravado. Retirar novamente a captura recuperou a reprodução, e o Codex deixou o perfil apenas com saída. Ele me explicou que o uso simultâneo do microfone estava provocando o bloqueio.

Avisei ao Codex que o ajuste recuperava o som do vídeo que já estava aberto, mas bastava reiniciar aquele vídeo ou abrir outro para perdê-lo. Como isso acontecia mesmo com o microfone fora do perfil, aquela explicação não dava conta da falha ao trocar de vídeo.

Como a falha aparecia entre uma reprodução e outra, o Codex configurou a saída para evitar que ela entrasse em pausa ou suspensão automática. Depois desse ajuste, o vídeo já não travava nos meus testes, mas ficava mudo. Ao medir o áudio que o sistema enviava à saída, ele encontrou sinal mesmo enquanto eu não ouvia nada.

Ao desligar e religar o controle do alto-falante, o som voltou numa das tentativas. O Codex criou uma automação para repetir isso quando começasse uma reprodução. Os registros confirmavam a execução dos comandos, mas passei o teste inteiro sem ouvir som. Ele desativou a automação.

A alteração no driver

Nos controles internos, o alto-falante continuava marcado como ligado. O Codex foi conferir o pino elétrico que comandava seu amplificador e cruzou a leitura com o código do driver, a parte do kernel responsável por controlar aquele hardware.

No arquivo sof_es8336.c, o Codex encontrou uma diferença entre parar e retomar a reprodução. Ao parar, o driver podia desligar o amplificador. Ao começar ou retomar, aquele trecho não providenciava sua reativação. O estado que o sistema mantinha sobre a saída podia continuar indicando que ela estava ativa. Assim, retomar um vídeo não garantia que outra parte do driver voltasse a ligar o amplificador. O código original nesses casos era:

case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
    break;

A versão modificada ficou assim:

case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
    /* STOP disables the amplifier without changing the DAPM pin state. */
    if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
        mod_delayed_work(system_dfl_wq, &priv->pcm_pop_work,
                         msecs_to_jiffies(70));
    break;

A alteração reaproveitava uma rotina existente, com atraso de 70 milissegundos, para restaurar o estado do pino do amplificador ao iniciar ou retomar a reprodução. O Codex acrescentou essa chamada no trecho que antes apenas saía sem fazer nada. Ele compilou o módulo alterado, depois de buscar um cabeçalho que faltava. Conferiu também a função no módulo original instalado, para verificar que aquele comportamento aparecia na versão que meu notebook usava.

A primeira tentativa de carregar a versão modificada falhou: uma dependência precisava estar carregada antes. O script recuperou o módulo original, e o som chegou a voltar por alguns segundos. O Codex esclareceu que aquele som vinha do módulo original recarregado. A versão corrigida ainda não tinha entrado em funcionamento.

Depois de resolver a dependência, ele carregou o módulo novo. Testei reiniciar o vídeo, trocar de vídeo e pausar por cerca de dez segundos antes de continuar. Dessa vez, funcionou nos três casos.

Os dois reinícios

Os testes tinham funcionado com o módulo carregado naquela sessão. Para usá-lo também depois de desligar e ligar o aparelho, o Codex instalou a versão corrigida pelo DKMS, que cuida da compilação e instalação desse tipo de módulo. O arquivo original da distribuição ficou preservado. Ele também restaurou o perfil com microfone. Os testes passaram a registrar amostras na captura, embora num nível muito baixo, e confirmei que trocar ou reiniciar vídeos continuava funcionando. A captação da minha voz ainda não estava validada.

Pedi para reiniciar o notebook. Na volta, o módulo corrigido estava carregado, mas o gerenciador de áudio tinha falhado. O script que o Codex tinha criado ainda não conseguia acessar os controles da placa no início da sessão. Ele retornava um erro, que o sistema tratava como falha do gerenciador de áudio inteiro. Quando o Codex executou o mesmo script manualmente, ele funcionou.

O Codex acrescentou uma espera e impediu que essa falha derrubasse o serviço inteiro. Reiniciamos outra vez. Confirmei a voz e testei reproduzir, reiniciar, pausar e trocar vídeos, sem reaplicar os ajustes manualmente. Às 20h43, confirmei também o VLC funcionando. Até essa confirmação, tinham passado cerca de 46 minutos, incluindo os testes e os dois reinícios.

O áudio parou de novo

Depois do registro do histórico, às 20h57, precisei voltar à conversa para avisar que o áudio tinha parado. O Codex coletou o estado da falha antes de tentar recuperar o som. O módulo corrigido continuava carregado, o gerenciador estava ativo e havia um fluxo de reprodução do VLC. A nova consulta encontrou reprodução e captura ativas, ambas sem avançar.

Eu havia tentado usar o microfone antes da falha, embora não pudesse afirmar que uma coisa tivesse causado a outra. Dessa vez, os contadores estavam parados mesmo com o patch do amplificador carregado.

Fechar a captura recuperou o avanço da reprodução. Para investigar essa relação, o Codex preparou testes que paravam e retomavam a entrada enquanto acompanhavam a saída. Precisou corrigir também o programa de teste, que inicialmente indicava falha mesmo quando os números mostravam avanço. Depois, percebeu que depender dos aplicativos abertos não garantia que houvesse reprodução e captura durante o teste inteiro. Passou a abrir seus próprios fluxos, reproduzindo silêncio e descartando a captura. Uma configuração que parecera funcionar não passou nesse ensaio. O Codex também precisou considerar que reiniciar a reprodução podia zerar seu contador sem significar um travamento.

Uma configuração para coordenar os dois fluxos deu resultados melhores. Confirmei que tentar usar o microfone já não interrompia a reprodução naquele teste. Minha voz, porém, continuava sem ser reconhecida. O Codex voltou a examinar por onde o sistema tentava captar o som e quais controles usava para isso.

A configuração só de reprodução

Pedi que ele se concentrasse na reprodução e deixasse o microfone de lado. Ele retirou a entrada interna do perfil, desligou seu controle no inicializador e arquivou as configurações experimentais de sincronização. Manteve o patch do amplificador e os ajustes da saída.

Depois da mudança, avisei que estava sem áudio e com o vídeo travado. Na consulta do Codex, os contadores da reprodução avançavam e a captura estava fechada, mas o fluxo da mídia não aparecia. Reiniciar apenas o gerenciador não havia bastado. O Codex reiniciou o conjunto dos serviços de áudio e pediu que eu recarregasse a aba ou reabrisse a mídia para restabelecer a reprodução.

Às 21h18, confirmei: ouvi a voz e a mídia voltou com som. O microfone interno ficou fora do perfil utilizado. A causa completa do bloqueio entre entrada e saída continuou sem confirmação. Depois da última alteração, não houve outro reinício do notebook nem teste prolongado para verificar a estabilidade.