Re: [alsa-devel] No sound on Quanta KN1 with kernel 3.4
At Sat, 14 Apr 2012 22:52:09 +0200, Uros Vampl wrote:
On 14.04.12 21:25, Takashi Iwai wrote:
At Sat, 14 Apr 2012 19:10:30 +0200, Uros Vampl wrote:
Hi,
as I wrote on the -users list, I don't have sound anymore in kernel 3.4. I was told to post the output of alsa-info.sh here, so here I am. The requested output is attached.
Could you give the alsa-info.sh output on the working kernel? In that way, it becomes easier to spot out what caused the problem.
Attached.
Could you try the patch below?
Also, which output is missing? Is it a speaker output or a line-out jack? Basically it's a bug of BIOS that doesn't give the proper association number for the corresponding pin 0x0f. The patch is just to make less restrictive.
But, if it's a laptop, the corresponding pin is likely a speaker output, so it'd be better to fix the pin-default value itself via pinfix table.
thanks,
Takashi
--- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 7a8fcc4..83f0b13 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -4957,8 +4957,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, if (!(wid_caps & AC_WCAP_STEREO)) if (!cfg->mono_out_pin) cfg->mono_out_pin = nid; - if (!assoc) - continue; if (!assoc_line_out) assoc_line_out = assoc; else if (assoc_line_out != assoc)
On 16.04.12 16:07, Takashi Iwai wrote:
Could you try the patch below?
Also, which output is missing? Is it a speaker output or a line-out jack? Basically it's a bug of BIOS that doesn't give the proper association number for the corresponding pin 0x0f. The patch is just to make less restrictive.
But, if it's a laptop, the corresponding pin is likely a speaker output, so it'd be better to fix the pin-default value itself via pinfix table.
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
Regards, Uroš
At Mon, 16 Apr 2012 19:56:09 +0200, Uros Vampl wrote:
On 16.04.12 16:07, Takashi Iwai wrote:
Could you try the patch below?
Also, which output is missing? Is it a speaker output or a line-out jack? Basically it's a bug of BIOS that doesn't give the proper association number for the corresponding pin 0x0f. The patch is just to make less restrictive.
But, if it's a laptop, the corresponding pin is likely a speaker output, so it'd be better to fix the pin-default value itself via pinfix table.
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
OK, I'll send another patch tomorrow. But the previous patch should work, still. Make sure that you adjusted and unmuted the mixer elements after applying the patch. There should be some new mixer elements.
If it still doesn't work after the mixer adjustment, give alsa-info.sh output again.
Takashi
At Mon, 16 Apr 2012 21:25:01 +0200, Takashi Iwai wrote:
At Mon, 16 Apr 2012 19:56:09 +0200, Uros Vampl wrote:
On 16.04.12 16:07, Takashi Iwai wrote:
Could you try the patch below?
Also, which output is missing? Is it a speaker output or a line-out jack? Basically it's a bug of BIOS that doesn't give the proper association number for the corresponding pin 0x0f. The patch is just to make less restrictive.
But, if it's a laptop, the corresponding pin is likely a speaker output, so it'd be better to fix the pin-default value itself via pinfix table.
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
OK, I'll send another patch tomorrow. But the previous patch should work, still. Make sure that you adjusted and unmuted the mixer elements after applying the patch. There should be some new mixer elements.
If it still doesn't work after the mixer adjustment, give alsa-info.sh output again.
Also, there are many bogus input pins on your device. Which physical inputs are on the machine? BIOS advertises that there are front-mic, rear-mic, line-in, aux-in and CD. Do all these work properly? You can choose it from "Input Source" mixer enum.
Also, it also advertises SPDIF input and output. Are really both on your machine?
Takashi
On 18.04.12 10:05, Takashi Iwai wrote:
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
OK, I'll send another patch tomorrow. But the previous patch should work, still. Make sure that you adjusted and unmuted the mixer elements after applying the patch. There should be some new mixer elements.
If it still doesn't work after the mixer adjustment, give alsa-info.sh output again.
Also, there are many bogus input pins on your device. Which physical inputs are on the machine? BIOS advertises that there are front-mic, rear-mic, line-in, aux-in and CD. Do all these work properly? You can choose it from "Input Source" mixer enum.
Also, it also advertises SPDIF input and output. Are really both on your machine?
The only physical input is mic-in. But there's also an integrated microphone. In kernel 3.3 the intergrated mic is simply "Mic" and works for both playback and capture. I don't have an external mic to test.
In kernel 3.4 I still don't have sound, even with the patch (I unmuted everything there was to unmute, then muted SPDIF, nothing produced sound), so I could only test capture - "Rear Mic" captures from the integrated microphone.
I assume "Front Mic" would work for an external microphone, and maybe CD is for listening to audio CDs? The CD drive broke a few years back, so I can't test it.
No idea about SPDIF-in, but headphone-out doubles as SPDIF-out. There's a red light inside the jack, and if I unmute SPDIF, the light goes on. I remember it was like that also in Windows. I don't have appropriate hardware to test if it actually works.
Attached is a alsa-info.txt with the patch. There are some differences compared to without patch, but like I said above, still no sound.
Regards, Uroš
On 18.04.12 11:55, Uros Vampl wrote:
The only physical input is mic-in. But there's also an integrated microphone. In kernel 3.3 the intergrated mic is simply "Mic" and works for both playback and capture. I don't have an external mic to test.
In kernel 3.4 I still don't have sound, even with the patch (I unmuted everything there was to unmute, then muted SPDIF, nothing produced sound), so I could only test capture - "Rear Mic" captures from the integrated microphone.
I assume "Front Mic" would work for an external microphone, and maybe CD is for listening to audio CDs? The CD drive broke a few years back, so I can't test it.
No idea about SPDIF-in, but headphone-out doubles as SPDIF-out. There's a red light inside the jack, and if I unmute SPDIF, the light goes on. I remember it was like that also in Windows. I don't have appropriate hardware to test if it actually works.
Attached is a alsa-info.txt with the patch. There are some differences compared to without patch, but like I said above, still no sound.
Looking at the various alsa-info.txt files I've sent, I think I know which crucial mixer control is missing in kernel 3.4, causing me to not have sound - "Front". It's there with kernel 3.3 and controls volume/mute of both speakers and headphones (the "Headphone" control does nothing). It's not there in kernel 3.4, with or without patch.
Regards, Uroš
At Wed, 18 Apr 2012 11:55:45 +0200, Uros Vampl wrote:
On 18.04.12 10:05, Takashi Iwai wrote:
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
OK, I'll send another patch tomorrow. But the previous patch should work, still. Make sure that you adjusted and unmuted the mixer elements after applying the patch. There should be some new mixer elements.
If it still doesn't work after the mixer adjustment, give alsa-info.sh output again.
Also, there are many bogus input pins on your device. Which physical inputs are on the machine? BIOS advertises that there are front-mic, rear-mic, line-in, aux-in and CD. Do all these work properly? You can choose it from "Input Source" mixer enum.
Also, it also advertises SPDIF input and output. Are really both on your machine?
The only physical input is mic-in. But there's also an integrated microphone. In kernel 3.3 the intergrated mic is simply "Mic" and works for both playback and capture. I don't have an external mic to test.
You can use even a headphone although the recording level is low. Just plug your headphone into the mic jack and shout.
In kernel 3.4 I still don't have sound, even with the patch (I unmuted everything there was to unmute, then muted SPDIF, nothing produced sound), so I could only test capture - "Rear Mic" captures from the integrated microphone.
OK.
I assume "Front Mic" would work for an external microphone, and maybe CD is for listening to audio CDs? The CD drive broke a few years back, so I can't test it.
On most of laptops, it's already deprecated. So we can drop it.
No idea about SPDIF-in,
If it has no jack, then we can drop it.
but headphone-out doubles as SPDIF-out. There's a red light inside the jack, and if I unmute SPDIF, the light goes on. I remember it was like that also in Windows. I don't have appropriate hardware to test if it actually works.
OK, then it must be kept.
Attached is a alsa-info.txt with the patch. There are some differences compared to without patch, but like I said above, still no sound.
Then the speaker pin is not 0x0f but 0x11.
I'll cook up the test patch based on the current information and post it later.
thanks,
Takashi
At Wed, 18 Apr 2012 12:27:09 +0200, Takashi Iwai wrote:
At Wed, 18 Apr 2012 11:55:45 +0200, Uros Vampl wrote:
On 18.04.12 10:05, Takashi Iwai wrote:
It's a laptop. There's no sound, not from internal speakers, not from headphone out. There is a mild crackling sound when the module is loaded, but that's it. The patch does not change things.
OK, I'll send another patch tomorrow. But the previous patch should work, still. Make sure that you adjusted and unmuted the mixer elements after applying the patch. There should be some new mixer elements.
If it still doesn't work after the mixer adjustment, give alsa-info.sh output again.
Also, there are many bogus input pins on your device. Which physical inputs are on the machine? BIOS advertises that there are front-mic, rear-mic, line-in, aux-in and CD. Do all these work properly? You can choose it from "Input Source" mixer enum.
Also, it also advertises SPDIF input and output. Are really both on your machine?
The only physical input is mic-in. But there's also an integrated microphone. In kernel 3.3 the intergrated mic is simply "Mic" and works for both playback and capture. I don't have an external mic to test.
You can use even a headphone although the recording level is low. Just plug your headphone into the mic jack and shout.
In kernel 3.4 I still don't have sound, even with the patch (I unmuted everything there was to unmute, then muted SPDIF, nothing produced sound), so I could only test capture - "Rear Mic" captures from the integrated microphone.
OK.
I assume "Front Mic" would work for an external microphone, and maybe CD is for listening to audio CDs? The CD drive broke a few years back, so I can't test it.
On most of laptops, it's already deprecated. So we can drop it.
No idea about SPDIF-in,
If it has no jack, then we can drop it.
but headphone-out doubles as SPDIF-out. There's a red light inside the jack, and if I unmute SPDIF, the light goes on. I remember it was like that also in Windows. I don't have appropriate hardware to test if it actually works.
OK, then it must be kept.
Attached is a alsa-info.txt with the patch. There are some differences compared to without patch, but like I said above, still no sound.
Then the speaker pin is not 0x0f but 0x11.
I'll cook up the test patch based on the current information and post it later.
Below is the test patch. Again, adjust the mixer volumes after applying the patch. Now you should have "Headphone" and "Speaker" volumes & switches.
Also, the speaker is muted automatically when the headphone is plugged. For testing the speaker, unplug the headphone.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2508f81..1231a17 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4861,6 +4861,7 @@ enum { ALC260_FIXUP_GPIO1_TOGGLE, ALC260_FIXUP_REPLACER, ALC260_FIXUP_HP_B1900, + ALC260_FIXUP_KN1, };
static void alc260_gpio1_automute(struct hda_codec *codec) @@ -4938,7 +4939,25 @@ static const struct alc_fixup alc260_fixups[] = { .v.func = alc260_fixup_gpio1_toggle, .chained = true, .chain_id = ALC260_FIXUP_COEF, - } + }, + [ALC260_FIXUP_KN1] = { + .type = ALC_FIXUP_PINS, + .v.pins = (const struct alc_pincfg[]) { + { 0x10, 0x02214000 }, /* HP */ + { 0x11, 0x99130110 }, /* speaker */ + { 0x12, 0x90a60160 }, /* int mic */ + { 0x13, 0x02a19000 }, /* ext mic */ + { 0x18, 0x01446000 }, /* SPDIF out */ + /* disable bogus I/O pins */ + { 0x0f, 0x411111f0 }, + { 0x14, 0x411111f0 }, + { 0x15, 0x411111f0 }, + { 0x16, 0x411111f0 }, + { 0x17, 0x411111f0 }, + { 0x19, 0x411111f0 }, + { } + } + }, };
static const struct snd_pci_quirk alc260_fixup_tbl[] = { @@ -4948,6 +4967,7 @@ static const struct snd_pci_quirk alc260_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x280a, "HP dc5750", ALC260_FIXUP_HP_DC5750), SND_PCI_QUIRK(0x103c, 0x30ba, "HP Presario B1900", ALC260_FIXUP_HP_B1900), SND_PCI_QUIRK(0x1509, 0x4540, "Favorit 100XS", ALC260_FIXUP_GPIO1), + SND_PCI_QUIRK(0x152d, 0x0729, "Quanta KN1", ALC260_FIXUP_KN1), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_FIXUP_REPLACER), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_FIXUP_COEF), {}
On 18.04.12 12:32, Takashi Iwai wrote:
Below is the test patch. Again, adjust the mixer volumes after applying the patch. Now you should have "Headphone" and "Speaker" volumes & switches.
Also, the speaker is muted automatically when the headphone is plugged. For testing the speaker, unplug the headphone.
Still no sound, not speakers, not headphones. Did you see my other mail about the "Front" control?
Also, there's only one capture control now. Shouldn't I be able to choose whether to capture from internal or external mic?
Attached is alsa-info.txt with the new patch.
Regards, Uroš
At Wed, 18 Apr 2012 13:36:55 +0200, Uros Vampl wrote:
On 18.04.12 12:32, Takashi Iwai wrote:
Below is the test patch. Again, adjust the mixer volumes after applying the patch. Now you should have "Headphone" and "Speaker" volumes & switches.
Also, the speaker is muted automatically when the headphone is plugged. For testing the speaker, unplug the headphone.
Still no sound, not speakers, not headphones. Did you see my other mail about the "Front" control?
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.
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.
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.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2508f81..c826a6d 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4861,6 +4861,7 @@ enum { ALC260_FIXUP_GPIO1_TOGGLE, ALC260_FIXUP_REPLACER, ALC260_FIXUP_HP_B1900, + ALC260_FIXUP_KN1, };
static void alc260_gpio1_automute(struct hda_codec *codec) @@ -4938,7 +4939,25 @@ static const struct alc_fixup alc260_fixups[] = { .v.func = alc260_fixup_gpio1_toggle, .chained = true, .chain_id = ALC260_FIXUP_COEF, - } + }, + [ALC260_FIXUP_KN1] = { + .type = ALC_FIXUP_PINS, + .v.pins = (const struct alc_pincfg[]) { + { 0x0f, 0x99130110 }, /* speaker */ + { 0x10, 0x02214000 }, /* HP */ + { 0x12, 0x90a60160 }, /* int mic */ + { 0x13, 0x02a19000 }, /* ext mic */ + { 0x18, 0x01446000 }, /* SPDIF out */ + /* disable bogus I/O pins */ + { 0x11, 0x411111f0 }, + { 0x14, 0x411111f0 }, + { 0x15, 0x411111f0 }, + { 0x16, 0x411111f0 }, + { 0x17, 0x411111f0 }, + { 0x19, 0x411111f0 }, + { } + } + }, };
static const struct snd_pci_quirk alc260_fixup_tbl[] = { @@ -4948,6 +4967,7 @@ static const struct snd_pci_quirk alc260_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x280a, "HP dc5750", ALC260_FIXUP_HP_DC5750), SND_PCI_QUIRK(0x103c, 0x30ba, "HP Presario B1900", ALC260_FIXUP_HP_B1900), SND_PCI_QUIRK(0x1509, 0x4540, "Favorit 100XS", ALC260_FIXUP_GPIO1), + SND_PCI_QUIRK(0x152d, 0x0729, "Quanta KN1", ALC260_FIXUP_KN1), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_FIXUP_REPLACER), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_FIXUP_COEF), {}
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?
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?
Regards, Uroš
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:
On 18.04.12 18:41, Takashi Iwai wrote:
Ah, does it affect both? What happens if you change the pin 0x10? Does it affect the headphone or speaker output?
Pin 0x0f affects both. Pin 0x10 affects neither.
Does the headphone output work with 3.4 kernel at all?
No. I always tested both speakers and headphones with each patch (and without patches). There was never any sound from either of the two.
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.
This patch does the trick! First I tried it with the patch that deletes two lines from hda_codec.c, worked already, but there was no Speaker control. Then I instead tried with the patch that sets pin 0x0f. Sound works and I have a Speaker control. Interesting thing though, the Headphone control does nothing and the Speaker control affects both speakers and headphones. Maybe pin 0x10 is bogus too.
Also interesting, the Auto-Mute control does nothing. No matter what it's set to, when I plug in headphones the speakers go silent. It seems the machine has hardware auto-mute handling.
Thank you for your work, I now have sound again!
Regards, Uroš
At Wed, 18 Apr 2012 19:33:35 +0200, Uros Vampl wrote:
On 18.04.12 18:41, Takashi Iwai wrote:
Ah, does it affect both? What happens if you change the pin 0x10? Does it affect the headphone or speaker output?
Pin 0x0f affects both. Pin 0x10 affects neither.
Does the headphone output work with 3.4 kernel at all?
No. I always tested both speakers and headphones with each patch (and without patches). There was never any sound from either of the two.
OK. This explains lots.
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.
This patch does the trick! First I tried it with the patch that deletes two lines from hda_codec.c, worked already, but there was no Speaker control. Then I instead tried with the patch that sets pin 0x0f. Sound works and I have a Speaker control. Interesting thing though, the Headphone control does nothing and the Speaker control affects both speakers and headphones. Maybe pin 0x10 is bogus too.
Also interesting, the Auto-Mute control does nothing. No matter what it's set to, when I plug in headphones the speakers go silent. It seems the machine has hardware auto-mute handling.
Thank you for your work, I now have sound again!
The patch below is the integrated fix patch. Try this one instead of the all previous fixes. Again with this patch, you'll have only "Master" volume, as both speaker and headphone share the same pin, thus no individual amps are present.
Hopefully this works for you.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2508f81..e65e354 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1445,6 +1445,13 @@ enum { ALC_FIXUP_ACT_BUILD, };
+static void alc_apply_pincfgs(struct hda_codec *codec, + const struct alc_pincfg *cfg) +{ + for (; cfg->nid; cfg++) + snd_hda_codec_set_pincfg(codec, cfg->nid, cfg->val); +} + static void alc_apply_fixup(struct hda_codec *codec, int action) { struct alc_spec *spec = codec->spec; @@ -1478,9 +1485,7 @@ static void alc_apply_fixup(struct hda_codec *codec, int action) snd_printdd(KERN_INFO "hda_codec: %s: " "Apply pincfg for %s\n", codec->chip_name, modelname); - for (; cfg->nid; cfg++) - snd_hda_codec_set_pincfg(codec, cfg->nid, - cfg->val); + alc_apply_pincfgs(codec, cfg); break; case ALC_FIXUP_VERBS: if (action != ALC_FIXUP_ACT_PROBE || !fix->v.verbs) @@ -4861,6 +4866,7 @@ enum { ALC260_FIXUP_GPIO1_TOGGLE, ALC260_FIXUP_REPLACER, ALC260_FIXUP_HP_B1900, + ALC260_FIXUP_KN1, };
static void alc260_gpio1_automute(struct hda_codec *codec) @@ -4888,6 +4894,36 @@ static void alc260_fixup_gpio1_toggle(struct hda_codec *codec, } }
+static void alc260_fixup_kn1(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + static const struct alc_pincfg pincfgs[] = { + { 0x0f, 0x02214000 }, /* HP/speaker */ + { 0x12, 0x90a60160 }, /* int mic */ + { 0x13, 0x02a19000 }, /* ext mic */ + { 0x18, 0x01446000 }, /* SPDIF out */ + /* disable bogus I/O pins */ + { 0x10, 0x411111f0 }, + { 0x11, 0x411111f0 }, + { 0x14, 0x411111f0 }, + { 0x15, 0x411111f0 }, + { 0x16, 0x411111f0 }, + { 0x17, 0x411111f0 }, + { 0x19, 0x411111f0 }, + { } + }; + + switch (action) { + case ALC_FIXUP_ACT_PRE_PROBE: + alc_apply_pincfgs(codec, pincfgs); + break; + case ALC_FIXUP_ACT_PROBE: + spec->init_amp = ALC_INIT_NONE; + break; + } +} + static const struct alc_fixup alc260_fixups[] = { [ALC260_FIXUP_HP_DC5750] = { .type = ALC_FIXUP_PINS, @@ -4938,7 +4974,11 @@ static const struct alc_fixup alc260_fixups[] = { .v.func = alc260_fixup_gpio1_toggle, .chained = true, .chain_id = ALC260_FIXUP_COEF, - } + }, + [ALC260_FIXUP_KN1] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc260_fixup_kn1, + }, };
static const struct snd_pci_quirk alc260_fixup_tbl[] = { @@ -4948,6 +4988,7 @@ static const struct snd_pci_quirk alc260_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x280a, "HP dc5750", ALC260_FIXUP_HP_DC5750), SND_PCI_QUIRK(0x103c, 0x30ba, "HP Presario B1900", ALC260_FIXUP_HP_B1900), SND_PCI_QUIRK(0x1509, 0x4540, "Favorit 100XS", ALC260_FIXUP_GPIO1), + SND_PCI_QUIRK(0x152d, 0x0729, "Quanta KN1", ALC260_FIXUP_KN1), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_FIXUP_REPLACER), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_FIXUP_COEF), {}
At Wed, 18 Apr 2012 20:43:51 +0200, Takashi Iwai wrote:
At Wed, 18 Apr 2012 19:33:35 +0200, Uros Vampl wrote:
On 18.04.12 18:41, Takashi Iwai wrote:
Ah, does it affect both? What happens if you change the pin 0x10? Does it affect the headphone or speaker output?
Pin 0x0f affects both. Pin 0x10 affects neither.
Does the headphone output work with 3.4 kernel at all?
No. I always tested both speakers and headphones with each patch (and without patches). There was never any sound from either of the two.
OK. This explains lots.
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.
This patch does the trick! First I tried it with the patch that deletes two lines from hda_codec.c, worked already, but there was no Speaker control. Then I instead tried with the patch that sets pin 0x0f. Sound works and I have a Speaker control. Interesting thing though, the Headphone control does nothing and the Speaker control affects both speakers and headphones. Maybe pin 0x10 is bogus too.
Also interesting, the Auto-Mute control does nothing. No matter what it's set to, when I plug in headphones the speakers go silent. It seems the machine has hardware auto-mute handling.
Thank you for your work, I now have sound again!
The patch below is the integrated fix patch. Try this one instead of the all previous fixes. Again with this patch, you'll have only "Master" volume, as both speaker and headphone share the same pin, thus no individual amps are present.
Hopefully this works for you.
BTW, has the auto-mute via HP plug ever worked with your machine?
If not, try the patch below instead. It might be that your machine needs a similar trick like some other ALC260 laptops.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2508f81..7de3502 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -1445,6 +1445,13 @@ enum { ALC_FIXUP_ACT_BUILD, };
+static void alc_apply_pincfgs(struct hda_codec *codec, + const struct alc_pincfg *cfg) +{ + for (; cfg->nid; cfg++) + snd_hda_codec_set_pincfg(codec, cfg->nid, cfg->val); +} + static void alc_apply_fixup(struct hda_codec *codec, int action) { struct alc_spec *spec = codec->spec; @@ -1478,9 +1485,7 @@ static void alc_apply_fixup(struct hda_codec *codec, int action) snd_printdd(KERN_INFO "hda_codec: %s: " "Apply pincfg for %s\n", codec->chip_name, modelname); - for (; cfg->nid; cfg++) - snd_hda_codec_set_pincfg(codec, cfg->nid, - cfg->val); + alc_apply_pincfgs(codec, cfg); break; case ALC_FIXUP_VERBS: if (action != ALC_FIXUP_ACT_PROBE || !fix->v.verbs) @@ -4861,6 +4866,7 @@ enum { ALC260_FIXUP_GPIO1_TOGGLE, ALC260_FIXUP_REPLACER, ALC260_FIXUP_HP_B1900, + ALC260_FIXUP_KN1, };
static void alc260_gpio1_automute(struct hda_codec *codec) @@ -4888,6 +4894,36 @@ static void alc260_fixup_gpio1_toggle(struct hda_codec *codec, } }
+static void alc260_fixup_kn1(struct hda_codec *codec, + const struct alc_fixup *fix, int action) +{ + struct alc_spec *spec = codec->spec; + static const struct alc_pincfg pincfgs[] = { + { 0x0f, 0x02214000 }, /* HP/speaker */ + { 0x12, 0x90a60160 }, /* int mic */ + { 0x13, 0x02a19000 }, /* ext mic */ + { 0x18, 0x01446000 }, /* SPDIF out */ + /* disable bogus I/O pins */ + { 0x10, 0x411111f0 }, + { 0x11, 0x411111f0 }, + { 0x14, 0x411111f0 }, + { 0x15, 0x411111f0 }, + { 0x16, 0x411111f0 }, + { 0x17, 0x411111f0 }, + { 0x19, 0x411111f0 }, + { } + }; + + switch (action) { + case ALC_FIXUP_ACT_PRE_PROBE: + alc_apply_pincfgs(codec, pincfgs); + break; + case ALC_FIXUP_ACT_PROBE: + spec->init_amp = ALC_INIT_NONE; + break; + } +} + static const struct alc_fixup alc260_fixups[] = { [ALC260_FIXUP_HP_DC5750] = { .type = ALC_FIXUP_PINS, @@ -4938,7 +4974,13 @@ static const struct alc_fixup alc260_fixups[] = { .v.func = alc260_fixup_gpio1_toggle, .chained = true, .chain_id = ALC260_FIXUP_COEF, - } + }, + [ALC260_FIXUP_KN1] = { + .type = ALC_FIXUP_FUNC, + .v.func = alc260_fixup_kn1, + .chained = true, + .chain_id = ALC260_FIXUP_GPIO1_TOGGLE, + }, };
static const struct snd_pci_quirk alc260_fixup_tbl[] = { @@ -4948,6 +4990,7 @@ static const struct snd_pci_quirk alc260_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x280a, "HP dc5750", ALC260_FIXUP_HP_DC5750), SND_PCI_QUIRK(0x103c, 0x30ba, "HP Presario B1900", ALC260_FIXUP_HP_B1900), SND_PCI_QUIRK(0x1509, 0x4540, "Favorit 100XS", ALC260_FIXUP_GPIO1), + SND_PCI_QUIRK(0x152d, 0x0729, "Quanta KN1", ALC260_FIXUP_KN1), SND_PCI_QUIRK(0x161f, 0x2057, "Replacer 672V", ALC260_FIXUP_REPLACER), SND_PCI_QUIRK(0x1631, 0xc017, "PB V7900", ALC260_FIXUP_COEF), {}
On 18.04.12 20:43, Takashi Iwai wrote:
The patch below is the integrated fix patch. Try this one instead of the all previous fixes. Again with this patch, you'll have only "Master" volume, as both speaker and headphone share the same pin, thus no individual amps are present.
Hopefully this works for you.
Yes, it works.
BTW, has the auto-mute via HP plug ever worked with your machine?
Yes, always. So no special treatment is needed in this case.
Thanks again, Uroš
At Wed, 18 Apr 2012 22:27:11 +0200, Uros Vampl wrote:
On 18.04.12 20:43, Takashi Iwai wrote:
The patch below is the integrated fix patch. Try this one instead of the all previous fixes. Again with this patch, you'll have only "Master" volume, as both speaker and headphone share the same pin, thus no individual amps are present.
Hopefully this works for you.
Yes, it works.
BTW, has the auto-mute via HP plug ever worked with your machine?
Yes, always. So no special treatment is needed in this case.
Great. Now I merged the fix patch to sound git tree. Will be included in the next pull request to 3.4.
thanks,
Takashi
participants (2)
-
Takashi Iwai -
Uros Vampl