☰

ALSA, PulseAudio e Intel HDA PCH sem som

tag-icon • tag-icon linux pulseaudio alsa manjaro
ALSA, PulseAudio e Intel HDA PCH sem som

Tenho apenas uma placa de som on-board que é uma Realtek ALC298 e não preciso de configurações de som avançadas. Apenas um sistema de som funcional para ouvir vídeos do youtube, assistir filmes etc... Até agora acompanhei muitos artigos online. Para resumir tudo o que tentei:

  1. Descubra se os canais estão silenciados. Eu usei alsamixere também verifiquei o pavucontrol, ambos não mostram canais silenciados. Repeti esta etapa quando estava na 3ª etapa (leia abaixo) e novos canais apareciam de vez em quando, mas no final das contas não havia som.

  2. Descubra se é ALSA ou apenas problema do PulseAudio. Então eu usei aplay -l:

**** Lista de dispositivos de hardware de REPRODUÇÃO ****
placa 0: PCH [HDA Intel PCH], dispositivo 0: ALC298 Analógico [ALC298 Analógico]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0
placa 0: PCH [HDA Intel PCH], dispositivo 3: HDMI 0 [HDMI 0]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0
placa 0: PCH [HDA Intel PCH], dispositivo 7: HDMI 1 [HDMI 1]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0
placa 0: PCH [HDA Intel PCH], dispositivo 8: HDMI 2 [HDMI 2]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0
placa 0: PCH [HDA Intel PCH], dispositivo 9: HDMI 3 [HDMI 3]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0
placa 0: PCH [HDA Intel PCH], dispositivo 10: HDMI 4 [HDMI 4]
  Subdispositivos: 1/1
  Subdispositivo #0: subdispositivo #0

A partir daí usei um arquivo wav formatado em PCM aplay -D plughw:0,0 test.wavque deu:

Reproduzindo WAVE 'test.wav': Little Endian de 32 bits assinado, taxa de 44100 Hz, estéreo

Mas nada! nenhum som em lugar nenhum, alto-falantes ou fones de ouvido. Concluí que é um problema do ALSA e não do PulseAudio, mas tenho uma dúvida, pois o daemon do PulseAudio estava em execução durante esta etapa. Como uma observação interessante, quando eu estava realizando esta etapa, as configurações de som do gnome mostraram as barras de som se movendo como se algo estivesse tocando:D

  1. Eu encontrei umartigo no site do kernelsobre áudio HDA ​​e a capacidade do kernel de reconfigurar dinamicamente o codec de áudio sem precisar reinicializar a máquina. Consegui encontrar e usar o hdajackretaskutilitário que faz parte do alsa-toolsrepo e ele me forneceu uma GUI. Este utilitário grava as modificações dos pinos no user_pin_configsarquivo (para sua informação, verificou isso manualmente após a reinicialização). No entanto, não consegui descobrir a combinação certa de reatribuições de pinos. A seguir estão os pinos que podem ser reatribuídos:
0x12
0x13
0x14
0x17
0x18
0x19
0x1a
0x1d
0x1e
0x1f
0x21
  1. Minha ideia aqui era basicamente usar ALC269modelo, pois vi umarquivo de patch interessanteao pesquisar no Google. O link é para rasp pi, mas achei que vale a pena tentar ver que ALC269é ummodelo de áudio HDA ​​do kernel compatível. Embora isso não tenha mudado nada, talvez alguém possa se beneficiar com isso.

Qualquer ajuda é apreciada aqui. Estou muito além das minhas habilidades em Linux.

PS: manjaro, linux56 embora todas as distribuições tenham o mesmo problema com a placa de som. Instalei quase todas as distros nos últimos meses, esperando que o som funcionasse.

Editar 1

Adicionado umpastade alsa-info.shpara mais informações.

Responder1

Boas notícias! Um usuário muito inteligente do Arch chamado ronincoder descobriu uma solução para o conector de fone de ouvido. Trabalhei com o ronincoder para fazer um patch do kernel [1] e nosso patch chegou à versão 5.7 do kernel! Também foi aplicado ao kernel 5.4 LTS. Inicializei 5.7.2 e 5.4.46 e o ​​áudio do fone de ouvido está alto e claro. :)

Funciona para você? Deveria se você tiver um Samsung Notebook 9 Pro NP930SBE-K01US ou NP930MBE-K04US (o do ronincoder é o primeiro, o meu é o último). Você pode verificar o modelo do seu laptop executando alsa_info.sh e olhando em "Nome da placa". O codec Realtek ALC298 no NP930SBE-K01US e NP930MBE-K04US identifica-se com "Subsystem Id" 0x144dc169 e 0x144dc176, respectivamente. Se snd_hda_intel vir algum desses IDs, ele implementará a correção.

E os alto-falantes? Eu relatei o problema de falta de som nos alto-falantes internos no bugzilla do kernel [2]. O mantenedor de som do Linux, Jaroslav Kysela, especula que pode haver alguns amplificadores conectados ao codec HDA que não são inicializados pelo BIOS e, portanto, não estão ativos no Linux. Ele sugere descartar a comunicação do codec para o driver do Windows usando QEMU. Poderíamos então analisar o dump e reproduzir a comunicação no Linux usando Early Patching [3] ou escrevendo outro patch do kernel. Já se passou um mês desde que Jaroslav fez essa sugestão e fiz alguns progressos, mas ainda não tenho uma boa cagada. Por favor, junte-se à discussão no kernel bugzilla se quiser me ajudar. ^^

[1] Para referência, nosso patch chegou à árvore de Linus como commit 14425f1f521f (ALSA: hda/realtek: Add quirk for Samsung Notebook). [2]https://bugzilla.kernel.org/show_bug.cgi?id=207423 [3]https://www.kernel.org/doc/html/v4.17/sound/hd-audio/notes.html#early-patching

Responder2

No elementaryOS (baseado no Ubuntu 20.04), nenhum som no meu MacBook Pro 2012 foi corrigido editando o arquivo de configuração sudo vim /etc/modprobe.d/alsa-base.confe substituindo

options snd-hda-intel model=generic

por

# options snd-hda-intel model=generic
options snd-hda-intel probe_mask=1

Mais detalhes explicativos:

Nota: Não sei por que ocorreu o problema de falta de som ou o que mudou antes, já que estava funcionando inicialmente após a instalação.

No entanto, consultando pacmd list-cardsno Terminal, a saída mudou de (antes da correção):

ports:
    analog-input-mic: Mikrofon (priority 8700, latency offset 0 usec, available: unknown)
        properties:
            device.icon_name = "audio-input-microphone"
    analog-output-speaker: Lautsprecher (priority 10000, latency offset 0 usec, available: unknown)
        properties:
            device.icon_name = "audio-speakers"
    analog-output-headphones: Kopfhörer (priority 9900, latency offset 0 usec, available: no)
        properties:
            device.icon_name = "audio-headphones"
    iec958-stereo-output: Digitalausgang (S/PDIF) (priority 0, latency offset 0 usec, available: unknown)
        properties:

para (após correção):

ports:
    [Out] Speaker: Speaker (priority 100, latency offset 0 usec, available: unknown)
        properties:
            
    [Out] Headphones: Headphones (priority 200, latency offset 0 usec, available: no)
        properties:
            
    [In] Mic2: Headphones Stereo Microphone (priority 200, latency offset 0 usec, available: unknown)
        properties:

(Observe a diferença na sintaxe aqui.)

Além disso, a saída de sudo vim aplay -lalterada de (antes da correção):

Karte 0: PCH [HDA Intel PCH], Gerät 0: Generic Analog [Generic Analog]
  Sub-Geräte: 0/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 1: Generic Digital [Generic Digital]           
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

para (após correção):

Karte 0: PCH [HDA Intel PCH], Gerät 0: CS4206 Analog [CS4206 Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 1: CS4206 Digital [CS4206 Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0

Responder3

Então o problema aqui é que o ALC298 da Realtek tem um requisito de barramento diferente que é I2S. A partir do linux56, o codec de áudio I2S não é suportado e este parece ser o novo padrão. Lenovo, Samsung e Huawei parecem usar placas de som com este novo padrão I2S e há muitos tópicos/tópicos não resolvidos que encontrei abandonados em relação a esse assunto.

Encontrei uma solução alternativa para consertar os fones de ouvido que funcionou para mim e para outra pessoa que estava usando um Samsung Notebook Pro 9. A solução usa um recurso de kernel chamado "Early Patching" para substituir opcionalmente os pinos padrão, verbos, modelo e outros específicos do ALSA atributos. Você pode encontrar informações completas, incluindo um patch de kernel personalizado alternativo emFóruns do Arch Linux.

Responder4

Experimente estas instruções abaixo. Uma vez que eles poderiam corrigir um problema semelhante no meu sistema.

  1. Você executa o comando "aplay", mas não ouve nada. Que tal executar o comando "sudo aplay"? Se o ALSA estiver funcionando, você poderá ouvir o som.

  2. Acho que o pulseaudio está rodando no sistema do seu sistema. Mas pode haver alguns problemas de compatibilidade entre o driver alsa-lib e snd-hda-intel.

    $pacmd cartões de lista

Verifique os resultados em "portas". Se você não consegue ver algo relacionado ao alto-falante, significa que a placa de som não pode ser reconhecida pelo pulseaudio.

  1. Edite o arquivo "/usr/share/alsa/ucm2/HDA-Intel/HDA-Intel.conf". Se você vir uma string vazia após "Define.Use", basta inserir "3" na string. Então salve-o.

  2. Reinicie sua máquina. Se você ainda não conseguir nenhum som, verifique se é "Saída Dummy" como sua placa de som. Nesse caso, adicione "options snd-hda-intel model=generic" ao final de "/etc/modprobe.d/alsa-base.conf".

Este problema é causado principalmente por "HDA-Intel.conf". Eu realmente não entendo por que o desenvolvedor mantém a string "Define.Use" vazia.

informação relacionada