Re: No sound on Quanta KN1 with kernel 3.4

[Takashi Iwai <tiwai@suse.de>]

At Wed, 18 Apr 2012 18:25:27 +0200,
Uros Vampl wrote:
> 
> On 18.04.12 14:16, Takashi Iwai wrote:
> > Yes, but it alone doesn't help for analysis because it's already an
> > abstracted mixer element.  We need to figure out which pin corresponds
> > to the speaker output.  It must be either 0x0f or 0x11.
> > 
> > BTW, any reason to set the "Speaker" volume so low?  It's almost
> > inaudible.  Raise this volume.
> 
> No reason. I tried again with all volume sliders to the max, still no 
> sound.
> 
> > If raising volume doesn't change, and if you can still run the older
> > kernel, try to change the pin control via hda-verb like:
> > 	# hda-verb /dev/snd/hwC0D0 0x0f SET_PIN_WID 0x00
> > and check whether the speaker still works.  If 0x0f doesn't change,
> > try 0x11,
> > 	# hda-verb /dev/snd/hwC0D0 0x11 SET_PIN_WID 0x00
> > 
> > If the pin 0x0f actually changes the speaker output, use the patch
> > below instead of the previous one.
> 
> By older kernel, you mean 3.3? If I do
>        # hda-verb /dev/snd/hwC0D0 0x0f SET_PIN_WID 0x00
> on 3.3, sound disappears. On both speakers and headphones. Doing
>        # hda-verb /dev/snd/hwC0D0 0x0f SET_PIN_WID 0x40
> turns sound back on. That means we have our pin, right?

Ah, does it affect both?
What happens if you change the pin 0x10?  Does it affect the headphone
or speaker output?

> Well, I tried the new patch which sets 0x0f as the speaker pin, no 
> sound. Attached is alsa-info with this patch.
> 
> > > Also, there's only one capture control now.
> > 
> > This is correct.  When there are only internal and external mics,
> > the driver enables the auto-mic switching mode.
> > 
> > > Shouldn't I be able to 
> > > choose whether to capture from internal or external mic?
> > 
> > Just plugging the mic jack should switch to the external mic
> > automatically just like the headphone/speaker switch.
> 
> Ah interesting, that's good info to have.
> 
> So what now? Neither of the patches work. Does the fact that pin 0x0f 
> controls both speakers and headphones on kernel 3.3 provide a clue?

Does the headphone output work with 3.4 kernel at all?

Also, just to be sure, try the patch below in addition to another.
This will disable the COEF setup, and it wasn't applied to previous
models.


Takashi

---
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index 2508f81..15cdc21 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -789,6 +789,7 @@ static void alc_auto_init_amp(struct hda_codec *codec, int type)
 	case ALC_INIT_DEFAULT:
 		switch (codec->vendor_id) {
 		case 0x10ec0260:
+#if 0
 			snd_hda_codec_write(codec, 0x1a, 0,
 					    AC_VERB_SET_COEF_INDEX, 7);
 			tmp = snd_hda_codec_read(codec, 0x1a, 0,
@@ -798,6 +799,7 @@ static void alc_auto_init_amp(struct hda_codec *codec, int type)
 			snd_hda_codec_write(codec, 0x1a, 0,
 					    AC_VERB_SET_PROC_COEF,
 					    tmp | 0x2010);
+#endif
 			break;
 		case 0x10ec0262:
 		case 0x10ec0880: