Logo Hardware.com.br
Thiagohg
Thiagohg Membro Junior Registrado
126 Mensagens 8 Curtidas

[Resolvido] [Arch] Sem som no Flash

#1 Por Thiagohg 25/06/2011 - 21:59
Boa noite a todos,

Estou com uma nova instalação do Arch (após ter conseguido finalmente instalar com FakeRAID) no meu PC principal. Tudo funcionando perfeitamente, exceto um problema: o som do flash não funciona. Apenas no flash. Ou seja, nada de vídeo com som no youtube frown.png. Nesse momento, estou ouvindo música no Amarok, e os sons de interface do KDE funcionam perfeitamente. Gostaria de saber se alguém poderia me ajudar.


Informações de software:

Arquitetura: amd64/x86_64 (64 bits)
Kernel 2.6.39-ARCH
KDE 4.6.3
Navegador: Chromium 12.0.742.100
Adobe Flash Player 10.3.181.26 para arquitetura IA-32 (32 bits)
Servidor de som: Phonon 4.5.0, com backend GStreamer 0.10.34
Driver de som: ALSA

Informações de hardware:

Core i7 930 2.8 GHz
Memória DDR3 6GB
Placa de som: 00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller - onboard
Placa mãe: ASUS P6X58D-E


Soluções que encontrei na internet e não funcionaram:

1) reinstalar o flash
2) descarregar módulos do OSS e colocá-los em blacklist
3) instalar lib32-alsa-oss
4) instalar lib32-libflashsupport
5) verificar controles de volume (como falei, estou ouvindo música nesse momento)

Observação: lib32-alsa-lib e lib32-alsa-plugins foram instalados como dependência de flashplugin

Obrigado pela ajuda, qualquer informação extra que seja necessária é só pedir.
Responder
m45t3r
m45t3r Veterano Registrado
986 Mensagens 57 Curtidas
#7 Por m45t3r
25/06/2011 - 22:48
Thiagohg disse:
Correto. Sem PulseAudio, apenas Phonon com backend GStreamer.


PulseAudio? Então é culpa do OSS.

Explicação rápida: o Flash por padrão usa o OSS como saída de áudio, mas como o ALSA tem um layer de compatibilidade com o OSS isso não chega a ser um problema. Mas quando você instala o PA o layer de compatibilidade do OSS transpassa o PA e deixa o sistema inteiro sem som (mas com som no Flash) ou o contrário.

Solução:
Tem duas, a mais simples é mandar o layer de compatibilidade do OSS pro espaço:
# rmmod snd_pcm_oss

Depois edite o /etc/rc.conf, adicionando o seguinte na parte de MODULES:
MODULES=(!snd_pcm_oss)

Qualquer programa que use o OSS exclusivamente não vai funcionar mais, a não ser que você use o comando:
$ padsp

Mas não lembro de nenhum programa que ainda use somente o OSS.

Segunda solução é instalar o osspd, uma camada de compatibilidade com o OSS no espaço de usuário:
https://wiki.archlinux.org/index.php/Pulseaudio#osspd

P.S.: ok, sem PA? Tente remover o módulo só para desencargo de consciência, apesar que provavelmente não vai resolver.
Thiagohg
Thiagohg Membro Junior Registrado
126 Mensagens 8 Curtidas
#8 Por Thiagohg
25/06/2011 - 22:59
m45t3r disse:

P.S.: ok, sem PA? Tente remover o módulo só para desencargo de consciência, apesar que provavelmente não vai resolver.


Já tinha tentado isso, o módulo não existe.

"Marcos FRM"
Veja se mudando a taxa de amostragem não ajuda:


Não resolveu o problema, mas também não sei se mudei a configuração direito. Meu asound.conf está assim

defaults.pcm.rate_converter "samplerate_best"

pcm.upmix51 {
type upmix
slave.pcm "surround51"
delay 15
channels 6
}
pcm.!default "plug:upmix51"

pcm.rate_convert {
type plug
slave {
pcm "hw: 0,0"
rate 41000
}
}



Obrigado a todos pela ajuda

EDIT: Tive a ideia de tentar instalar o PulseAudio. Resolveu o problema do Flash, agora o som está funcionando perfeitamente. Uma pena não poder ficar sem ele, já que acho essa complicação toda de "servidor de som" totalmente desnecessária. São muitas camadas de software em cima de algo que deveria ser simples: ALSA, GStreamer, PulseAudio, Phonon.
Mas, enfim, o que importa é que ao menos está funcionando. Pena que não é de forma eficiente.

Muito obrigado pela ajuda de vocês.
Marcos FRM
Marcos FRM Highlander Registrado
10.3K Mensagens 712 Curtidas
#9 Por Marcos FRM
26/06/2011 - 10:29
Thiagohg disse:
EDIT: Tive a ideia de tentar instalar o PulseAudio. Resolveu o problema do Flash, agora o som está funcionando perfeitamente. Uma pena não poder ficar sem ele, já que acho essa complicação toda de "servidor de som" totalmente desnecessária. São muitas camadas de software em cima de algo que deveria ser simples: ALSA, GStreamer, PulseAudio, Phonon.
Mas, enfim, o que importa é que ao menos está funcionando. Pena que não é de forma eficiente.

Eu sou suspeito de falar do PulseAudio, pois acho-o uma excelete peça de software, que foi fundamental para modernizar a infraestrutura.

Aplicativo -> GStreamer/AO/SDL -> PulseAudio -> ALSA -> SOM NA CAIXA
(para aplicativos que usem algum framework como GStreamer, AO, SDL, etc.)

Aplicativo -> PulseAudio -> ALSA -> SOM NA CAIXA
(para aplicativos que usem o PulseAudio diretamente, como o Audacious, o VLC, etc)

Aplicativo -> plugin 'pulse' -> PulseAudio -> ALSA -> SOM NA CAIXA
(aplicativos que usam usam ALSA diretamente -- o pacote 'pulseaudio-alsa' do Arch configura o sistema para automaticamente para fazer o redirecionamento)

A única coisa que fará o PulseAudio consumir processamento é quando precisar reamostrar os fluxos de áudio, da mesma forma que a alsa-lib fazia. Para tunar o PulseAudio, dê uma lida:
https://www.hardware.com.br/comunidade/pulseaudio-audio/1150443/
...
m45t3r
m45t3r Veterano Registrado
986 Mensagens 57 Curtidas
#10 Por m45t3r
26/06/2011 - 12:48
Thiagohg disse:

EDIT: Tive a ideia de tentar instalar o PulseAudio. Resolveu o problema do Flash, agora o som está funcionando perfeitamente. Uma pena não poder ficar sem ele, já que acho essa complicação toda de "servidor de som" totalmente desnecessária. São muitas camadas de software em cima de algo que deveria ser simples: ALSA, GStreamer, PulseAudio, Phonon.
Mas, enfim, o que importa é que ao menos está funcionando. Pena que não é de forma eficiente.

Muito obrigado pela ajuda de vocês.


Não necessariamente, pois o ALSA nunca nasceu para receber som diretamente. Ele é complexo demais para isso, a ideia original era que as pessoas construíssem coisas básicas a partir de outras camadas de abstração (como o SDL, GStreamer, Phonon e o próprio PulseAudio) e só usassem ALSA diretamente para quando fosse necessário acesso as funções avançadas de som ou baixa latência.

O PulseAudio resolveu boa parte dos problemas que o ALSA trouxe por ser muito complexo, criando uma interface simples.
Thiagohg
Thiagohg Membro Junior Registrado
126 Mensagens 8 Curtidas
#11 Por Thiagohg
26/06/2011 - 23:06
"Marcos FRM"
A única coisa que fará o PulseAudio consumir processamento é quando precisar reamostrar os fluxos de áudio, da mesma forma que a alsa-lib fazia. Para tunar o PulseAudio, dê uma lida:
https://www.hardware.com.br/comunidad...audio/1150443/

Você fez um excelente artigo, gostei bastante smile.png
Depois que configurei aqui realmente cheguei na melhor qualidade de áudio que já tive no meu PC.
Só queria registrar uma observação quanto ao src-sinc-best-quality: aqui, ele nunca chegou a consumir mais de 12% de processamento. Em compensação, fez o PulseAudio travar ao reproduzir 3 streams simultaneamente. Algum bug, talvez?? Não compreendo porque não pediu mais CPU ao invés de travar. De qualquer forma, o "medium" oferece uma qualidade boa rindo_atoa.gif


"m45t3r"
Não necessariamente, pois o ALSA nunca nasceu para receber som diretamente. Ele é complexo demais para isso, a ideia original era que as pessoas construíssem coisas básicas a partir de outras camadas de abstração (como o SDL, GStreamer, Phonon e o próprio PulseAudio) e só usassem ALSA diretamente para quando fosse necessário acesso as funções avançadas de som ou baixa latência.

O PulseAudio resolveu boa parte dos problemas que o ALSA trouxe por ser muito complexo, criando uma interface simples.


Realmente o conjunto deles forma uma boa plataforma de áudio. Entretanto, acho que essa separação em várias camadas de abstração faz sentido apenas do ponto de vista de quem está programando. Para um usuário, o ideal seria apenas instalar um pacote "sistema de som" e acabou, mas essa padronização não seria possível justamente por se tratar de software livre: projetos diferentes, equipes diferentes. É compreensível, mas ainda sim, estranho ter que instalar 4 softwares diferentes para executar uma única funcionalidade. Reforço: do ponto de vista de quem está programando, separar as camadas de abstração é bom, produtivo e essencial (eu sou programador, falo por experiência própria). Apenas acho que ela não deveria ser carregada até o usuário final, até mesmo no Arch :P
Responder Tópico
© 1999-2024 Hardware.com.br. Todos os direitos reservados.
Imagem do Modal