I think arecord is simpler and has the same setup as audacity when it comes to the mic.

I tried this:


adam@isengard:~$ cat /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
32: [ 1] : control
33: : timer
56: [ 1- 0]: digital audio capture
adam@isengard:~$ arecord -c1 -Dplughw:0,0 -f cd -vv /dev/null
Recording WAVE '/dev/null' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 92879
tstamp_mode : NONE
period_step : 1
avail_min : 4096
start_threshold : 1
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
#+ | 00%^C
Aborted by signal Interrupt...



I tried all of the capture devices and the only one that works is the last, the USB mic. So why is the stuff in /proc/asound/devices not hooked up with the hardware, which is obviously pumping input through to the speakers?

I hope you stripped my config down. My integrated soundcard takes two devices atiixp + atiixp_modem. Plus a 3rd for the usb-audio (M-Audio Mobile Pre in my case). You probably only need 2 of those 3.

$ arecord --list-devices

You seem to be missing a few spaces between parameter and option on yours. hda-intel is fairly NEW stuff and a bit bleeding edge. Perhaps a custom kernel would improve things in terms of bringing your drivers up to date. My atiixp is at least 4 years old. And I seem to be getting a little resistance getting things to run the way I know they should. And have been able to do in the past (with a bit more customization than I currently have)

$ arecord -f dat -D hw:0,0 test.wav

Not that I normally record from my laptops soundcard. But it's nice to make sure it works on occasion. Meanwhile alsa-project.org's ftp seems to be down. Fortunately alsa is included in the 2.6 series kernels. Unfortunately my 2.6.26 distro kernel is too dated I guess. Or they backported a very old version of alsa with it for some reason. Need 1.0.18 or better of alsa to compile the newer jackd. Need the newer jackd to compile mplayer with jack support. Beyond that everything works to one degree or another.

$ jackd -R -d alsa -d hw:2 &
$ timidity -Oj -iA &
$ rosegarden

Just flirting around with midi. Unfortunately no -ao jack in mplayer until I resolve my versioning issues.

This machine is at least 3 years old, maybe 4.

In alsa-base, I removed the debian package config and changed it to what you put above and the only card mentioned is the snd-hda-intel:


I had the USB card in there, and I then tried it without - neither way was any different.

The output of arecord --list-devices:

**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC882 Analog [ALC882 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 1: ALC882 Digital [ALC882 Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: Intel [HDA Intel], device 2: ALC882 Analog [ALC882 Analog]
Subdevices: 2/2
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
card 1: U0x46d0x9a4 [USB Device 0x46d:0x9a4], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

I don't know what more I can say. Java's still throwing errors when trying to output sound, the mic is still piping input direct to the speakers and is unavailable to apps, and those snd-pcm-oss, snd-mixer-oss and snd-seq-oss do not load automatically.

There's all sorts of interesting looking stuff out there, especially for ubuntu, but I could spend days trying to fix this.

You don't think it could be something really basic like the jack is meant for a stereo mic but it's only a mono mic?

That wouldn't really matter much. 1 or 2 channels is the only difference. That's actually the unexpected quirk with my current configuration. I know my mic jack (on the laptop) is mono, and it only lets me capture a stereo track (in arecord). In combination with not being able to download alsa's drivers directly to compile against my current (but ancient) kernel.

You should be able to disable the play through. Java is probably assuming OSS. As long as you don't have artsd, esd, pulse audio, jack, ..... running and keeping the sound card to itself, you should be okay from a certain POV.

You could setup a jack server for your USB mic (or which ever one is bleeding through).

$ jackd -R -d alsa -d hw:2 &

And then run qjackctl to show and sever the connection (play through). Alsamixer sometimes has option for that too. On my Delta 44 I can select to have the input pipe straight to the output. Or not, the default is NOT. Not that I know if that was the original default at this point. It shows up as a text channel in alsamixer. Looks like H/W, then H/W 1, H/W 2, H/W 3 for the for output channels. I can select H/W In, H/W In 1, .... to get playthrough, but I rarely do unless I'm using the TV capture card and watching a VHS tape. You can accomplish this same task with qjackctl if you run via the jack method. Or jack_connect if you're more cli inclined. Basically it's selectable. And probably at the hardware level which shouldn't impact java in any way. Baring obvious potential feedback issues.


Hmmm...

http://forum.ubuntu-fr.org/viewtopic.php?id=355943

Looks like this one has an ACPI resource conflict. Same USB input and hda-intel. You might try a reboot with the USB device disconnected. See if you have issues with just the hda-intel device at that point. If not, then plug in the USB device and see if it triggers an issue.

# cat /var/log/dmesg | grep -i "conflict"
# cat /var/log/kern.log | grep -i "conflict"
# cat /var/log/syslog | grep -i "conflict"

See if you have something like that.

or:
# egrep -i "conflict" /var/log/syslog

various means to an end. My logs are clear (no hits) on that term.

I've got Capture, Capture.0, Capture.1 but I can't disable them in xfce-mixer but not at all in alsamixer.

I changed more stuff in my /etc/modprobe.d/alsa-base config, not sure if that helped, plus had to do a cold boot.

After that, Java started working again. But I forgot to load the oss modules manually after the cold boot, so not sure why Java is working.

I checked for conflict logs - nothing showing.

I recommend remove every sound daemon (artsd, PulseAudio, Jackd, and others) that you have loaded then type the following in separate terminals.

arecord -r 48000 -c 1 | hexdump
alsamixer -V all

Adjust the controls when you see something different being printed from hexdump. In alsamixer, you may have to choose a capture device and set volume for some devices. I suggest do not adjust or use MIC BOOST because it might make it worst. Adjust the volume for capture. To stop or close arecord or hexdump, hit CTRL+C.

This is the best way to setup recording with out wasting space.

Normally, sound card's MIC connector is a three conductor. They are compatible with condenser microphones that needs power to energized the pre-amplifier in the microphone. Dynamic microphones does not need one. This connector is mono. Some notebook computers may include two microphones which adds confusion.

For any distribution, you are the mercy of the maintainers. If you are dealing with pre-compiled packages, you will experience more problems that is out of your control. If you use distributions like Gentoo or Arch then you can control your problems and find a fix.

One thought. Just added the security update manually to my sources.list and noticed updates to libc6-amd64. If you're cpu is NOT 64 bit, you might want to purge these to keep the applications from getting confused. Make them default to 32 bit, since 64 bit doesn't run that well on 32 bit machines.

$ cat /proc/cpuinfo

flags: ..... . . . . . lm .....

If you have lm, you've got a 64 bit cpu. If you have lahf_lm or NO lm, you're NOT a 64 bit x86 processor.

I've got lahf_lm. I checked the installed packages and I don't have anything with 64 in the name.

electro, I've been using this command:

arecord -c 1 -D plughw:0,2 -f cd -vv /dev/null

which displays a cmd line VU meter.

But thanks for the explanations. Interesting. I did try to get some help on the debian list but unfortunately it just went around in circles, which is why I came here. I see quite a few people posting with this error, but most of the time it's just the control is muted. I wish that was me!

Grrr... It looks like debian security updates replaced my snd-atiixp with snd-pcspkr. To make matters worse I seem to be having a difficult time swapping it back as pcsp loads as card 0, even with /etc/modprobe.d/blacklist, some alias stuff, and removing the udev rule for that thing. Perhaps related to your issue if I figure out what's going on here. About the only thing I get out of pcsp is annoying beeps. Audacity wont even load unless I change defaults.pcm.card to 2, my USB soundcard. atiixp-modem still loads, which is the only one that I don't need for anything that I actually use.

are you using stable or testing?

stable / lenny

Added to alsa_custom

blacklisted pcsp and snd-pcspkr

As I try to figure out why they gave it a virtual name that differs from it's real name. It's not like we're limited to 8.3 dos names anymore people. At least not for most of the new stuff. I suppose there are still a few legacy systems in place. Hopefully this corrects the issue. I guess there is some important stuff in those alsa-base things after all.

I'll probably rename alsa_custom to a .conf since that seems to be the direction future things will be held to.

Got my native laptop card back. And re-edited grub.cfg to disable that touchpad tap as click stuff. I still have to redo from source media items. Updates on a customized install can be a bit annoying. I guess I should learn the package management system well enough to create packages. Someday perhaps...

Which java application is giving you the no audio device? Java applets in the web browser? Or java as compiled / run from a CLI? Thinking of doing some sort of strace to see what it's expecting or trying to access in terms of audio devices. Your user should be in the "audio" group. And your audio devices in /dev/ should be assigned to that group. If that's not the case it could be your issue. If that's right, then we still need to dig deeper.

Java from CLI

But it's working again now - I'm not sure what it was that re-enabled it, could have been my changes to the /etc/modprobe.d/alsa-base (I merged some stuff from the original with the stuff you gave me) or it could have been any number of other unknowns. Unknown unknowns that is. I think I've got a handle on the known unknowns

The user is in the audio group.

It was good to get the java audio back - I felt that stuff was slipping out of control. But the original mic problem is still there, if you have any more ideas.

What was the original mic problem again?

Browsers assume card 0 for the most part. You might try launching the app with aoss and see if that helps.

$ aoss <app> <parameters>

In theory it wraps OSS apps to use alsa more directly. Unfortunately for web browsers, when they launch a new tab or new window, those are not wrapped with aoss.

You might be having an indexing issue. If your cards are loading in a different sequence. It might also be a motherboard thing where if it detects a 2nd soundcard it'll disable the integrated one. The symptom of which is if you boot with the webcam unplugged, it'll be different than if you boot with the webcam plugged in. And other udev plus /etc/modules loading sequence issues that might vary depending on how fast this or that runs and who gets there first. udev was actually supposed to address that issue with it's rules (/etc/udev/rules.d/).

If it's a sequence issue, you might be able to adjust after boot.

# /etc/init.d/udev restart

And various alsa* restart and modprobe -r plus modprobe of related modules. It can get tricky if your system isn't behaving how you think it should.