Versão Imprimível
de quando em vez eu não consigo ouvir som aqui pq - conforme a msg do título - o /dev/dsp tá ocupado. Isso vem do nada e, conforme eu verifico:
lsof /dev/dsp
NADA está ocupando o dispositivo.
Ao tentar remover os módulos de som, os de placa, etc, recebo a informação de que os módulos estão em uso - portanto, não posso baixar/recarrega-los pra verificar.
A placa de som só volta a funcionar após reboot da máquina.. bolas, isto aqui não é rwindows, eu gostaria de saber se tem outro jeito.
Qual placa que é?
Isso acontece perto do tempo em que você visualiza algo em flash ou coisas do tipo?
Intel 8x0 - Sis AC-97 (conforme o alsaconf)Citação:
Postado originalmente por psy
não reparei.. vou prestar mais atenção :(Citação:
Isso acontece perto do tempo em que você visualiza algo em flash ou coisas do tipo?
Qual módulo você usa na placa? oss, alsaoss, etc
Eu acho bastante possível que o problema seja algo relacionado com flash, mas depende do módulo também.
é o alsa.
SEM qualquer uso o /dev/dsp ficou ocupado. Medida extrema: desliguei/religuei a máquina, desocupou. Então fui até o site da macromedia e mandei acionar o tutorial que êles têm lá - todo em flash. Resultado: continua funcionando o som.
Então:
a) paraliza "do nada"
b) aparentemente sem relação com o uso do flash
:(
Hmm, certo..
Da um ls -l no /dev/dsp, eu acho que o link em si deve ter permissao de RW, mas o device (dsp0) nao, pode ser esse o problema.
Quando ele da esse erro, tenta jogar uma string no device e ver se voce ouve resposta, ou usar por exemplo, o xmms, com modulo oss, e ve se roda perfeito.
Parece problema de permissao, mas vai saber...
[irado@irado:~$]: ls -l /dev/dsp
lrwxrwxrwx 1 root root 9 2007-02-15 12:04 /dev/dsp -> sound/dsp
não é isso não (em meu entender, claro). O "cat.. > /dev/dsp" funciona normal até que pare (risos), isso como usuário normal. E, pelo que se vê acima, o link aceita rw, pedras e paus.. o que vc mandar pra lá..
quanto ao xmms, strings, etc.. tudo funciona muito bem. Até parar (risos). Daí em diante, só no reboot mesmo, pq não se consegue mais nada, remover módulos nem pensar.
kkk
Quando ele para roda um 'fuser /dev/dsp' pra ver que merda ta ocupando ele..
Mistériooo!
Ah outra coisa, você tá no debian?
Da uma olhada se ele nao ta usando o esd ao invez do alsa, se for o caso muda a lib dele (libesd0) para a libesd-alsa0...
Amigo,
Isso acontece também, quando algum programa (processo) não é finalizado corretamente, às vezes devido à algum erro do desenvolvedor.
Reiniciar a máquina e o sistema de som voltar a funcionar depois disso, é um sintoma bem característico do que falo acima.
Checa os processos com o comando "ps" e vê se algum que já devia ter terminado, ainda continua na memória rodando e ocupado o dispositivo de som.
para o psy: não, não é debian, é slackware 11.0. E usando o alsa mesmo.
vou experimentar, quando parar, o "fuser". Conforme explicitado na lei de murphy, agora que quero que pare, não aconteceu mais :(
slackmaster: no ps não aparece nada.. ninguém que possa usar o /dev/dsp (normalmente aciono o gxine ou xmms, o processo paralisa do nada e.. pronto, tá ocupado - mesmo depois de um kill nos xmms/gxine).
kkk, murph > all!
Fiquemos no aguardo entonces heheh!
tá aqui o resultado:Citação:
Postado originalmente por psy
[irado@irado:~/downloads$]: cat infovideo.tmp > /dev/dsp
bash: /dev/dsp: Device or resource busy
[irado@irado:~/downloads$]: fuser /dev/dsp
[irado@irado:~/downloads$]:
ou seja.. ninguém se apresentou como culpado :(
bem.. ontem foi visível o culpado: é o gxine, que é chamado pelos mozillas/firefox/seamonkey para tratamento de streaming de som - shoutcast.
Ou seja, eu acesso o shoutcast e, depois de algum tempo eu resolvo parar o gxine. Muito bem, elimino-o, não aparece mais no ps, masss... o /dev/dsp, a partir daí, fica "ocupado". Mesmo o próprio gxine, se chamado, não consegue mais acesso. Minha impressão é de que não é falha do aplicativo mas possívelmente do módulo de kernel, uma vez que pesquisa rápida no google traz um montão de gente com o mesmo problema, mas com outros aplicativos.
O youtube, por exemplo, não trava o /dev/dsp se chamado antes, mas eu tampouco sei como funciona o áudio do youtube (não há aplicativo à parte).
enfim.. obrigado a vcs pelo apoio. Talvez dia dêstes saia uma correção para o problema (repito: IMHO, algo com os módulos do kernel)