http://bugzilla.novell.com/show_bug.cgi?id=620413 http://bugzilla.novell.com/show_bug.cgi?id=620413#c20 Takashi Iwai <tiwai@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |roberto.helering@everett.nl --- Comment #20 from Takashi Iwai <tiwai@novell.com> 2010-07-26 15:45:02 UTC --- The screenshot doesn't help for the detailed analysis. Always give alsa-info.sh output instead. Also, I'm not interested in the resultant wav output at this moment as long as you see it doesn't work. So far, I have no further clue since I have no hardware. And remote debugging doesn't help for such a case -- you need to figure out by yourself. In general, reduce the test layer as much as possible. Avoid PulseAudio, use ALSA directly via "arecord -Dplughw -vv foo.wav", at best without graphics. Then check the widget connection of the codec. Check which ADC ("Audio Input" widget) is actually used (it can be seen in the codec#* proc file during recording). Follow the widget connection. Check the amp value is properly set (unmuted and adjusted) in the route, between ADC and the input pin in the end. You may need to reconnect the widget via hda-emu directly to a different pin. Some details are found in /usr/src/linux/Documentation/sound/alsa/HD-Audio.txt. If any result is found with the procedure above, let me know. I can build the quirk into the driver code based on your information. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.