Bug 102501 - Activate subwoofer on Amilo M1437G
Summary: Activate subwoofer on Amilo M1437G
Status: RESOLVED PATCH_ALREADY_AVAILABLE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-08 17:27 UTC by Jose
Modified: 2016-12-04 09:25 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.19.8
Tree: Mainline
Regression: No


Attachments
Fix patch #1 (1.59 KB, patch)
2015-08-13 16:07 UTC, Takashi Iwai
Details | Diff
Fix patch #2 (1.32 KB, patch)
2015-08-13 16:07 UTC, Takashi Iwai
Details | Diff
Patched patch_realtek.c file with some debug messages. (193.05 KB, text/x-csrc)
2015-09-05 07:18 UTC, Jose
Details
alsa-info with jack headphone plugged (30.04 KB, text/plain)
2015-09-05 12:18 UTC, Jose
Details
alsa-info without jack headphone plugged at boot (30.10 KB, text/plain)
2015-09-05 12:19 UTC, Jose
Details
Patch to set auto_mute_via_amp flag for ALC880 (431 bytes, patch)
2015-09-05 16:46 UTC, Takashi Iwai
Details | Diff
cat /proc/asound/card0/codec#* without jack headphone plugged (9.93 KB, application/octet-stream)
2015-09-06 13:31 UTC, Jose
Details
hda trace of reconfig without plugged headphone (76.04 KB, text/plain)
2015-09-06 13:31 UTC, Jose
Details
cat /proc/asound/card0/codec#1 with jack headphone plugged (9.81 KB, text/plain)
2015-09-08 19:35 UTC, Jose
Details

Description Jose 2015-08-08 17:27:25 UTC
I have managed to activate the subwoofer on this model with hdajackretask.
It only works if a headphone is connected to the jack at boot.

1. Is it possible add a quirk to the driver to activate the good pins according to this model?
2. Is there a way to find why the cable jack is needed.

Details there : http://www.alsa-project.org/db/?f=5f007b1b9f95bba494f4c4167834eb3abf3e14d0
Comment 1 Raymond 2015-08-10 10:08:06 UTC
s/class/sound/hwC0D1/init_pin_configs:
0x14 0x01014010
0x15 0x01011012
0x16 0x01016011
0x17 0x01012014
0x18 0x01a19830
0x19 0x02a19c40
0x1a 0x01813031
0x1b 0x02014c20
0x1c 0x411111f0
0x1d 0x411111f1
0x1e 0x0144111e
0x1f 0x01c46150

/sys/class/sound/hwC0D1/driver_pin_configs:
0x14 0x0121411f
0x15 0x99030120
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0

/sys/class/sound/hwC0D1/user_pin_configs:
0x14 0x0121411f
0x15 0x90170150
0x16 0x90170151
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0
0x1f 0x01c46150

the hda auto parser don't like your BIOS pin default which have Line Out at Ext Front and at Ext Rear

there is a PCI quirk which add HP pin with MISC_NO_PRESENCE 


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/patch/sound/pci/hda/patch_realtek.c?id=ba5338185dd522696f1c0d0957a724a1fdd1f39d


try 

hdajacksensetest -a

to find out whether HP and Mic can be detected when plug and unplug those jacks
Comment 2 Jose 2015-08-10 20:09:57 UTC
(In reply to Raymond from comment #1)
> try 
> 
> hdajacksensetest -a
> 
> to find out whether HP and Mic can be detected when plug and unplug those
> jacks

Thank you for the answer. The HP jack is detected even when I boot without it plugged :

hdajacksensetest -d 1 -a
Pin 0x14 (Green Headphone, Rear side): present = Yes (and No when unplugged)

For the PCI quirk, how can I try it ? Do I have to patch my kernel source and rebuild the sond-hda module or can it be tried by another way.
Comment 3 Raymond 2015-08-11 00:51:14 UTC
it is regression by the above patch since unsol event was enabled

you have to clear the bit 8 of pin default of hp pin 

	[ALC880_FIXUP_F1734] = {
		/* almost compatible with FUJITSU, but no bass and SPDIF */
		.type = ALC_FIXUP_PINS,
		.v.pins = (const struct alc_pincfg[]) {
-			{ 0x14, 0x0121411f }, /* HP */
+			{ 0x14, 0x0121401f }, /* HP */
Comment 4 Jose 2015-08-13 15:31:43 UTC
(In reply to Raymond from comment #3)
> it is regression by the above patch since unsol event was enabled
> 
Sorry if I am silly, but what is "unsol"?
If I clear the bit 8 should I expect the subwoofer to work even without a jack plugged at boot, or just expect not needing the hdajackretask boot hack anymore?
Comment 5 Takashi Iwai 2015-08-13 16:06:26 UTC
Could you try the following two patches, and remove hdajackretask hacks?
Comment 6 Takashi Iwai 2015-08-13 16:07:05 UTC
Created attachment 184831 [details]
Fix patch #1
Comment 7 Takashi Iwai 2015-08-13 16:07:18 UTC
Created attachment 184841 [details]
Fix patch #2
Comment 8 Raymond 2015-08-14 12:13:33 UTC
(In reply to Jos from comment #4)
> (In reply to Raymond from comment #3)
> > it is regression by the above patch since unsol event was enabled
> > 
> Sorry if I am silly, but what is "unsol"?

-	{0x14, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN|ALC_HP_EVENT},

this mean HP was able to auto mute the speaker before that patch but that patch explicity disable jack detection by set bit 8 which mean no jack detection circuit and driver won't enable unsolicited event any more
Comment 9 Jose 2015-08-14 14:34:57 UTC
(In reply to Takashi Iwai from comment #5)
> Could you try the following two patches, and remove hdajackretask hacks?

I only rebuilt the snd_hda_codec_realtek module.

That activates the subwoofer as did the hdajackretask, except the hardware mixers are different, and I can no longer change the sound level of the subwoofer separately. So this not not as good as hdajackretask hack.

Here is patched result :

http://www.alsa-project.org/db/?f=9d874b76db85f5b69af0ce64d4aa594b553c23e3

And I still need to connect a jack at boot ;-)

Thank you for your attention.
Comment 10 Jose 2015-08-14 14:38:36 UTC
(In reply to Jos from comment #9)
 > That activates the subwoofer as did the hdajackretask, except the hardware
> mixers are different, and I can no longer change the sound level of the
> subwoofer separately. So this not not as good as hdajackretask hack.
> 

Sorry, in fact now Normal speakers are "Surround", and Subwoofer is "Center", so this is a good patch. Will this be OK for other laptops?
Only jack at boot keeps us from the perfection.
Comment 11 Takashi Iwai 2015-08-14 15:06:17 UTC
It seems that your patched driver didn't get loaded correctly:
[   12.305437] snd_hda_codec_realtek: no symbol version for module_layout
[   12.386171] snd_hda_codec_realtek: no symbol version for module_layout

so the generic parser took over the role, and the result was from the bogus pin configs.  Please retry the build of modules.
Comment 12 Raymond 2015-08-15 02:26:55 UTC
[   12.386171] snd_hda_codec_realtek: no symbol version for module_layout
[   12.394850] sound hdaudioC0D1: ignore pin 0x1b with mismatching assoc# 0x2 vs 0x1

you are using bios pin default when snd-hda-codec-realtek module cannot be loaded
the auto parser don't like any line out pin at ext front when there is line out at ext rear


[   12.398292] sound hdaudioC0D1: autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[   12.401649] sound hdaudioC0D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   12.405012] sound hdaudioC0D1:    hp_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   12.408327] sound hdaudioC0D1:    mono: mono_out=0x0
[   12.411659] sound hdaudioC0D1:    dig-out=0x1e/0x0
[   12.415044] sound hdaudioC0D1:    inputs:
[   12.422013] sound hdaudioC0D1:      Front Mic=0x19
[   12.425225] sound hdaudioC0D1:      Rear Mic=0x18
[   12.428388] sound hdaudioC0D1:      Line=0x1a
[   12.431532] sound hdaudioC0D1:    dig-in=0x1f
Comment 13 Jose 2015-08-30 08:02:39 UTC
(In reply to Takashi Iwai from comment #11)
> It seems that your patched driver didn't get loaded correctly:
> [   12.305437] snd_hda_codec_realtek: no symbol version for module_layout

I have found that build only a module kills Modules.symlimk file, I could workaround rebuilding the hda whole directory. So now the module is loaded, but the patches do not activate the subwoofer :

http://www.alsa-project.org/db/?f=8a604585993733650b014025f3c030b4b79c33f9

Thanks.
Comment 14 Takashi Iwai 2015-09-04 07:22:32 UTC
Did you really apply *both* patches?  The alsa-info.sh output indicates that you applied only the first one.
Comment 15 Jose 2015-09-04 17:04:45 UTC
(In reply to Takashi Iwai from comment #14)
> Did you really apply *both* patches?  The alsa-info.sh output indicates that
> you applied only the first one.

OMG you are right. I'm sorry about being so silly following instructions.
Now it still does not work with both patches :

http://www.alsa-project.org/db/?f=37ed17106380e2d26407d0962c7241e7bfad0f4e
Comment 16 Takashi Iwai 2015-09-04 17:32:38 UTC
Double-check that it's the result of the patched kernel.
When you look at the alsa-info.sh output in the following part:

/sys/class/sound/hwC0D1/driver_pin_configs:
0x14 0x0121401f
0x15 0x99030120
0x16 0x411111f0
0x17 0x411111f0
0x18 0x411111f0
0x19 0x01a19950
0x1a 0x411111f0
0x1b 0x411111f0
0x1c 0x411111f0
0x1d 0x411111f0
0x1e 0x411111f0

You see that 0x16 contains 0x41111111f0.  This must have been changed by the second patch.  You can put some debug message in patch_alc880() to confirm whether you're running the patched code.
Comment 17 Jose 2015-09-05 07:16:52 UTC
> You see that 0x16 contains 0x41111111f0.  This must have been changed by the
> second patch.

Are you sure? I can see any 0x16 modified line by the patches. Anyway, I added some debug info :

[   14.604615] Starting patch_alc880
[   14.608341] sound hdaudioC0D1: autoconfig: line_outs=1 (0x15/0x0/0x0/0x0/0x0) type:speaker
[   14.611886] sound hdaudioC0D1:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[   14.615384] sound hdaudioC0D1:    hp_outs=1 (0x14/0x0/0x0/0x0/0x0)
[   14.618919] sound hdaudioC0D1:    mono: mono_out=0x0
[   14.622414] sound hdaudioC0D1:    inputs:
[   14.626359] sound hdaudioC0D1:      Mic=0x19
[   14.629837] sound hdaudioC0D1:    dig-in=0x1f
[   14.636324] err = 1
[   14.639870] Applied patch_alc880

More here : http://www.alsa-project.org/db/?f=fa84d57c49642472509dac7e71f10d2b4595b20a

and I attach the patched file with debug messages to let you double check. Thanks.
Comment 18 Jose 2015-09-05 07:18:07 UTC
Created attachment 186751 [details]
Patched patch_realtek.c file with some debug messages.
Comment 19 Takashi Iwai 2015-09-05 08:16:49 UTC
The second patch wasn't applied properly.  In your patch_realtek.c the following lines appear:

	SND_PCI_QUIRK(0x1734, 0x107c, "FSC F1734", ALC880_FIXUP_F1734),
	SND_PCI_QUIRK(0x1734, 0x107c, "FSC Amilo M1437", ALC880_FIXUP_FUJITSU),

Since both point to the same ID, the only first one is taken.

The second patch *replaces* the 1734:107c line with the new one (ALC880_FIXUP_FUJITSU).
Comment 20 Jose 2015-09-05 08:48:46 UTC
(In reply to Takashi Iwai from comment #19)
> The second patch wasn't applied properly.  In your patch_realtek.c the

I'm shy. But at least now it works without the hdajackretask hacks.

So now the last question : can I hope any way to get the subwoofer working without having to plug a headphone in the jack at boot.
Comment 21 Takashi Iwai 2015-09-05 09:21:20 UTC
(In reply to Jos from comment #20)
> So now the last question : can I hope any way to get the subwoofer working
> without having to plug a headphone in the jack at boot.

I didn't follow this part, so far.  Could you tell me what's the exact problem?
Comment 22 Raymond 2015-09-05 09:28:27 UTC
you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not have low pass filter ?

do your subwoofer play both left and right channel ?

speaker-test -c4 -twav -D hw:0,0
Comment 23 Jose 2015-09-05 11:05:42 UTC
(In reply to Takashi Iwai from comment #21)
> I didn't follow this part, so far.  Could you tell me what's the exact
> problem?

If the system is booted without something plugged in the jack, no sound comes from the subwoofer, while it still appears in the alsamixer. I somewhat found that plugging anything, then unplugging it after boot completed, activates sound in the subwoofer.
Comment 24 Jose 2015-09-05 11:07:33 UTC
(In reply to Raymond from comment #22)
> you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not
> have low pass filter ?
> 
> do your subwoofer play both left and right channel ?
> 
> speaker-test -c4 -twav -D hw:0,0

It only plays left channel. I suppose this is an hardware limitation?
Comment 25 Jose 2015-09-05 12:18:50 UTC
Created attachment 186801 [details]
alsa-info with jack headphone plugged
Comment 26 Jose 2015-09-05 12:19:15 UTC
Created attachment 186811 [details]
alsa-info without jack headphone plugged at boot
Comment 27 Raymond 2015-09-05 13:16:57 UTC
it is strange that pincap is zero


Node 0x16 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
  Control: name="Bass Speaker Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Speaker Surround Phantom Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x00000000:
  Pin Default 0x01016011: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x00:
  Unsolicited: tag=00, enabled=0
  Connection: 1
     0x0e
Comment 28 Takashi Iwai 2015-09-05 16:45:25 UTC
Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and the pinctl change screws up the pin setup.

Could you try the patch below in addition?
Comment 29 Takashi Iwai 2015-09-05 16:46:00 UTC
Created attachment 186821 [details]
Patch to set auto_mute_via_amp flag for ALC880
Comment 30 Raymond 2015-09-06 01:26:29 UTC
(In reply to Jos from comment #24)
> (In reply to Raymond from comment #22)
> > you need pulseaudio 7.0 lfe filter (2.1 profile) if your laptop does not
> > have low pass filter ?
> > 
> > do your subwoofer play both left and right channel ?
> > 
> > speaker-test -c4 -twav -D hw:0,0
> 
> It only plays left channel. I suppose this is an hardware limitation?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=ee81abb623cb5e03c182d16871bb4fb34fdc9b4f

do you mean your laptop need to use customised 2.1 channel map instead of default

const struct snd_pcm_chmap_elem snd_pcm_fujitsu_2_1_chmaps[] = {
+	{ .channels = 2,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+	{ .channels = 4,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR,
+		   SNDRV_CHMAP_LFE, SNDRV_CHMAP_NA} },
+	{ }
+};
Comment 31 Raymond 2015-09-06 01:33:46 UTC
it is pulseaudio bug to provide surround 4.0 profile which did not check alsa channel map and pulseaudio channel 


https://bugs.freedesktop.org/show_bug.cgi?id=91471
Comment 32 Jose 2015-09-06 06:53:27 UTC
(In reply to Takashi Iwai from comment #28)
> Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and
> the pinctl change screws up the pin setup.
> 
> Could you try the patch below in addition?

Still no subwoofer sound.
http://www.alsa-project.org/db/?f=1f151adb78b2716f90d49ed872407aaa3f4a0ed2
Comment 33 Jose 2015-09-06 07:03:25 UTC
(In reply to Raymond from comment #31)
> it is pulseaudio bug to provide surround 4.0 profile which did not check
> alsa channel map and pulseaudio channel 
> 
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=91471

In fact 4.0 appears in pavucontrol but is not the default choosen. Sorry I don't understand your answer : do you want me to test the patch of the URL in comment 30 ?
Comment 34 Takashi Iwai 2015-09-06 07:47:35 UTC
(In reply to Jose from comment #32)
> (In reply to Takashi Iwai from comment #28)
> > Yeah, something wrong in the hardware level.  Maybe ALC880 is so buggy and
> > the pinctl change screws up the pin setup.
> > 
> > Could you try the patch below in addition?
> 
> Still no subwoofer sound.
> http://www.alsa-project.org/db/?f=1f151adb78b2716f90d49ed872407aaa3f4a0ed2

OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
This will disable the automatic configuration, so the sound isn't usable at first.  But you'll have the access to /proc/asound/card0/codec#* files, so read them and attach to Bugzilla.  Here the point to check is whether the pin-caps of NID 0x16 is still 0x00.

Suppose you built your kernel with kernel trace feature, try to turn on the tracing of HD-audio events (as root):
  # echo 1 > /sys/kernel/debug/tracing/events/hda

Then configure HD-audio.  Here I assume hwC0D1 (codec#1) is the Realtek one.  If codec#0 is Realtek, use hwC0D0:
  # echo 1 > /sys/class/sound/hwC0D1/reconfig

Read the tracing output
  # cat /sys/kernel/debug/tracing/trace > hda-trace.txt

And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this moment to be sure to verify the state.

Some details about tracing is found in Documentation/sound/alsa/HD-Audio.txt.
Comment 35 Raymond 2015-09-06 09:12:08 UTC
alc880 is the only hda codec which issuse  SET_PIN_SENSE before GET_PIN_SENSE

Do your codec really need SET_PIN_SENSE since it suppose to start impedance measurement which generate noise and event ?


https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=729d55ba972348234759f8e40abf8de020f0d505

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=bfc9902599549736b9c6445e1e2235b8542f64a6
Comment 36 Jose 2015-09-06 13:31:07 UTC
Created attachment 186881 [details]
cat /proc/asound/card0/codec#* without jack headphone plugged
Comment 37 Jose 2015-09-06 13:31:45 UTC
Created attachment 186891 [details]
hda trace of reconfig without plugged headphone
Comment 38 Jose 2015-09-06 13:35:26 UTC
(In reply to Takashi Iwai from comment #34)
> OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
> This will disable the automatic configuration, so the sound isn't usable at
> first.  But you'll have the access to /proc/asound/card0/codec#* files, so
> read them and attach to Bugzilla.  Here the point to check is whether the
> pin-caps of NID 0x16 is still 0x00.

Look like yes, but I let you read the attached file.

> And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this
> moment to be sure to verify the state.
> 

My Mageia distro comes with trace so yes I got hdatrace.txt, see attached file.
I just tested without headphone plugged at boot, I don't know if it is needed to do with with some thing plugged?

http://www.alsa-project.org/db/?f=0752eb3aacf116d34d45d5c5836471415e026df2
Comment 39 Raymond 2015-09-06 16:26:17 UTC
if you can hear high frequency when speaker -test play rear left signal from subwoofer, this mean that your laptop does not have and hardware low oass filter and you need to provide corre ct 2.1 channel map for pulseaudio lfe filter 

those asus laptop external sonic master subwoofer need customised 2.1 channel map 

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=8e38395360844806041ea69ab9690f5f174bc40c


static const struct snd_pcm_chmap_elem asus_pcm_2_1_chmaps[] = {
+	{ .channels = 2,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR } },
+	{ .channels = 4,
+	  .map = { SNDRV_CHMAP_FL, SNDRV_CHMAP_FR,
+		   SNDRV_CHMAP_NA, SNDRV_CHMAP_LFE } }, /* LFE only on right */
+	{ }
+};
Comment 40 Raymond 2015-09-07 01:09:17 UTC
do your laptop have  knob for changing volume?

Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
  Volume-Knob: delta=0, steps=64, direct=0, val=40
  Unsolicited: tag=02, enabled=1
  Connection: 0
Comment 41 Jose 2015-09-07 08:21:26 UTC
(In reply to Raymond from comment #40)
> do your laptop have  knob for changing volume?
> 
> Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
>   Volume-Knob: delta=0, steps=64, direct=0, val=40
>   Unsolicited: tag=02, enabled=1
>   Connection: 0

Yes, it has near the 3.5mm jack. This one has the headset logo and /SPDIF, I suppose it can also output digital through this jack?
Comment 42 Raymond 2015-09-07 09:19:04 UTC
http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/profile-sets/default.conf


headphone belong to stereo profile

after headphone is plugged,  pulseaudio change from 2.1 profile to stereo

but pulseaudio remain at stereo after headphone is plugged
Comment 43 Jose 2015-09-07 17:52:08 UTC
(In reply to Raymond from comment #42)
> but pulseaudio remain at stereo after headphone is plugged

You mean unplugged? Anyway, I don't understand if you are helping me :

1. getting the subwoofer working without jack plugged at boot?

2. making pulseaudio mix left and right channels in the subwoofer?

Thanks.
Comment 44 Raymond 2015-09-08 03:50:12 UTC
7.3.3.15 Pin Sense  

The Pin Sense control returns the Presence Detect status, EDID-Like Data (ELD) Valid, and the impedance measurement of the device attached to the pin.   Some codecs may require that the impedance measurement be triggered by software; in that case, sending the Execute command will cause the impedance measurement to begin.  The “Presence Detect” bit will always be accurate if that functionality is supported by the widget. Note that the Pin Complex Widget may support the generation of an Unsolicited Response to indicate that the Sense Measurement (either the Presence Detect or the Impedance) value has changed, the generation of which implies that the measurement is complete. 


alc880 is the only hda codec which the driver still exec GET_PIN_SENSE before GET_PIN_SENSE as those ADI codecs seem generate event when driver start impedance measurement in an endless loop



* execute pin sense measurement */
static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
{
	u32 pincap;
	u32 val;

	if (!codec->no_trigger_sense) {
		pincap = snd_hda_query_pin_caps(codec, nid);
		if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
			snd_hda_codec_read(codec, nid, 0,
					AC_VERB_SET_PIN_SENSE, 0);
	}
	val = snd_hda_codec_read(codec, nid, 0,
				  AC_VERB_GET_PIN_SENSE, 0);
	if (codec->inv_jack_detect)
		val ^= AC_PINSENSE_PRESENCE;
	return val;
}
Comment 45 Raymond 2015-09-08 03:53:02 UTC
according to hda specification , it only require codec to return PD when receive  GET_PIN_SENSE command
Comment 46 Raymond 2015-09-08 09:37:33 UTC
(In reply to Jose from comment #33)
> (In reply to Raymond from comment #31)
> > it is pulseaudio bug to provide surround 4.0 profile which did not check
> > alsa channel map and pulseaudio channel 
> > 
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=91471
> 
> In fact 4.0 appears in pavucontrol but is not the default choosen. Sorry I
> don't understand your answer : do you want me to test the patch of the URL
> in comment 30 ?

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/pulse/channelmap.c

there is no useful function to compare alsa driver's channel map with pulseaudio channel map from pulseaudio default.conf


especially when pulseaudio 2.1 profile can be mapped to several alsa 2.1 channel maps including 5.1

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=48f1b308cc66152eb6db66742dd0d08d888cda8d;hp=5c4cd46810cef8850b037fca9e38ffd43b0bff22
Comment 47 Takashi Iwai 2015-09-08 10:38:26 UTC
(In reply to Jose from comment #38)
> (In reply to Takashi Iwai from comment #34)
> > OK, then try to boot with snd_hda_intel.probe_only=1 boot option.
> > This will disable the automatic configuration, so the sound isn't usable at
> > first.  But you'll have the access to /proc/asound/card0/codec#* files, so
> > read them and attach to Bugzilla.  Here the point to check is whether the
> > pin-caps of NID 0x16 is still 0x00.
> 
> Look like yes, but I let you read the attached file.

Thanks, it's indeed 0x00, so the initial state is already bogus.
It's found not only on NID 0x16 but also 0x17.
 
> > And attach this output to Bugzilla, too.  Finally, run alsa-info.sh at this
> > moment to be sure to verify the state.
> > 
> 
> My Mageia distro comes with trace so yes I got hdatrace.txt, see attached
> file.
> I just tested without headphone plugged at boot, I don't know if it is
> needed to do with with some thing plugged?
> 
> http://www.alsa-project.org/db/?f=0752eb3aacf116d34d45d5c5836471415e026df2

That's the requested information.  But it'd be also helpful to have these information with the hp-plugged boot.  Especially to see whether NID 0x16 has a right value when booted with hp plugged, even with probe_only=1.

Another test I'd like to ask it to the manual adjustment of the pin 0x16.
Boot without HP as normal, that is, keep the broken state.  Confirm /proc/asound/card0/codec#1 wheter NID 0x16 Pincap and Pin-ctls are both 0.  Then, run hda-verb like:

  hda-verb /dev/snd/hwC0D1 0x16 SET_PIN_WID 0x40

and check the proc file again whether the pin-ctls is changed or not.

If it doesn't change, it's really a hardware problem, likely a bug of ALC880 chip design.  There can be some workaround, but it's hard to know...
Comment 48 Jose 2015-09-08 19:34:14 UTC
(In reply to Takashi Iwai from comment #47)
> That's the requested information.  But it'd be also helpful to have these
> information with the hp-plugged boot.  Especially to see whether NID 0x16
> has a right value when booted with hp plugged, even with probe_only=1.

I attach the whole dump, but yes NID 0x16 has the good value even with probe_only=1.

> Another test I'd like to ask it to the manual adjustment of the pin 0x16.
> Boot without HP as normal, that is, keep the broken state.  Confirm
> /proc/asound/card0/codec#1 wheter NID 0x16 Pincap and Pin-ctls are both 0. 
> Then, run hda-verb like:
> 
>   hda-verb /dev/snd/hwC0D1 0x16 SET_PIN_WID 0x40
> 
> and check the proc file again whether the pin-ctls is changed or not.
> 
> If it doesn't change, it's really a hardware problem, likely a bug of ALC880
> chip design.  There can be some workaround, but it's hard to know...

Unfortunately, it does not change. Thank you  for spending time, of course I can live with this bug, let's keep it under the carpet ;-)

Will the fix patch #1 and #2 end in the mainline kernel?
Comment 49 Jose 2015-09-08 19:35:34 UTC
Created attachment 187091 [details]
cat /proc/asound/card0/codec#1 with jack headphone plugged
Comment 50 Raymond 2015-09-09 07:19:10 UTC
why the name of codec is "not set" ?


Codec: Not Set
Address: 1
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10ec0880
Subsystem Id: 0x08800000
Revision Id: 0x100800
No Modem Function Group found
Comment 51 Raymond 2015-09-10 16:44:02 UTC
(In reply to Jose from comment #49)
> Created attachment 187091 [details]
> cat /proc/asound/card0/codec#1 with jack headphone plugged

Node 0x21 [Volume Knob Widget] wcaps 0x600080: Mono
  Volume-Knob: delta=0, steps=64, direct=0, val=46
  Unsolicited: tag=00, enabled=0
  Connection: 0

it is strange that unsolicited event was not always enabled
Comment 52 Takashi Iwai 2015-09-10 18:12:30 UTC
Just because it's the result of pre-probe.
Comment 53 Raymond 2015-09-11 01:37:35 UTC
static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
{
	u32 pincap;
	u32 val;

-	if (!codec->no_trigger_sense) {
-		pincap = snd_hda_query_pin_caps(codec, nid);
-		if (pincap & AC_PINCAP_TRIG_REQ) /* need trigger? */
-			snd_hda_codec_read(codec, nid, 0,
-					AC_VERB_SET_PIN_SENSE, 0);
-	}
	val = snd_hda_codec_read(codec, nid, 0,
				  AC_VERB_GET_PIN_SENSE, 0);
	if (codec->inv_jack_detect)
		val ^= AC_PINSENSE_PRESENCE;
	return val;
}

do alc880 really need snd_hda_codec_read(codec, nid, 0,				AC_VERB_SET_PIN_SENSE, 0); ?
Comment 54 Jose 2015-09-11 11:21:11 UTC
(In reply to Raymond from comment #53)
> static u32 read_pin_sense(struct hda_codec *codec, hda_nid_t nid)
> .....
> do alc880 really need snd_hda_codec_read(codec, nid, 0,                       
> AC_VERB_SET_PIN_SENSE, 0); ?

Is this a patch to try?
Comment 55 Raymond 2015-09-11 15:15:03 UTC
is it possible to post the trace when you plug headphone since the driver start impedance measurement which take time to complete ?




Impedance returns the measured impedance of the widget.  A returned value of 0x7FFF,FFFF (all 1‟s) indicates that a valid sense reading is not available, or the sense measurement is busy (refer to Section 7.3.1) if it has been recently triggered.  This field is only valid if the widget has Sense capability as indicated by the “Impedance Sense Capable” bit of the Pin Capabilities parameter.
Comment 56 Raymond 2015-09-11 15:29:42 UTC
http://git.alsa-project.org/?p=alsa-tools.git;a=blob_plain;f=hdajacksensetest/hdajacksensetest.c;hb=HEAD

hdajacksensetest can be modified to show the impedance when you specify setpinsense



	if (set_pin_sense) {
		for (i = 0; i < pin_count; i++)
			if (should_check_pin(&pin_configs[i])) {
				codec_rw(pin_configs[i].nid, AC_VERB_SET_PIN_SENSE, 0);
			}
		sleep(1);
	}

	for (i = 0; i < pin_count; i++)
		if (should_check_pin(&pin_configs[i])) {
			gchar *desc = get_config_description(actual_pin_config(&pin_configs[i]));
			unsigned long present = codec_rw(pin_configs[i].nid, AC_VERB_GET_PIN_SENSE, 0);
-			printf("Pin 0x%.2x (%s): present = %s\n", pin_configs[i].nid, desc, present & 0x80000000 ? "Yes" : "No");
+        printf("Pin 0x%.2x (%s): present = %x\n", pin_configs[i].nid, desc, present );
			g_free(desc);
		}
Comment 57 Jose 2016-12-04 09:25:33 UTC
The subwoofer works with a headset plugged at power-on. While this is not a good fix, it is enough for me.

Note You need to log in before you can comment on or make changes to this bug.