Comment 11 for bug 42718

Revision history for this message
Daniel T Chen (crimsun) wrote : Re: Sound capture on Thinkpad T20, T21, T22 not working

There seems to be _tremendous_ confusion regarding the inability to capture audible audio in Linux on PCI sound devices. For the sake of good bug reporting practices, I'm going to enumerate several commands, the output from which all audio bug reports should include.

1) tail -2 /proc/asound/oss/sndstat

The above command lists the codecs involved. The output from this command is _vital_. Different codecs pushing the same driver (say, intel8x0, emu10k1, or hda-intel) exhibit a huge variation in errata. This bug report alone covers _four_ distinct codecs, none of which are solely to blame. See the following point:

2) amixer

It is _imperative_ that you include the amixer output from your preferred (the one that's giving you said recording problems) audio device. The community has spent years documenting known mixer issues on http://alsa.opensrc.org/ (see drivers). For instance, many of the codecs driving cs46xx, emu10k1, and intel8x0 require multiple elements to be selected, unmuted, and raised to audible levels.

3) lspci -nv

The actual {sub,}{vendor,device} IDs are important. That's how we track whether something exists as a quirk or needs to be added/modified.

4) asoundconf list

This script command (which is really just filtered cat /proc/asound/cards) lists the enumerated sound devices on your system.

5) cat /etc/asound.conf ~/.asoundrc*

We need to know if you've modified any runtime configuration files that affect how alsa-lib interacts with your sound devices. The nonexistence of the above files is not a problem.

6) dmesg

Many codecs and drivers, upon initialisation, will spit something via printk() into the kernel ring buffer. Any diagnostic messages will appear in this output.

And last but certainly not least:

7) cat /proc/interrupts

Sound devices require resources. We need to see if those resources are properly assigned.