ALSA error installing software configuration

[PhiJ]

Hi, I've just installed chuck 1.2.1.2 on a Gentoo linux amd64 system from sources with alsa support and examples, but without jack or oss support.

When I run it, I get this error:
[chuck]: (via rtaudio): no devices found for given stream parameters:
... RtAudio: ALSA error installing software configuration (hw:NVidia,0): Invalid argument.
... RtAudio: ALSA error installing software configuration (hw:NVidia,1): Invalid argument.
... RtApiAlsa: pcm device (hw:NVidia,2) won't open: No such file or directory.

[chuck]: cannot initialize audio device (try using --silent/-s)

And chuck --probe gives me this:
[chuck]: found 3 device(s) ...
[chuck]: ------( chuck -- dac1 )---------------
[chuck]: device name = "hw:NVidia,0"
[chuck]: probe [success] ...
[chuck]: # output channels = 6
[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]:
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.
[chuck]:

Any idea what the problem is?

[Kassen]

Odd.

Did you get any lines that looked like errors when compiling?
Are you -for example- sure you have the "-dev" ALSA library installed?
Do other ALSA programs work?

[PhiJ]

I didn't see portage ejecting any errors in the compile or the log file. It certainly didn't thought the package was installed successfully (Green lights at the end)
As for ALSA, I don't really know (I've only been with linux for a couple of months), but when I run make menuconfig (which has my current config loaded at the mo I think), it says

<M> Advanced Linux Sound Architecture
< > Sequencer support
<M> OSS Mixer API
<M> OSS PCM (digital audio) API
[*] OSS PCM (digital audio) API - Include plugin system
< > RTC Timer support
[ ] Dynamic device file minor numbers
[*] Support old ALSA API
[*] Verbose procfs contents
[ ] Verbose printk
[ ] Debug

Also I have an HD Audio Device, with every option set except Build hwdep for HD-audio driver. And yes, sound didn't work at all on GNOME before I installed the ALSA modules and stuff. It now does.
Does that help at all?

Edit: Oh, and I used portage to install it, not the standard install instructions. Portage should do it right though. It has, however, not been tested for my arch yet.

Edit number 2: I have the package alsa-lib installed with all plugins (so I assume all of the alsa libraries) installed (also with midi support, but no alisp support debug stuff or docs).
Oh, and looking at the install instructions, I don't have yacc (is that just needed for the install?) I installed it though, ran an env-update, and it made no difference, so I got rid of it.

Edit number 3: Had a look through the portage emake file, and it seems to use the normal makefile, so that shouldn't be a prob.

[PhiJ]

Getting somewhere (I think). Adding sequencer support into my kernel doesn't help with the original error message, but I get a different output from chuck --probe:
[chuck]: found 3 device(s) ...
[chuck]: ------( chuck -- dac1 )---------------
[chuck]: device name = "hw:NVidia,0"
[chuck]: probe [success] ...
[chuck]: # output channels = 6
[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]:
[chuck]: ------( chuck -- 0 MIDI inputs )------
[chuck]:
[chuck]: ------( chuck -- 0 MIDI outputs )-----
[chuck]:

Can we work anything out from that?

[Kassen]

First thing to do would be making sure you have the ALSA "-dev" library. You absolutely need this and it's not the same as a plugin. The version of this library needs to match the version of ALSA that's installed. Right now I suspect this is the issue.

If that doesn't help I'd get YACC (which you need for the compile process, I don't think you need it to run ChucK, though I would keep it around as it's nice to have for the next time you'll build ChucK) and simply use "make linux-alsa" and "sudo make install". I'm suggesting that because we know that method of building will work if you have the dependencies set up right.

I can understand the desire to use portage but if all goes well you should end up with just a chuck executable in /usr/bin. Should you ever want to get rid of this a simple manual removal (with sudo, of course) will do.

Once the normal process works we could always look into using Portage but I think you should try "make" and should this fail post make's output for diagnosis.

[PhiJ]

The version of the ALSA library I have is 1.0.16 and the version of ALSA I have is 1.0.16rc2. If I need to install anything else I really don't know how... sorry.
Tried the standard install - No errors, but it still doesn't work.

[Kassen]

Ok.... that's quite strange. Now I'm at a bit of a loss.

Erm, somebody else may have some ideas?

[radarsat1]

any luck with other alsa programs? does aplay work? does jack work? try compiling with jack. permissions problem? many things to check.

[PhiJ]

aplay? Yes.
Jack? No idea.
Compiling with jack? using portage or the other install, I get this:
JACK tmpdir identified as [/var/run/jack]
[chuck]: (via rtaudio): no devices found for compiled audio APIs!
[chuck]: cannot initialize audio device (try using --silent/-s)
And chuck1 --probe gives me this
JACK tmpdir identified as [/var/run/jack]
[chuck]: (via rtaudio): no devices found for compiled audio APIs!
[chuck]:
[chuck]: ------( chuck -- 0 MIDI inputs )------
[chuck]:
[chuck]: ------( chuck -- 0 MIDI outputs )-----
[chuck]:
(I've saved the jack version as chuck1 in /usr/bin. That won't cause any problems will it?)
How do I check if it's a permissions problem?

[radarsat1]

what's the output of "chuck --probe" for the alsa version?

[PhiJ]

That's in my third post. :)

[radarsat1]

sorry, you're right. a quick google on "alsa invalid argument" tells me that this happens sometimes if the wrong sample rate is selected. i know for example that i've had problems with RtAudio on a computer that had a hardware samplerate of 48000 Hz when I tried to open a dac at 44100 Hz. So, what happens when you try different combinations of sample rates and block sizes? Also, what's your sound chipset?

[PhiJ]

lspci gives me
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
In terms of the kernel "Also I have an HD Audio Device, with every option set except Build hwdep for HD-audio driver."
is that enough info about my audio device? If not, how do I find more?

I get the same results for chuck --srate=44100 or 48000 or 88200 or 96000 or 192000 (using the adc.ck example file) How do I change block sizes?

[Kassen]

--bufsizeN

N must either be a power of 2 or will be rounded up to the smallest power of 2 that's larger then N.

Note this affects latency, CPU strain and the polling of interfaces but it's *not* block processing.

[radarsat1]

hm, yeah that's enough information. unfortunately i don't know what else to suggest off the top of my head. you could try downloading STK and compiling the examples to see if they work. (also uses RtAudio, albeit a newer version than ChucK.)

it'd be great to figure out what's wrong actually, if there is a bug in RtAudio it would be good to fix it. but i'm not sure what else to try. i haven't used gentoo in a few years.

block size can be changed with the bufsize and bufnum arguments, but i doubt they'll make a difference.

[Kassen]

No, I don't think that will make a difference either, but it couldn't hurt to go over the syntax.

If I understand it all correctly the latest version of RTAudio would permit us to support multiple types of driver in a single executable. That could be a big advantage for us. Less hassle with Linux's various types and no more issues with Windows stock drivers (compatible with everything but sloooooow) v.s. ASIO (cool but needs a extra ASIO4ALL driver to use with build in/ consumer cards.)

If it's stable I feel we should try to move in that direction.

[radarsat1]

I agree, it would be nice to upgrade ChucK's RtAudio. A problem is that it's been modified from the latest version. One approach would be to figure out which version Ge took, and perform a 'diff' to see what changes he made, and then port them to the newest version. A bit of work, but possibly worth doing.

For supporting multiple interfaces, I think it would be nice, but it might require using run-time linking (i.e., loadlibrary / dlopen), which would require some changes to the way RtAudio is coded. However, this would allow to compile a binary against Jack and ASIO for example, but allow it to run even if they aren't installed. Again, a bit of work.

[Kassen]

We could go "figure out what version Ge has" and do the diff and so on... but I think we can do better then that. Gary Scavone (who does RTAudio) has at times posted to the ChucK mailing list, it's not like this is some complete stranger. We could simply ask what's up there.

Still if you look at this; http://www.music.mcgill.ca/~gary/rtaudio/multi.html

I think it looks quite possible. It does note;

[radarsat1]