I found the solution to this problem. It was a combination of two issues with made me confused. On the one hand I was stopping the chuck examples with ctrl+z or ctrl+c randomly. With ctrl+z it doesnt free the devices and after that the error was happening. But now I quit with ctrl+c it never complains after. On the other hand my chuck file is controled from a python process, i am using pygame (SDL) to open a window and i was also initialising the pygame audio system. This was getting control over the sound card and by the time chuck was launched the device was busy. Now I dont start the pygame audio and the problem is gone. This error did not happen with my desktop and i guess this is due to the souncard being different, I guess the one on the desktop is much better and can handle both chuck and pygame at the same time. thanks enrike altern wrote:
Atte André Jensen wrote:
altern wrote:
[chuck]: cannot initialize audio device (try using --silent/-s)
any ideas? I am not running any other sound device as far as i can see but i dont know much on audio and linux.
Looks like chuck can't find your soundcard. Try "chuck --probe". Are there any of the examples that *are* working that produce sound?
I am checking more carefully. I run hanoi++.ck and this sounds ok, i stops it, try to run it again and i get the error then.
This is the output from "chuck --probe"
~$ chuck --probe [chuck]: found 2 device(s) ... [chuck]: ------( chuck -- dac1 )--------------- [chuck]: device name = "hw:I82801CAICH3,0" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = YES [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: supported sample rates: [chuck]: 8000 Hz [chuck]: 11025 Hz [chuck]: 16000 Hz [chuck]: 22050 Hz [chuck]: 32000 Hz [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: [chuck]: ------( chuck -- dac2 )--------------- [chuck]: device name = "hw:I82801CAICH3,1" [chuck]: probe [success] ... [chuck]: # output channels = 0 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 0 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: supported sample rates: [chuck]: 48000 Hz [chuck]: ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory [chuck]: RtMidiIn::initialize: error creating ALSA sequencer input client object. [chuck]: ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory [chuck]: RtMidiOut::initialize: error creating ALSA sequencer client object.
i tried this as well as suggested by Burton in another email $ fuser /dev/snd/* /dev/snd/pcmC0D0c: 4351m /dev/snd/pcmC0D0p: 4351m
does this mean that after running chuck once the sndcard is locked somehow?
mmm... I tried $ fuser -k -dev-snd/*
and ... aha! ... i got this /dev/snd/pcmC0D0c: 4351m /dev/snd/pcmC0D0p: 4351m [1] Killed chuck hanoi++.ck
Now I tried again all the examples in the examples folder and they all work, but then after trying status.ck again i get the same error as before. I tried fuser -k again and it says it killed status.ck. Again the sound works fine. So now i tried to run status.ck again to see if it is the code on that file causing the lock, but this time no problem after running it.
So it looks like somehow (randomly?) the soundcard get blocked by chuck I am running the files from command line and killing the them with control+C
any ideas about what to do to avoid this problem? it is quite bad.
thanks for the tips!
enrike