No I don't think it's any of that.

There's one sound card and in alsamixer I can control the input volume of the mic, but it pipes the input straight to the output and the hifi, which I don't need obviously.

I can't configured stuff like audacity or skype to use the mic - that's the issue. audacity shows the options of devices on the card, but selecting them doesn't give me the mic input. Strange that the names of the devices in audacity and skype are "ALSA HDA Intel ALC882 Analog hw:0,0 " thro "... hw:0,2" and the names in alsamixer are just 'mic' and 'mic boost'. Some sort of fundamental disconnect. Running it with aoss makes no difference.

I do have these strange devices in the alsamixer: "capture", "capture.1" and "capture.2" - maybe that's what audacity thinks is the input devices.

It's a strange one. Is alsaconf of any help?

$ aumix -q

Curious to see what that one shows on your system. (simpler and easier to understand than amixer)

You have to actually record something in audacity to see what your levels are registering at (depending on your version of audacity). Ardour just shows them all the time. I still think that play through shouldn't be a default. It is and if you're mic is close enough and sensitive enough you can/will get feedback. Or if you turn the speakers up too loud. But that's a different issue.

You might try rm -rf ~/.audacity to let your version of audacity assume default settings when you launch it. Where ~ is short for /home/user/

Oh right. I have to load snd-pcm-oss, snd-mixer-oss and snd-seq-oss to get that to run, otherwise I don't see the /dev/mixer stuff. I know they're meant to load on boot, but they don't.

adam@isengard:~$ aumix -q
vol 84, 84
pcm 85, 85
line 74, 74
mic 55, 55
cd 81, 81
pcm2 100, 100
igain 0, 0
dig1 100, 100


Well I tried loads of times to record on each of the devices shown in audacity, but for the first and the third, I just get a flat line, no nothing. On the second device, audacity goes all flakey and won't record, but doesn't give any error.

I don't see ardour in the package repository.

I'm having the same exact problem with my laptop mate, hope you get it all sorted out

The obvious thing I'm seeing there is no R

$ aumix -q

vol 84, 84, P
pcm 84, 84
speaker 80, 80
line 0, 0, P
mic 50, 50, R <===<<<
cd 84, 84, P
pcm2 84, 84
igain 50, 50
line1 100, 100, P
dig1 0, 0
phin 100, 100, P
phout 100, 100, P
video 100, 100, P

In the gui version of aumix (package aumix-gtk in debian) there's little squares with colored squared in them. The RED one is the recording channel. Clicking it turns it red (and turns previous red ones green).

Or go old school

$ aumix -i 30 -m 75 -m R

Sorry but my system isn't doing that.

adam@isengard:~$ aumix -i 30 -m 75 -m R
adam@isengard:~$ aumix -q
vol 84, 84
pcm 85, 85
line 74, 74
mic 75, 75
cd 81, 81
pcm2 100, 100
igain 30, 30
dig1 100, 100
adam@isengard:~$


Plus the gui aumix doesn't have any little squares with red or green. Just the sliders for volume and balance - and that's with all options in the menu checked. Actually there is a header 'R' but the column below is blank. Hmmm! Could there be more garbage in my config?

This is version 2.8-21

That's an odd one to say the least. Is this a laptop or desktop? It's almost like some jumper or cable somewhere isn't plugged in. Does it work in windows (whatever that is?)? If you have bandwidth and media, you might burn a liveCD and see if it's the same. If not, you might check to see how it differs in terms of configuration.

Things are muted in alsa by default. In alsamixer push "M" on any channels that are not already known to be okay. If you haven't already.

On a side note, that extra conf stuff and blacklist-ing snd-pcsp and friends makes it so I can record in mono now. You should probably rename your /etc/modprobe.d custom stuff to a .conf file. Because I did that as well, and that could be the sole reason for the sanity that my system gained. And I had to reinstall alsa-base to get the blacklist entries to cut and paste. And moved/removed them when I was done for those /etc/modprobe.d/alsa-base entries. Leaving just my custom conf.

# dpkg --purge --force-all alsa-base
# apt-get install alsa-base

Maybe it'll help, maybe it wont.

Will alsa read all of /etc/modprobe.d/alsa-base and /etc/modprobe.d/alsa-custom or /etc/modprobe.d/alsa-custom.conf?

Or just /etc/modprobe.d/alsa-base ?

That's what I'm using.

The kernel and boot process reads all of /etc/modprobe.d/ at boot time. But newer messages / alerts seem to suggest that it will only read files ending in .conf in that path. Pretty much anything involving modprobe reads from there. Which alsa does when loading or unloading modules.

$ apt-cache show module-init-tools

http://www.kerneltools.org/

OK one step in the right direction: the oss modules now load automatically.

Audacity still wants no truck with the mic, and I still see no way of setting the mic to R (the aumix cmd doesn't have any effect).

There are new files now in /etc/modprobe.d called blacklist, alsa-base-blacklist, linux_sound_base_noOSS and sound.

Sound is just

alias snd-card-0 snd-hda-intel
options snd-hda-intel index=0


which seems to duplicate alsa-base.

The blacklist files seem OK, none are blacklisting snd-hda-intel.

And none of them are .conf suffixes.

"R" in aumix is equivalent to "[on]" in amixer. It's just simpler to read. You might have a version that doesn't print that information. Or there's some option -h that helps it to know to print it. Might be an alias or something on my system. Could be the way it was compiled and other things. Could just be a difference in version.

There's information in /proc/asound/card0/* to give further details. Even some way to echo "some modified line from said cat of virtual file" > /proc/asound/card0/... But you've got to know what you're doing there and mostly a last resort. Much like `echo 0 > /proc/sys/net/ipv4/ip_forward` can disable or enable(1) a feature. We're not there yet IMO, but reading some cat /proc/asound/* stuff might further understanding. Or mis-understanding since alsa seems a bit confused at this point.

$ find /proc/asound/ -iname '*' | while read INPUT; do echo -e "\n\n\n"$INPUT"\n" | tee -a logging_sound.txt; cat $INPUT | tee -a logging_sound.txt; done
$ less logging_sound.txt

Purely informative, but maybe of use to you.

$ cat logging_sound.txt | wc -l

Close to 1,000 lines on my system so probably not advisable to post here.

Regardless alsamixer should give you access to it. I just find that app so cryptic to be of much use beyond level and information. On some channels it's just blatantly odd/wrong on a few of my cards. Those channel generally don't hold settings so kind of moot. Room for improvement IMO.

I'm beginning to hope that squeeze comes out of testing soon - I've probably got a good chance of the mic just working out of the box with it.

Anyway, one thing I noticed looking through all the output of the /proc/asound stuff, e.g.:

/proc/asound/devices

0: [ 0] : control
1: : sequencer
16: [ 0- 0]: digital audio playback
17: [ 0- 1]: digital audio playback
24: [ 0- 0]: digital audio capture
25: [ 0- 1]: digital audio capture
26: [ 0- 2]: digital audio capture


I think they just ignore the mic. I think the 3 audio input devices are nothing to do with the mic, they're something like "Node 0x07 [Audio Input] wcaps 0x10011b: Stereo Amp-In" for input from an external amp or whatever. So I can't see the hardware for the mic mentioned. I can see some channels named 'mic'. But I guess that is just logical, down to the mixer software, and it hasn't made the connection to the mic hardware.

My output.

/proc/asound/devices

0: [ 0] : control
16: [ 0- 0]: digital audio playback
24: [ 0- 0]: digital audio capture

32: [ 1] : control
33: : timer
48: [ 1- 0]: digital audio playback
56: [ 1- 0]: digital audio capture

64: [ 2] : control
80: [ 2- 0]: digital audio playback
88: [ 2- 0]: digital audio capture

Note that these in essence identify what hw:0,0 and such represent.

/proc/asound/cards

0 [IXP ]: ATIIXP - ATI IXP
ATI IXP rev 2 with unknown codec at 0xd0003400, irq 17
1 [Modem ]: ATIIXP-MODEM - ATI IXP Modem
ATI IXP Modem rev 2 at 0xd0003800, irq 17
2 [MobilePre ]: USB-Audio - MobilePre
M Audio MobilePre at usb-0000:00:13.1-2, full speed

/proc/asound/card0/pcm0c/info

card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: ATI IXP AC97
name: ATI IXP AC97
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 1

pcm0c is the capture device. Alternatively you could always install the latest alsa from source on your current kernel and distro. Most times that just means compiling alsa-lib and alsa-driver in that order. I haven't been able to download them on my end. Probably an MTU conflict in the stream between here and there as no one else seems to have this issue. But in theory it'd go something like this...

$ mozilla http://www.alsa-project.org/

download alsa-driver-1.0.23.tar.bz2 and alsa-lib-1.0.23.tar.bz2

$ tar-xjvpf alsa-driver-1.0.23.tar.bz2
$ tar-xjvpf alsa-lib-1.0.23.tar.bz2

$ cd alsa-lib-1.0.23
$ ./configure --prefix=/usr
$ make
$ su
(password)
# make install
(alternatively sudo make install)
# exit

$ cd ../alsa-driver-1.0.23
$ ./configure --prefix=/usr --with-sequencer=yes --with-oss=yes --with-drivers=hda_intel,usb_audio
$ make
$ su
# make install
# exit

And reboot or restart alsa. Reset your mixer levels and such as well. Just one of many alternatives. And it assumes that you have all of the build tools. gcc, build-essential, ncurses, kernel-headers, ... . . . and all of the *-dev packages needed to compile from sources. I'm a bit rusty on it, so don't take my syntaxes above as stone. Use --help on configure when needed.

Many means to an end.