Hi all, I've become quite interested in procedural/fully synthesized audio for game development, and I've tried out a lot of different tools, including cmus, supercollider, puredata, and chuck. I really like chuck, because it seems fairly lightweight and simple compared to the others. The only problem is that I can't get it to work in Ubuntu using alsa. It works with jack, which is fine for me, but I don't want my users to have to install and deal with jack just to play my game. So here's my situation... I'm running 32 bit Ubuntu 11.04. I have onboard sound on my motherboard, through the nVidia MCP55 chipset: 00:0f.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2) Unfortunately, that device crapped out on me a year or so ago, so I replaced it with this: 02:09.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) ...which is a Diamond XS51 PCI audio card. I also have this, courtesy of my video card: 01:00.1 Audio device: ATI Technologies Inc Barts HDMI Audio [Radeon HD 6800 Series] That makes for a fairly complex setup. Here's what chuck sees: $ ./chuck --probe [chuck]: found 7 device(s) ... [chuck]: ------( chuck -- dac1 )--------------- [chuck]: device name = "hw:NVidia,0" [chuck]: probe [success] ... [chuck]: # output channels = 8 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = YES [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: 32-bit int [chuck]: supported sample rates: [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 96000 Hz [chuck]: 192000 Hz [chuck]: [chuck]: ------( chuck -- dac2 )--------------- [chuck]: device name = "hw:NVidia,1" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: 32-bit int [chuck]: supported sample rates: [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 88200 Hz [chuck]: 96000 Hz [chuck]: 192000 Hz [chuck]: [chuck]: ------( chuck -- dac3 )--------------- [chuck]: device name = "hw:NVidia,2" [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]: 32-bit int [chuck]: supported sample rates: [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 96000 Hz [chuck]: 192000 Hz [chuck]: [chuck]: ------( chuck -- dac4 )--------------- [chuck]: device name = "hw:CMI8738,0" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: supported sample rates: [chuck]: 5512 Hz [chuck]: 8000 Hz [chuck]: 11025 Hz [chuck]: 16000 Hz [chuck]: 22050 Hz [chuck]: 32000 Hz [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 88200 Hz [chuck]: 96000 Hz [chuck]: [chuck]: ------( chuck -- dac5 )--------------- [chuck]: device name = "hw:CMI8738,1" [chuck]: probe [success] ... [chuck]: # output channels = 6 [chuck]: # input channels = 0 [chuck]: # duplex Channels = 0 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: supported sample rates: [chuck]: 5512 Hz [chuck]: 8000 Hz [chuck]: 11025 Hz [chuck]: 16000 Hz [chuck]: 22050 Hz [chuck]: 32000 Hz [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 88200 Hz [chuck]: 96000 Hz [chuck]: [chuck]: ------( chuck -- dac6 )--------------- [chuck]: device name = "hw:CMI8738,2" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 2 [chuck]: # duplex Channels = 2 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: 32-bit int [chuck]: supported sample rates: [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: 88200 Hz [chuck]: 96000 Hz [chuck]: [chuck]: ------( chuck -- dac7 )--------------- [chuck]: device name = "hw:Generic,3" [chuck]: probe [success] ... [chuck]: # output channels = 2 [chuck]: # input channels = 0 [chuck]: # duplex Channels = 0 [chuck]: default device = NO [chuck]: natively supported data formats: [chuck]: 16-bit int [chuck]: supported sample rates: [chuck]: 32000 Hz [chuck]: 44100 Hz [chuck]: 48000 Hz [chuck]: [chuck]: ------( chuck -- 2 MIDI inputs )------ [chuck]: [0] : "Midi Through Port-0" [chuck]: [1] : "C-Media CMI8738 MIDI" [chuck]: [chuck]: ------( chuck -- 4 MIDI outputs )----- [chuck]: [0] : "Midi Through Port-0" [chuck]: [1] : "C-Media CMI8738 MIDI" [chuck]: [2] : "OPL3 FM Port" [chuck]: [3] : "qjackctl" [chuck]: I've tried using dacs 4-6 with pasuspender to suppress pulseaudio, but nothing seems to work. The same thing happens without pasuspender; I don't know if it's actually required, but it's something I tried. Anyway, in an attempt to get some more information, I increased the log verbosity: $ pasuspender -- ./chuck --verbose5 --dac5 moe.ck **snip** [chuck]:(2:SYSTEM): | sample rate: 48000 [chuck]:(2:SYSTEM): | buffer size: 512 [chuck]:(2:SYSTEM): | num buffers: 8 [chuck]:(2:SYSTEM): | devices adc: 0 dac: 5 (default 0) [chuck]:(2:SYSTEM): | adaptive block processing: 0 [chuck]:(2:SYSTEM): | channels in: 2 out: 2 **snip** [chuck]:(3:SEVERE): starting real-time audio... [chuck]:(2:SYSTEM): RtApiAlsa: callback thread error... [chuck]:(5:INFORM): | (RtApiAlsa: audio read error for device (hw:NVidia,0): Input/output error.) [chuck]:(5:INFORM): | closing thread... What's going on here? I asked for the CMI8738, but I'm getting I/O errors from the nvidia device. At this point I'm completely lost. Help? -Alex
What's going on here? I asked for the CMI8738, but I'm getting I/O errors from the nvidia device. At this point I'm completely lost.
Odd. Just to make sure (I've seen many seasoned pro's forget to plug in power for a device thought broken...); you are sure your alsa-dev libraries are all in place and of the correct version? Did you check what happens if you don't "suspend" PulseAudio? In my experience chuck-alsa connects just fine to PulseAudio, provided you are not also running something like Skype and/or a browser with a running Flash plugin. Those two tend to try to be compatible with very old drivers (good, I suppose) and in the meantime manage to not be compatible with running stuff like ChucK at the same time (bad). I suggest you drop the suspending of PA for a moment, close all browsers and Skype sessions, then try all likely DAC candidates again in turn. If anything interesting shows up I'd like you to post it to this list, as you did above. Hope that gets us a bit further; I hope we can get this to work because ChucK for game audio sounds quite exciting. Hope that helps, Kas.
you are sure your alsa-dev libraries are all in place and of the correct version?
Of course this note only applies if you compiled your own binary from source. I strongly recommend that Linux users do, so you get the latest updates. I should have clarified that before, or maybe it was already clear? Yours, Kas.
Did you check what happens if you don't "suspend" PulseAudio? In my experience chuck-alsa connects just fine to PulseAudio, provided you are not also running something like Skype and/or a browser with a running Flash plugin. Those two tend to try to be compatible with very old drivers (good, I suppose) and in the meantime manage to not be compatible with running stuff like ChucK at the same time (bad).
I tried that and received the same error as before. However... As it turns out, there's an option to disable the onboard audio device in BIOS. I switched it off, and now chuck works just fine. I'm guessing that chuck must try to query all present devices, which is why it failed every time, even when I specified a different device. How's that for a rare bug! -Alex
Alex; I'm guessing that chuck must try to query all present devices, which
is why it failed every time, even when I specified a different device. How's that for a rare bug!
Could be, yes. I think it's generally good practice to turn off unused devices in the BIOS, especially when dealing with a more complicated setup like yours, or with somewhat broken devices. For all we know it might have been a IRQ conflict or some such issue. Surprising that ALSA itself didn't balk at the situation, really. End good all good, Kas.
participants (2)
-
Alex French -
Kassen