At Tue, 02 Aug 2011 15:18:18 -0400, Pavel Roskin wrote:
On 08/02/2011 03:58 AM, Takashi Iwai wrote:
Kailang at Realtek suggested that the verb above is only for ALC269vb, but he found out another workaround (coef idx 7 bit 7).
Could you try the patch below?
It works! However, I needed an extra change for the new code to be executed. Also, I needed to backport the patch to Linux 3.0 (it's wireless-testing.git, but for the sound code, it's essentially Linux 3.0).
This condition is not true on my system:
if (board_config == ALC_MODEL_AUTO) { alc_pick_fixup(codec, NULL, alc269_fixup_tbl, alc269_fixups); alc_apply_fixup(codec, ALC_FIXUP_ACT_PRE_PROBE); }
board_config is 4 (ALC269_DMIC). So the condition needs to be removed for the fixup to be applied. I guess the fixup for EeePC 1005HA should be called elsewhere. I'm not using any module parameters.
OK, then just pass model=auto. It may result in different mixer elements, but mostly it should work. (Actually it's helpful if you can test the auto-parser.)
I get nothing but noise on the sound-2.6/master branch. It happens regardless of whether I'm using one or two channels with arecord.
Does it happen no matter whether patched and/or model option value?
I remember a few cases when I was able to record proper sound with 2 channels on the sound-2.6/master kernel. But most of the time, I would get that noise. It looks like a separate regression.
I could try to bisect it. It's a big investment of time, considering that the system has an Atom CPU, so I'd like to know if there is any interest in that, or there is some patch lying around that would address the noise problem.
Before starting bisecting, please give alsa-info.sh outputs on both working and non-working kernels. Then we can compare the visible difference of register values (although coef stuff isn't exposed there).
thanks,
Takashi