[chuck-users] error on linux laptop

altern altern2 at gmail.com
Wed Dec 20 14:55:49 EST 2006


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



More information about the chuck-users mailing list