Luke Dean <[EMAIL PROTECTED]> writes:

> I'm running FreeBSD 6.1.
> My sound device shows up like this in my dmesg:
> pcm0: <Intel ICH5 (82801EB)> port 0xd800-0xd8ff,0xdc00-0xdc3f mem
> 0xfc001000-0xfc0011ff,0xfc002000-0xfc0020ff irq 17 at device 31.5 on
> pci0
> pcm0: primary codec not ready!
> pcm0: <Avance Logic ALC658 AC97 Codec>
> My sound driver is compiled into the kernel:
> device          sound
> device          snd_ich
> I've got a java application that I run through
> diablo-jdk- that uses sound.  It's a game.  Partway
> through the game, the sound stops working.  The people who make the
> game have been aware of the problem for many months, but don't
> understand what to do about it.
> Okay, I can accept that.
> What I can't accept is that this java application breaks the sound in
> such a way that NOTHING can play sound anymore until I reboot the
> machine!
> If I attempt to play a movie with mplayer after the game has broken
> the sound, it says:
> [AO OSS] audio_setup: Can't open audio device /dev/dsp: No such file
> or directory
> However, the dsp device still exists in /dev:
> [0:/dev> ll dsp*
> crw-rw-rw-  1 root  wheel  -   0,  51 Dec 29 21:36 dsp0.0
> crw-rw-rw-  1 root  wheel  -   0,  54 Dec 29 21:37 dsp0.1
> crw-rw-rw-  1 root  wheel  -   0,  52 Dec 29 19:24 dspW0.0
> crw-rw-rw-  1 root  wheel  -   0,  55 Dec 29 19:24 dspW0.1
> crw-rw-rw-  1 root  wheel  -   0,  57 Dec 29 19:24 dspr0.1
> The sndstat device doesn't show any problem, if I'm reading the output
> right:
> [0:/dev> cat /dev/sndstat
> FreeBSD Audio Driver (newpcm)
> Installed devices:
> pcm0: <Intel ICH5 (82801EB)> at io 0xfc001000, 0xfc002000 irq 17 bufsz
> 16384  (1p/1r/0v channels duplex default)
> Is there anything I can do short of rebooting the machine to get my
> sound working when this happens?  I thought maybe there was something
> I could do with devd or devctl to reset the device, but I can't figure
> out how to do that.  I'm not even sure how to "see" the problem except
> to attempt to play a sound.

Well, it's hard to say, because the hardware could be misbehaving, in
which case the software may not know what's going on.  It might be
interesting to see whether fstat(1) sees anything holding the dsp
devices.  You could also try using vchans, which would (in theory) let
you access the hardware from another device node after the first one

Good luck.
_______________________________________________ mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to