http://bugzilla.novell.com/show_bug.cgi?id=620413
http://bugzilla.novell.com/show_bug.cgi?id=620413#c20
Takashi Iwai changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
InfoProvider| |roberto.helering@everett.nl
--- Comment #20 from Takashi Iwai 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.