+ Responder ao Tópico



  1. #1

    Padrão /dev/dsp: Device or resource busy

    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.

  2. #2
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    Qual placa que é?

    Isso acontece perto do tempo em que você visualiza algo em flash ou coisas do tipo?

  3. #3

    Padrão

    Citação Postado originalmente por psy Ver Post
    Qual placa que é?
    Intel 8x0 - Sis AC-97 (conforme o alsaconf)


    Isso acontece perto do tempo em que você visualiza algo em flash ou coisas do tipo?
    não reparei.. vou prestar mais atenção

  4. #4
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    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.

  5. #5

    Padrão

    é 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


  6. #6
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    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...

  7. #7

    Padrão

    [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.

  8. #8
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    kkk

    Quando ele para roda um 'fuser /dev/dsp' pra ver que merda ta ocupando ele..
    Mistériooo!

  9. #9
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    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...

  10. #10

    Padrão

    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.

  11. #11

    Padrão

    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).

  12. #12
    Administrador Avatar de Fernando
    Ingresso
    Jul 2001
    Localização
    Campinas Area
    Posts
    4.996
    Posts de Blog
    4

    Padrão

    kkk, murph > all!

    Fiquemos no aguardo entonces heheh!

  13. #13

    Padrão é coisa de doido..

    Citação Postado originalmente por psy Ver Post
    kkk

    Quando ele para roda um 'fuser /dev/dsp' pra ver que merda ta ocupando ele..
    Mistériooo!
    tá aqui o resultado:

    [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

  14. #14

    Padrão é o gxine, o 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)