[longo] Re: Bugs do Alsa (era: [off-topic] sb16 em 2.6.0-test2)
No dia 03/08/2003 às 14:58,
"Leandro A. F. Pereira" <leandro@linuxmag.com.br> escreveu:
> Tenho uma AWE32, ISA PnP. Funciona legal o ALSA no Linux 2.6.0-test2, tanto PCM
> quanto sequencer. Só tem duas coisas que estão quase me fazendo voltar para o
> bom e velho OSS:
>
> - Se o dispositivo de som está sendo utilizado, o ALSA deixa outros processos
> usá-lo normalmente -- parece que coloca tudo numa fila, e quando ele é liberado,
> tudo que estava nessa fila é tocado. Por exemplo, se estou com o xmms e o licq
> aberto, tocando uma MP3, e chega alguma mensagem no ICQ, eu não ouço o "Uh-Oh".
> É só fechar o xmms ou parar a música e ouço o som. Às vezes ouço inúmeros
> "Uh-Oh" em seqüência.
Leandro, sou obrigado a reabrir este thread porque na minha resposta eu
dizia que a arquitetura ALSA permitia de forma automática a execução de sons
simultâneos. De fato estava certo, mas acredito que a partir da versão 1.0,
o ALSA passou a seguir um novo modelo, que está sendo considerado padrão
(não só pelo ALSA, mas os drivers mais novos de placa de som, etc).
Descobri isso quando instalei o quérnel 2.6.0 (alsa 1.x) na máquina do meu
irmão, e fiquei surpreso (decepcionado?) com a impossibilidade de tocar sons
simultaneamente. A minha máquina ainda continua com o alsa antigo (quérnel
2.4 e ALSA 0.9.8) e consegue trabalhar perfeitamente com sons executados ao
mesmo tempo.
Este fato me intrigou, até quando achei um FAQ em '/usr/share/doc/alsa'
dizendo exatamente sobre isso:
Q: When I play something and I try to play something other the second attempt
will not fail but instead it hangs waiting for the completion of the first
sound.
A: This is definitely the standard behaviour as described in many official
documents that now ALSA follows. There is no reasons to complain about that
for the following reasons:
- it's the right (standard) way
- the application that want a different behaviour can open the device in
O_NONBLOCK mode
- all modern OSS drivers in mainstream kernel (cmpci, es1370, es1371,
esssolo1, maestro, sonicvibes, vwsnd) works in the same ways and the
others have to be intended buggy
- we want you ask to broken applications author to fix them ;-)
O que entendi é que ainda é possível ter esta característica em
funcionamento, mas isto agora fica a cargo dos desenvolvedores, podendo
optar em abrir o dispositivo de som de forma exclusiva ou não (NONBLOCKING,
do tipo open("/dev/dsp", O_RDONLY|O_NONBLOCK)).
Por exemplo, já existe um patch para o mplayer (saída ALSA) que permite o
usuário especificar o modo de abertura do dispositivo - por exemplo,
especificando na linha de comando: mplayer -ao alsa1x:noblock.
Mas ainda estou bastante confuso sobre isto, alguns pontos são:
1 - a possibilidade de gerenciar sons simultâneos, além de contar com o
desenvolver, precisa que o *hardware* seja capaz de executá-lo, ou o "mixer"
(merge) pode ser feito via software (ALSA) e então entregue à placa de som?
2 - como é de fato esta relação de exclusividade?!? Isto é, duas ou mais
aplicações podem disparar sons ao mesmo tempo se e somente se estas abriram
o dispositivo com a máscara O_NONBLOCK?
3 - qual a justificativa para a adoção deste novo padrão?
> - É lento! Lento! Lento! Um DivX que tocava normalmente com OSS, fica lerdão
> com o ALSA. Se desligar o som, fica perfeito. Se uso somente OSS (sem emulação
> do ALSA), fica melhor ainda.
Pois é, na máquina do meu irmão (Duron 1GHz, 380MB RAM, via68xx), o som ALSA
+ quérnel 2.6.0 pipocava com uma freqüência razoável. Bastava por exemplo um
uso mais intenso no HD (tipo uma descompactação de pacotes) e o som
literalmente parava. Nem mesmo um 'renice -19' na aplicação de som conseguia
elimitar este incômodo.
Não cheguei a fazer uma comparação mais precisa com o quérnel 2.4.X, mas das
vezes que rodei o Kurumin nesta máquina não cheguei a notar este pipocamento.
--
Douglas Augusto
[Netiqueta]
§ Evitar e-mails HTML, mesmo oferecendo alternativa puramente textual.
Reply to: