Created attachment 84611 [details] alsa-info.sh script output (dmesg, /proc/asound, alsactl, ...) There are three internal speakers which work correctly when the option model=ref is passed to snd-hda-intel. There are two headphone outputs. I am unable to disable the internal speaker while either headphone is connected. If the snd-hda-intel driver is passed any model from other 92HD* (e.g model=hp) or set to auto, the internal subwoofer does not work, but headphones work as expected (internal speakers mute when headphones are plugged in). There is a mute indicator light that does not work regardless of model used. It should be noted that I am using an HP Envy 17-3200.
erm...poor example. Say model=hp-led instead.
Again, sorry. The laptop has a 4.1 internal speaker system (five speakers).
the ref model is for debugging how many audio jacks and internal speakers do your computer have ? Node 0x0a [Pin Complex] wcaps 0x400583: Stereo Amp-In Control: name="Headphone as Line Out Switch", index=0, device=0 ControlAmp: chs=0, dir=In, idx=0, ofs=0 Control: name="Front Headphone Jack", index=1, device=0 Amp-In caps: N/A Amp-In vals: [0x00 0x00] Pincap 0x0001173c: IN OUT HP EAPD Detect Vref caps: HIZ 50 GRD 80 EAPD 0x2: EAPD Pin Default 0x02214030: [Jack] HP Out at Ext Front Conn = 1/8, Color = Green DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP VREF_HIZ Unsolicited: tag=02, enabled=1 Power states: Power: setting=D0, actual=D0 Connection: 3 0x13 0x14* 0x1c Node 0x0b [Pin Complex] wcaps 0x400581: Stereo Control: name="Front Headphone Jack", index=0, device=0 Pincap 0x0001001c: OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x02211010: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0x0 Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: Power: setting=D0, actual=D0 Connection: 3 0x13 0x14* 0x1c Node 0x0c [Pin Complex] wcaps 0x400583: Stereo Amp-In Control: name="Mic Jack Mode", index=0, device=0 ControlAmp: chs=0, dir=In, idx=0, ofs=0 Control: name="Mic Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: N/A Amp-In vals: [0x00 0x00] Pincap 0x00011734: IN OUT EAPD Detect Vref caps: HIZ 50 GRD 80 EAPD 0x2: EAPD Pin Default 0x02a19020: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=04, enabled=1 Power states: Power: setting=D0, actual=D0 Connection: 3 0x13* 0x14 0x1c Node 0x0d [Pin Complex] wcaps 0x400501: Stereo Control: name="Front Speaker Phantom Jack", index=0, device=0 Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x02170130: [Jack] Speaker at Ext Front Conn = Analog, Color = Unknown DefAssociation = 0x3, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Power states: Power: setting=D0, actual=D0 Connection: 3 0x13* 0x14 0x1c Node 0x0e [Pin Complex] wcaps 0x400583: Stereo Amp-In Control: name="Line Out Jack", index=0, device=0 Amp-In caps: N/A Amp-In vals: [0x00 0x00] Pincap 0x00010034: IN OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x01014050: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x5, Sequence = 0x0 Pin-ctls: 0x40: OUT Unsolicited: tag=03, enabled=1 Power states: Power: setting=D0, actual=D0 Connection: 3 0x13* 0x14 0x1c Node 0x0f [Pin Complex] wcaps 0x400583: Stereo Amp-In Control: name="Line Capture Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Line Jack", index=0, device=0 Amp-In caps: N/A Amp-In vals: [0x00 0x00] Pincap 0x00010034: IN OUT EAPD Detect EAPD 0x2: EAPD Pin Default 0x01819040: [Jack] Line In at Ext Rear Conn = 1/8, Color = Pink DefAssociation = 0x4, Sequence = 0x0 Pin-ctls: 0x20: IN Unsolicited: tag=05, enabled=1 Power states: Power: setting=D0, actual=D0 Connection: 3 0x13* 0x14 0x1c Node 0x10 [Pin Complex] wcaps 0x400500: Mono Control: name="Line Out Phantom Jack", index=0, device=0 Pincap 0x00000010: OUT Pin Default 0x01014020: [Jack] Line Out at Ext Rear Conn = 1/8, Color = Green DefAssociation = 0x2, Sequence = 0x0 Pin-ctls: 0x40: OUT Power states: Power: setting=D0, actual=D0 Connection: 1 0x1a
The same problem here but the main concern is that no Mic working (nor internal, nor connected to external jack) Model HP Envy 3290NR, same audio chip, running 3.7.1 kernel. Tried all possible hp* models and enable_msi parameters. Can supply any additional information upon request.
The mic problem is solved by disabling the onboard intel wireless audio card (connected through snd-sub-audio) - after disabling the capture bar for 92HD* card in alsamixer became active and both mics starts work. Very strange as these must be two separate cards.
The headphones problem is solved by model=hp-zephyr though the mic auto-switch became broken with it. Seems like the new model=hp-3000 need to be created using working parts of existing ones. Forgot to say that mute led do not work in any model variant (hp-led/hp-inv-led/etc.)
Could you try the latest kernel without model option and list up what's still not working? Most of problems look like a BIOS issue -- it didn't set up the pins correctly and didn't give a proper DMI string for the mute LED.
With 3.12, the two front stereo speakers work by default and headphones behave correctly (i.e plugging them in mutes the speakers). Following the instructions at http://www.reddit.com/r/linux/comments/1nu4pc/muxless_graphics_cards_on_linux/ and connecting the woofer to 0x10, the sound system works correctly. The mute LED is still non-operational.
^ That is definitely the wrong link. I seem to have lost the right one. I used `hdajackretask` in `alsa-utils` to assign the correct pin.
OK, could you give the alsa-info.sh output with the latest kernel, too?
Regarding the mute LED: it's detected somehow and using GPIO3. If this really doesn't work, you can try to pass a hint gpio_led=0x01 to override the BIOS setup. In anyway, it'd be clearer if you can give the output of dmidecode.
Below is a test patch just made from a wile guess. Let me know if this works.
Created attachment 114651 [details] Test patch
Ping.
Created attachment 131621 [details] alsa-info alsa-info from a modified ALSA setup.
Created attachment 131631 [details] DMI information dmidecode output
Created attachment 131641 [details] aplay -L aplay -L putput
Did it work or not?
I probably forgot to submit my comment before I added those attachments. Here it is: === I have the same kind of laptop and audio hardware, with the same behaviour. I'm attaching my alsa-info, 'dmidecode' and 'aplay -L' output. Please note that the ALSA configuration has been altered by me (including with hdajackretask). If you need the alsa-info from an unmodified system, I'll provide it. === Regarding the patch, I'm willing to test it but haven't found yet a guide on patching and compiling ALSA.
do you mean subwoofer is 0x10 ? can node 0x1c 's volume control used by the speaker or subwoofer ? Node 0x10 [Pin Complex] wcaps 0x400500: Mono Control: name="Speaker Surround Phantom Jack", index=0, device=0 Pincap 0x00000010: OUT Pin Default 0x40f000f0: [N/A] Other at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x40: OUT Power states: Power: setting=D0, actual=D0 Connection: 1 0x1a Node 0x13 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="92HD91BXX Analog", type="Audio", device=0 Amp-Out caps: N/A Amp-Out vals: [0x67 0x67] Converter: stream=8, channel=0 Power states: Power: setting=D0, actual=D0 Delay: 13 samples Node 0x14 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: N/A Amp-Out vals: [0x67 0x67] Converter: stream=8, channel=2 Power states: Power: setting=D0, actual=D0 Delay: 13 samples Node 0x1b [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=3, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x91 0x91] [0x80 0x80] [0x80 0x80] Power states: Power: setting=D0, actual=D0 Connection: 6 0x13 0x14 0x0a 0x0c 0x0e 0x0f Node 0x1c [Audio Selector] wcaps 0x30050d: Stereo Amp-Out Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x9f 0x9f] Power states: Power: setting=D3, actual=D3 Connection: 1 0x1b
(In reply to Raymond from comment #20) > do you mean subwoofer is 0x10 ? Yes, I used hdajackretask to override that pin. By default 0x10 is "not connected". While this makes it output sound, the subwoofer also plays higher frequencies, which makes the laptop sound unbalanced (much more sound comes from the left side than from the right side). > can node 0x1c 's volume control used by the speaker or subwoofer ? I don't know how to test this. alsamixer's "Master" and "Speaker" indicators both change the volume of front-left, front-right and subwoofer (as if they were combined in a single output). There is no separate volume control for the subwoofer.
when loopback mixing is enabled, audio from 0x13 or 0x14 pass through audio mixer 0x1b to node 0x1c which has an amp out you can use hda-analyzer to change the volume control at node 0x1c
(In reply to Raymond from comment #22) > when loopback mixing is enabled, It is enabled now. >audio from 0x13 or 0x14 pass through audio mixer 0x1b Indeed, using mixer 0x1b I can control each front speaker. It doesnt't affect the subwoofer. > to node 0x1c which has an amp out 0x1c has only 0x1b as Source Node. It also controls the front speakers. >you can use hda-analyzer to change the volume control at node 0x1c I also tried other controls, but nothing seems to be controlling the subwoofer from hda-analyzer. There is no node with a 0x10 source.
If I change node 0x19's Source Node from 0x14 to 0x1c, then the sound become more powerful (especially from 0x10, the subwoofer) and 0x1c starts to control the subwoofer.
if you look at the functional block diagram of 92HD91b datasheet, there is a band pass filter in the mono out path and a 5 band EQ in the port D path
(In reply to Raymond from comment #25) > if you look at the functional block diagram of 92HD91b datasheet, > there is a band pass filter in the mono out path and a 5 band EQ in the port > D path My knowledge of audio hardware is very limited. I'll try to test the patch in #13 and report back. If there is anything else I can do to help solving this bug, just ask.
how many internal speakers ? http://askubuntu.com/questions/303775/envy-15-beats-audio-issues-w-13-04 seem have four speaker and subwoofer in the hardware maintainance manual
Yes, there are 4 speakers and a subwoofer. The subwoofer is composed of two physical woofers. I managed to get sound from the two speakers that sit below the touchpad (called Front Speakers in the documentation) and the subwoofer, but not from the speakers that sit above the keyboard (Stereo Speakers in the docs). This is the service guide for may laptop: http://h10032.www1.hp.com/ctg/Manual/c03317211.pdf
The 92HD91B single-chip audio system is a low power optimized, high fidelity, 4-channel audio codec with integrated speaker amplifier, capless headphone amplifier, and low drop out voltage regulator. The integrated combo jack allows for dual-function headphone and headset detection. The integrated high-pass and band-pass filters allow for Hardware EQ and speaker protection 2 Full Duplex Stereo 24-bit ADCs and 24-bit DACs 2W/channel Class-D stereo speaker amplifier @ 4 ohms and 5V Hardware EQ and Compressor Limiter Dedicated BTL high pass filter and Mono bandpass filter for speaker protection you have to find out the node of the missing rear speakers it is only a 4 channels codec, so you cannot use surround41 http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=1af088e39b75a0a0897c7036487b143e983cd423 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_auto_parser.c?id=9b7564a64999597844513604df4a206fa4da3b69 for multi-channels, the pin default must use the same DefAssoication and ascending sequence number
as the driver seem won't create surround 4.0 setup 1) for a 4 channels codec since badness of missing a headphone volume control is larger than supporting surround 4.0, 2) hda_auto_parser seem use function reorder_outputs to change the order of the speakers you have to use hda-analyzer to find the missing speaker node
the naming of the speaker playback switch at audio output does not allow the driver to share audio output with headphone and speaker when you have 4 speakers , Node 0x13 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="92HD91BXX Analog", type="Audio", device=0 Amp-Out caps: N/A Amp-Out vals: [0x67 0x67] Converter: stream=8, channel=0 Power states: Power: setting=D0, actual=D0 Delay: 13 samples Node 0x14 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: N/A Amp-Out vals: [0x67 0x67] Converter: stream=8, channel=2 Power states: Power: setting=D0, actual=D0 Delay: 13 samples
you may need similar fix in patch_sigmtatel.c if you want volume control for the subwoofer https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_via.c?id=4abdbd1c2c1832e7270e546307ffb3e56b286db2 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/patch_via.c?id=d5266125fb439a5dfa4edd548d888fda47414ac5 (e.g. asus g75v with vt1802 4-channel with 2.1 speaker) the difference between vt1802 are the mute switch at audio output instead of pin complex
to bypass the function reorder_outputs() when number of dac is less than two since you don't want the driver re order 4.1 speakers when only have two dac --- a/sound/pci/hda/hda_auto_parser.c +++ b/sound/pci/hda/hda_auto_parser.c @@ -173,6 +173,7 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, struct auto_out_pin speaker_out[ARRAY_SIZE(cfg->speaker_pins)]; struct auto_out_pin hp_out[ARRAY_SIZE(cfg->hp_pins)]; int i; + int num_dacs = 0; if (!snd_hda_get_int_hint(codec, "parser_flags", &i)) cond_flags = i; @@ -191,6 +192,10 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, unsigned int def_conf; short assoc, loc, conn, dev; + if (wid_type == AC_WID_AUD_OUT) + if (!(wid_caps & AC_WCAP_DIGITAL)) + num_dacs++; + /* read all default configuration for pin complex */ if (wid_type != AC_WID_PIN) continue; + + if (num_dacs >= 3) { + reorder_outputs(cfg->line_outs, cfg->line_out_pins); reorder_outputs(cfg->hp_outs, cfg->hp_pins); reorder_outputs(cfg->speaker_outs, cfg->speaker_pins); + + } +
take a look at datasheet 7.4.31.AFG (NID = 01h): DAC3OutAmp (Mono Out Volume)
(In reply to Raymond from comment #33) > to bypass the function reorder_outputs() when number of dac is less than two > > > since you don't want the driver re order 4.1 speakers when only have two dac > > > --- a/sound/pci/hda/hda_auto_parser.c > +++ b/sound/pci/hda/hda_auto_parser.c > @@ -173,6 +173,7 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, > struct auto_out_pin speaker_out[ARRAY_SIZE(cfg->speaker_pins)]; > struct auto_out_pin hp_out[ARRAY_SIZE(cfg->hp_pins)]; > int i; > + int num_dacs = 0; > > if (!snd_hda_get_int_hint(codec, "parser_flags", &i)) > cond_flags = i; > @@ -191,6 +192,10 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec, > unsigned int def_conf; > short assoc, loc, conn, dev; > > + if (wid_type == AC_WID_AUD_OUT) > + if (!(wid_caps & AC_WCAP_DIGITAL)) > + num_dacs++; > + > /* read all default configuration for pin complex */ > if (wid_type != AC_WID_PIN) > continue; > > > + > + if (num_dacs >= 3) { > + > reorder_outputs(cfg->line_outs, cfg->line_out_pins); > reorder_outputs(cfg->hp_outs, cfg->hp_pins); > reorder_outputs(cfg->speaker_outs, cfg->speaker_pins); > + > + } > + I have applied this patch against Ubuntu's kernel 3.13.0-24-generic. When running the patched kernel, what changes should I look for and report?
it only allow you to test with three speakers pin complexes with two DAC, the driver only create two volume controls at audio output you still need to find out whether the mono out volume can be used or not the datasheet contain info about vendor specific verbs for nodes 0x22 but you have to check whether your codec revision support those feature e.g. the band pass filter is enabled by default , so it is strange that you still get high frequency from the subwoofet
take a look at 7.29 Advanced function you can use hda-verb and those GET command to dump the internal values and check whether it match the default values after rest in the datasheet
you have to find out the pin complex of the rear speakers
(In reply to Raymond from comment #36) ... > the datasheet contain info about vendor specific verbs for nodes 0x22 but > you have to check whether your codec revision support those feature I haven't managed to understand how to use hda-verb, but hda_analyzer gives this dump for node 0x22: Node 0x22 [Vendor Defined Widget] wcaps 0xf00001: Stereo
I'm now testing the upstream kernel 3.15.0-031500rc1-generic and there are no improvements over kernel 3.13 concerning this hardware. Support for the following features is missing: a) mute LED (does not light on when pressing the hardware Mute button) b) subwoofer (node 0x10) needs a quirk to start working, see [1] c) loopback mixing has to be enabled to get better sound d) a separate volume control for the subwoofer would be excellent. === [1] in order to enable the subwoofer, hdajackretask created the following config in /lib/firmware/hda-jack-retask.fw: [codec] 0x111d76e0 0x103c1851 0 [pincfg] 0x0a 0x40f000f0 0x0b 0x0321101f 0x0c 0x03a11020 0x0d 0x92170110 0x0e 0x40f000f0 0x0f 0x40f000f0 0x10 0x90170151 0x11 0xd5a30130 0x1f 0x40f000f0 0x20 0x40f000f0 This makes the subwoofer output sound after a reboot.
(In reply to Raymond from comment #36) ... > the driver only create two volume controls at audio output > you still need to find out whether the mono out volume can be used or not By default, both PCM and Master volume controls in alsamixer always control Left + Right + Subwoofer volume. There is no separate control for the mono out (subwoofer). > the datasheet contain info about vendor specific verbs for nodes 0x22 but > you have to check whether your codec revision support those feature > > e.g. the band pass filter is enabled by default , so it is strange that you > still get high frequency from the subwoofet I stand corrected: the high frequencies are output only through the front speakers. The subwoofer gets mid-range and low frequencies, like human voice and some musical instruments (and bass). The low frequencies are clear, while voice makes the subwoofer produce some loud and unpleasant buzz.
(In reply to Sergiu Bivol from comment #40) ... > c) loopback mixing has to be enabled to get better sound I now understand that loopback mixing is responsible for most off the buzz I was hearing. Enabling it makes the sound louder because it sends all frequencies to all speakers. Without this mixing, the sound is much more clear, with almost no buzz at all. Please disregard c).
hda_analyzer has produced the following config diff for a setup that works well (Front Left, Front Right and the Subwoofer play loud and clear): Diff for codec 0/0 (0x111d76e0): --- +++ @@ -91,17 +91,17 @@ Pin Default 0x40f000f0: [N/A] Other at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Unsolicited: tag=0x00, enabled=0 Power: setting=D3, actual=D3 Connection: 3 0x13* 0x14 0x1c Node 0x10 [Pin Complex] wcaps 0x400500: Mono - Control: name="Speaker Surround Phantom Jack", index=0, device=0 + Control: iface="card", name="Speaker Surround Phantom Jack", index=0, device=0 Pincap 0x00000010: OUT Pin Default 0x40f000f0: [N/A] Other at Ext N/A Conn = Unknown, Color = Unknown DefAssociation = 0xf, Sequence = 0x0 Pin-ctls: 0x40: OUT Power: setting=D0, actual=D0 Connection: 1 0x1a @@ -188,17 +188,17 @@ Connection: 1 0x19 Node 0x1b [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=1, idx=3, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=1, idx=3, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 - Amp-In vals: [0x17 0x17] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] + Amp-In vals: [0x17 0x17] [0x1f 0x1f] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Power: setting=D0, actual=D0 Connection: 6 0x13 0x14 0x0a 0x0c 0x0e 0x0f Node 0x1c [Audio Selector] wcaps 0x30050d: Stereo Amp-Out Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x1f 0x1f] Power: setting=D0, actual=D0 Connection:
did you add the customized badness table since the default badness table won't create bass speaker playback volume control when there is two dac +spec->gen.main_out_badness = &via_main_out_badness; + spec->gen.extra_out_badness = &via_extra_out_badness; just copy those via badness tables and rename to idt_xxxx_badness the point is whether pulseaudio mute the front playback volume when headphone is plugged since there is no headphone playback volume does it really work since the subwoofer has Def assosication 5 different from the speaker Def assosication 1 the auto parser ignore these kind of pins https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_auto_parser.c?id=9b7564a64999597844513604df4a206fa4da3b69 codec] 0x111d76e0 0x103c1851 0 [pincfg] 0x0a 0x40f000f0 0x0b 0x0321101f 0x0c 0x03a11020 0x0d 0x92170110 0x0e 0x40f000f0 0x0f 0x40f000f0 0x10 0x90170151 0x11 0xd5a30130 0x1f 0x40f000f0 0x20 0x40f000f0
those Fxx verb are GET commands and 7xx verb are SET commands try get command to dump the values of 7.29.1.21.Mono Band-Pass Filter COEF_SEL Register do the values match with the default values 0x32 (120Hz, 250Hz)
in theory , you only need signal from one of the two dac 0x13 or 0x14 when playing stereo do you want signal from front and rear when playing four channels ? 0x17 is 0dB and 0x1f is +12dB Amp-In vals: [0x17 0x17] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] + Amp-In vals: [0x17 0x17] [0x1f 0x1f] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Power: setting=D0, actual=D0 Connection: 6 0x13 0x14 0x0a 0x0c 0x0e 0x0f
Node 0x0d [Pin Complex] wcaps 0x400501: Stereo Control: name="Front Speaker Phantom Jack", index=0, device=0 Pincap 0x00010050: OUT EAPD Balanced EAPD 0x2: EAPD Pin Default 0x02170130: [Jack] Speaker at Ext Front HDA specification 7.4 Packages and External Circuits 7.4.1 Standard Audio 48-Pin Codec Packages 8. The pin function “BTL” indicates balanced output drivers presumably driving hard wired speakers. This implies two output pins for each channel or four output pins for a typical stereo Pin Widget. While the additional outputs and associated amplifiers may be reconfigured from another port or Pin Widget, they must logically appear as a single Pin Widget; i.e., if a stereo Pin Widget was switched to BTL output, it must remain stereo and switch to four output pins rather than two. Similar to the example in rule #7, a headphone jack may be shared with external speakers; in this case, instead of switching an external (EAPD) signal, the Pin Widget would be switched from standard jack (two pin) output to BTL (four pin) output. If a Pin Widget supported BTL exclusively (no sharing), then the “BTL Capable” bit in the Pin Capabilities parameter would be set, and the “Output Capable” bit would be cleared. If the Pin Widget supported headphone jack sharing, then both “BTL Capable” and “Output Capable” bits would be set, and the output mode of the Pin Widget would be controlled by the function driver, after consulting the “Presence Detect” bit.
(In reply to Raymond from comment #44) ... > the point is whether pulseaudio mute the front playback volume when > headphone is plugged since there is no headphone playback volume When using the vanilla 3.15-rc1 kernel or Ubuntu's 3.13.0-23-generic, headphones work correctly: speakers become muted and sound goes through headphones. Removing all headphones restores sound through speakers (including the subwoofer that was activated with hdajackretask). I tested with one and two pairs of headphones connected to the laptop and there were no issues whatsoever. I'm now compiling a patched 3.15-rc1 kernel (modified according to your suggestions) and will repeat these tests. Thank you very much for your patience and support.
(In reply to Takashi Iwai from comment #12) > Below is a test patch just made from a wile guess. Let me know if this > works. I applied the changes from your patch to sound/pci/hda/patch_sigmatel.c together with the changes suggested by Raymond for badness tables, producing the diff below [1]. The mute led is still not working. I understand that there is a way to make manual tests and try various values using hda-verb, as in this bug: https://bugzilla.kernel.org/show_bug.cgi?id=70991 The hda-verb commands in that bug report do not work on my system because a parameter is missing: $ hda-verb /dev/snd/hwC0D0 SET_GPIO_MASK 0x01 usage: hda-verb [option] hwdep-device nid verb param How should I invoke hda-verb on my system to find the GPIO led? [1] diff -pu: --- patch_sigmatel.c 2014-04-17 16:53:57.827084960 +0300 +++ patch_sigmatel.c.modifiat 2014-04-17 12:31:05.000000000 +0300 @@ -102,6 +102,7 @@ enum { STAC_92HD83XXX_HEADSET_JACK, STAC_92HD83XXX_HP, STAC_HP_ENVY_BASS, + STAC_HP_ENVY17, STAC_HP_BNB13_EQ, STAC_92HD83XXX_MODELS }; @@ -2582,6 +2583,16 @@ static const struct hda_verb hp_bnb13_eq {} }; +static void stac_fixup_hp_envy17(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + struct sigmatel_spec *spec = codec->spec; + if (action == HDA_FIXUP_ACT_PRE_PROBE) { + spec->gpio_led = 0x01; + snd_hda_codec_set_pincfg(codec, 0x10, 0x02170131); + } +} + static const struct hda_fixup stac92hd83xxx_fixups[] = { [STAC_92HD83XXX_REF] = { .type = HDA_FIXUP_PINS, @@ -2656,6 +2667,10 @@ static const struct hda_fixup stac92hd83 {} }, }, + [STAC_HP_ENVY17] = { + .type = HDA_FIXUP_FUNC, + .v.func = stac_fixup_hp_envy17, + }, [STAC_HP_BNB13_EQ] = { .type = HDA_FIXUP_VERBS, .v.verbs = hp_bnb13_eq_verbs, @@ -2721,6 +2736,8 @@ static const struct snd_pci_quirk stac92 "HP", STAC_92HD83XXX_HP_cNB11_INTQUAD), SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x165B, "HP", STAC_92HD83XXX_HP_cNB11_INTQUAD), + SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1853, + "HP Envy17", STAC_HP_ENVY17), SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1888, "HP Envy Spectre", STAC_HP_ENVY_BASS), SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1899, @@ -4128,12 +4145,33 @@ static const struct snd_pci_quirk stac92 {} /* terminator */ }; +static const struct badness_table idt_main_out_badness = { + .no_primary_dac = 0x10000, + .no_dac = 0x4000, + .shared_primary = 0x10000, + .shared_surr = 0x20, + .shared_clfe = 0x20, + .shared_surr_main = 0x20, +}; + +static const struct badness_table idt_extra_out_badness = { + .no_primary_dac = 0x4000, + .no_dac = 0x4000, + .shared_primary = 0x12, + .shared_surr = 0x20, + .shared_clfe = 0x20, + .shared_surr_main = 0x10, +}; + static int stac_parse_auto_config(struct hda_codec *codec) { struct sigmatel_spec *spec = codec->spec; int err; int flags = 0; + spec->gen.main_out_badness = &idt_main_out_badness; + spec->gen.extra_out_badness = &idt_extra_out_badness; + if (spec->headset_jack) flags |= HDA_PINCFG_HEADSET_MIC;
(In reply to Raymond from comment #44) ... > just copy those via badness tables and rename to idt_xxxx_badness I did that (the full patch is in the previous comment). > the point is whether pulseaudio mute the front playback volume when > headphone is plugged since there is no headphone playback volume Even without the headphone playback volume mixer, Pulseaudio correctly mutes/unmutes speakers and headphones. Even more, now the Front mixer (in alsamixer) controls both speaker and headphone volume (when I plug the headphones, they inherit the speakers' volume). All I lost is the ability to have different output levels remembered for headphones and speakers, but that is not an issue for me since this new behaviour is also predictable and consistent. > does it really work since the subwoofer has Def assosication 5 different > from the speaker Def assosication 1 > the auto parser ignore these kind of pins It works very well. Subwoofer's volume is muted (along with Front) when I plug the headphones and is restored to the correct level when I unplug the headphones. One thing to mention: when I plug the headphones, alsamixer doesn't reflect the fact that the subwoofer (Bass Speaker mixer) is muted. It is shown as being unmuted at all times.
Could you update the information with the latest kernel, what is missing and what still needs to be patched? I'm willing to take static quirk if appropriate.