Bug 189331

Summary: HP Spectre x360 (Kabylake) just front speakers work
Product: Drivers Reporter: Oleg Mikheev (omikheev)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: NEW ---    
Severity: high CC: alejandro, antoine.bernez, aroragagan24, bermanmaxim, bugzilla, cipkuehl, contact, dario.asm, dislabled, djvw1983, dridri85, e.vakhromtsev, elias.gabrielsson, emraydin, fattony4, francesco.cuius.98, frans.skarman, fredericok, giuseppe06, grabowski.frederic, grib, hhben10, holger, ian.hincks, ifoolb, j, jason, juan.puchalski, kailang, kingsid911, lalochcz, LANGLOIS.JF, let4be, levmckinney, m.aragnet, mateusz.tomasz.doroszko, matthijsm+kernel, mayank8019, me, mpc7400, msestovic, nrobert13, osip.fatkullin, philip.leis, pointedstick, redlane, reg.krn, reg.pkm, Ryan.Laird, sagarsaini, sareen_eng, sharkcow, tacchinotech, tbriden, thezealousfool, tiwai, ushmax, uzivatelmp, vortex, zxc011991
Priority: P1    
Hardware: Intel   
OS: Linux   
Kernel Version: 4.9.0-rc7 Tree: Mainline
Regression: No
Attachments: alsa-info.txt
alsa-info 2.9.0-rc7
alsa-info working speakers
alsa-info inc coef
patch to fix mute led
image of pin configuration (broken headphone jack)
Working speakers alsa info
Speakers working Alsa-Info
Alsa info when only one speaker works
attempt to fix coeffs
qemu xml for sound card pci passthrough
attachment-1613-0.html
Fix speakers by applying ALL verbs applied by Windows
attachment-5374-0.html
cat /proc/asound/card0/codec#0 - working
cat /proc/asound/card0/codec#0 - not working
attachment-12893-0.html
attachment-27196-0.html
Replacement of hp_x360_helper.c
attachment-19470-0.html
lspci -nnv on ae-012nc (mute LED and top speakers not working, different PCI id)
alsa-info on ae-012nc (mute LED and top speakers not working, different PCI id)
alsa-info hp_envy_ad102nl
alsa-info on ae012nc after W10 VM
Pinconfig extracted in Windows
Dumps from Spectre x360 13" ae012nc

Description Oleg Mikheev 2016-11-29 07:35:22 UTC
Created attachment 246191 [details]
alsa-info.txt

I know this looks as a mute or a mixer issue, but I wouldn't file a bug if I didn't try everything.
This is a newer HP Spectre x360 based on Kabylake, it just came out.
Headphones work fine.
Speakers don't - just the bottom right one works. In Windows all four work fine.
Tried different models and probe modes. Disabled HDMI device in kernel to isolate issue.
There was a patch at some point saying ALC295 is the same as ALC225 https://patchwork.kernel.org/patch/9142225/, I'm not sure if the one in x360 is.
Comment 1 Oleg Mikheev 2016-11-29 07:38:18 UTC
Created attachment 246201 [details]
alsa-info 2.9.0-rc7
Comment 2 Takashi Iwai 2016-11-29 07:57:25 UTC
There are likely some other speaker pins that aren't enabled by BIOS.
You need to figure out by yourself via trial-and-error, e.g. using hdajackretask or hda-analyzer, as this is basically a BIOS bug.

And/or, the device requires some vendor-specific ways to enable some amps, e.g. GPIO pins, changing VREF of some unused pins, or other vendor-specific COEF parameter.  Again, you have to figure out by yourself, as all these are non-standard configurations.

On Windows, many vendors ship with an extra *.INI file to override the things like above.  You may find it and check anything useful if you have a luck.
Comment 3 Oleg Mikheev 2016-11-29 13:48:10 UTC
If I find it out is it going to be a code fix in the form of a new model or something?
Comment 4 Oleg Mikheev 2016-11-29 14:24:20 UTC
I also tried latest Ubuntu LiveCD, there's no sound and no devices except for Dummy. So I guess it's a real problem.
Comment 5 Takashi Iwai 2016-11-29 14:25:09 UTC
If you find out the pin configuration that matches with the actual speakers and/or vendor-specific verbs or COEFs, then yes, we can implement the fixup code into the driver.

In most cases you can apply the workaround without recompiling the driver by the "patch" module option.  Some descriptions are found in Documentation/sound/alsa/HD-audio.txt.
Comment 6 Oleg Mikheev 2016-11-30 08:57:15 UTC
I tried different PIN combinations and that didn't make any difference.
Is there any tool for Windows like hda-analyzer to see how they configure it?
Also, it's Bang & Olufsen sound, with four speakers, and it seems that it might be not as simple as just PINs.
There's firmware folder that has bunch of stuff, could it be that it won't work properly without one of these loaded?
I couldn't figure out which one is loaded in Windows...

Directory of C:\SWSETUP\DRV\Audio\REALTEK\SH1.xReal_PPBWB2\6.0.1.7922\src\IntelHDASST\HDAudioOEDrv\Firmware

10/09/2016  12:45 AM    <DIR>          .
10/09/2016  12:45 AM    <DIR>          ..
09/08/2016  07:19 AM           238,920 dsp_fw_release.bin
09/08/2016  07:19 AM            12,288 dsp_fw_release_7CAD0808-AB10-CD23-EF45-12AB34CD56EF.bin
09/08/2016  07:19 AM             8,364 dsp_lib_cpath_release.bin
09/08/2016  07:19 AM            24,576 dsp_lib_cpath_release_46CB87FB-D2C9-4970-96D2-6D7E614BB605.bin
09/08/2016  07:19 AM             8,340 dsp_lib_dolby_release.bin
09/08/2016  07:19 AM           155,648 dsp_lib_dolby_release_E0E018A8-3550-4B54-A8D0-A8E05D0FCBA2.bin
09/08/2016  07:19 AM            12,436 dsp_lib_dts_release.bin
09/08/2016  07:19 AM           155,648 dsp_lib_dts_release_E1284052-8664-4FE4-A353-3878F72704C3.bin
09/08/2016  07:19 AM             8,388 dsp_lib_fortemedia_release.bin
09/08/2016  07:19 AM           200,704 dsp_lib_fortemedia_release_B3573EFF-6441-4A75-91F7-4281EEC4597D.bin
09/08/2016  07:19 AM             8,364 dsp_lib_intel_sst_release.bin
09/08/2016  07:19 AM            45,056 dsp_lib_intel_sst_release_7C708106-3AFF-40FE-88BE-8C999B3F7445.bin
09/08/2016  07:19 AM             4,180 dsp_lib_intel_wov_release.bin
09/08/2016  07:19 AM            40,960 dsp_lib_intel_wov_release_EC774FA9-28D3-424A-90E4-69F984F1EEB7.bin
09/08/2016  07:19 AM            12,460 dsp_lib_smartamp_release.bin
09/08/2016  07:19 AM            73,728 dsp_lib_smartamp_release_2C093145-5895-4699-9DDB-6FEFDC77E85D.bin
09/08/2016  07:19 AM             4,204 dsp_lib_sraudio_release.bin
09/08/2016  07:19 AM            16,384 dsp_lib_sraudio_release_D46F9D72-81A4-47FD-B301-8E39D17C0981.bin
09/08/2016  07:19 AM             8,344 dsp_lib_waves_release.bin
09/08/2016  07:19 AM           114,688 dsp_lib_waves_release_B489C2DE-0F96-42E1-8A2D-C25B5091EE49.bin
09/08/2016  07:19 AM            16,532 dsp_lib_xa_audyssey_release.bin
09/08/2016  07:19 AM            94,208 dsp_lib_xa_audyssey_release_BD70CE66-7CEE-4277-A91A-D6368FEAF83D.bin
09/08/2016  07:19 AM             4,228 libconexant.bin
09/08/2016  07:19 AM           151,552 libconexant_F3578986-4400-4ADF-AE7E-CD433CD3F26E.bin
09/08/2016  07:19 AM             4,220 libicesoundmfx.bin
09/08/2016  07:19 AM            24,576 libicesoundmfx_88373A01-16A5-469D-A39A-BDEB594178B8.bin
09/08/2016  07:19 AM             4,228 libmvm1.bin
09/08/2016  07:19 AM           159,744 libmvm1_347297C3-A6D5-40DB-8120-ACE66BABF491.bin
09/08/2016  07:19 AM             4,228 rtkns_lib.bin
09/08/2016  07:19 AM           110,592 rtkns_lib_271F72A1-BC28-44C7-AA94-2B2C17C32561.bin
09/08/2016  07:19 AM             4,228 rtksep_lib.bin
09/08/2016  07:19 AM            53,248 rtksep_lib_7111001F-D35F-44D9-81D2-7AC685BED3D7.bin
              32 File(s)      1,785,264 bytes
Comment 7 Takashi Iwai 2016-11-30 09:43:21 UTC
The firmwares seem to be for various others.  The previous Spectre x360 model was with a Conexant codec, and maybe that's why the conexant chip is found there.

The four speaker output itself should work without DSP.  It's hard to know, but not only the pin default configuration value but also the actual pin control value (e.g. VREF level or HP amp bit) may influence on such behavior.

About Windows: I have no idea, sorry.
Comment 8 Oleg Mikheev 2016-12-01 08:05:27 UTC
After some experiments hda_analyzer fails to load with this message:
Invalid AFG subtree for codec Realtek ALC295?

I think I got closer to solving it, but this thing can't load any more so I can't go on :(

I still got sound in Windows, which is a good thing I guess.
Comment 9 Nate Graham 2017-01-11 01:20:26 UTC
I've got this machine and experience nearly same problem (both bottom speakers work, not just one, but the top speakers are silent). I too tried remapping the pins in hdajackretask with every possible combination, to no avail. However I can run hda_analyzer, though I have no idea what I'm doing. If someone can provide a bit of guidance, I can follow instructions reeeel gud. :)
Comment 10 Maxim Berman 2017-01-11 15:46:12 UTC
I have the same issue, I'm happy to help but I am missing some vocabulary and understanding (GPIO pins, parser hints, advanced mode...)

I can signal also that the mute LED does not work, so I guess this should correspond to some pin also. ?
Comment 11 Maxim Berman 2017-01-11 17:03:56 UTC
I found out the INF file used by the windows Realtek driver, if it helps: HDXSSTHPNB.inf. Should I dump this file somewhere and add a link here? It is in the WIN64 folder of the x64 drivers downloadable on HP site (version 6.0.1.8023).
Comment 12 Maxim Berman 2017-01-11 17:37:16 UTC
I had a look at https://www.reaper-x.com/2012/02/13/how-to-remap-retasking-realtek-onboard-jacks-ports/

If I go to the registry settings for this Realtek(SST) driver, in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e96c-e325-11ce-bfc1-08002be10318}\0000\Settings\Drv8023_DevType_0295_SS103c827e

I see some "Pin" settings in different registry values... I have put a pastebin of that registry key here http://pastebin.com/2e2SeESs
Comment 13 Oleg Mikheev 2017-01-13 03:08:45 UTC
I actually can run hda-analyzer, it was kernel config that I changed that blocked it.
And I can see that mute LED turns on when I change VREF of Node[0x1b] PIN from HIZ to any other value. Sound doesn't mute, it's only LED.
Do both of you have two bottom speakers working? I would be really happy if both worked on mine, it's really painful to have one speaker on the system.
Also, I get the "crackling" sound in headphones, almost exactly as described in https://h30434.www3.hp.com/t5/Notebook-Audio/Crackling-sound-while-playing-music-in-HP-SPECTRE-X360/td-p/5039064
People claim it's a hardware issue and exchange motherboards, but in my case booting into Windows results in excellent sound in headphones and speakers.
Comment 14 Nate Graham 2017-01-13 03:46:34 UTC
I can confirm that both bottom speakers work on mine and headphones are not crackly. Headphones sound great, actually.
Comment 15 Oleg Mikheev 2017-01-13 04:00:01 UTC
Also, does Windows HDA tool work for any of you? https://msdn.microsoft.com/en-us/library/windows/hardware/dn613936(v=vs.85).aspx
It fails on me. If it worked I guess we could get the real HDA settings from the windows.

What does work is the PinConfigOverride script http://www.osx86.net/files/file/4197-pinconfigoverride-hda-verbs/
It produces four files with some verbs that I have no idea what to do with, for example:

HDA Verb Converter

<01271C30 01271D01 01271EA6 01271FB7 01371C00 01371D00 01371E00 01371F40 01471C10 01471D01 01471E17 01471F90 01671CF0 01671D11 01671E11 01671F41 01771CF0 01771D11 01771E11 01771F41 01871CF0 01871D11 01871E11 01871F41 01971C40 01971D10 01971EA1 01971F03 01A71CF0 01A71D11 01A71E11 01A71F41 01B71CF0 01B71D11 01B71E11 01B71F41 01D71C01 01D71D00 01D71E60 01D71F40 01E71CF0 01E71D11 01E71E11 01E71F41 02171C20 02171D10 02171E21 02171F03>


Does it make sense to any one? I guess I need to feed it into hda-verb in some form...
Comment 16 Oleg Mikheev 2017-01-13 04:06:50 UTC
@Nate does yours say 13-w023dx on the bottom label?

and what's the output of lshw? mine is

    description: Computer
    product: HP Spectre x360 Convertible 13-w0XX (xxx)
    vendor: HP
    version: Chassis Version
    serial: xxx
    width: 64 bits
    capabilities: smbios-2.8 dmi-2.8 vsyscall32
    configuration: boot=normal family=103C_5335KV G=N L=CON B=HP S=SPT sku=xxx uuid=xxx
  *-core
       description: Motherboard
       product: 827E
       vendor: HP
       physical id: 0
       version: 94.46
       serial: xxx
       slot: Base Board Chassis Location
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: F.11
          date: 11/18/2016
          size: 64KiB
          capacity: 6080KiB
Comment 17 Nate Graham 2017-01-13 04:11:49 UTC
No, I have a 13-w013dx. Looks like yours is a bit newer under the hood. Here's lshw for mine:

    description: Convertible
    product: HP Spectre x360 Convertible 13-w0XX (xxx)
    vendor: HP
    version: Chassis Version
    serial: xxx
    width: 64 bits
    capabilities: smbios-2.8 dmi-2.8 smp vsyscall32
    configuration: boot=normal chassis=convertible family=103C_5335KV G=N L=CON B=HP S=SPT sku=xxx uuid=xxx
  *-core
       description: Motherboard
       product: 827E
       vendor: HP
       physical id: 0
       version: 94.27
       serial: xxx
       slot: Base Board Chassis Location
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: F.04
          date: 09/26/2016
          size: 64KiB
          capacity: 6080KiB


I haven't gotten around to figuring out how to upgrade the BIOS in Fedora, since I wiped the Windows partition.
Comment 18 Maxim Berman 2017-01-14 00:09:37 UTC
My bottom speakers both work too, no crackling from the headphones... Model 13-w000nf. The output of lshw is the same as Nate Graham. I will try out Windows HDA tool in a moment.
Comment 19 Nate Graham 2017-01-31 20:26:09 UTC
Any news, Maxim?
Comment 20 Pavel Mihov 2017-02-03 17:02:24 UTC
I have a 13-w013dx here as well. Sound coming in only from the two bottom speakers. 

lshw output:

description: Convertible
    product: HP Spectre x360 Convertible 13-w0XX (X7V19UA#ABA)
    vendor: HP
    version: Chassis Version
    serial: 5CD6390XVQ
    width: 4294967295 bits
    capabilities: smbios-2.8 dmi-2.8 smp vsyscall32
    configuration: boot=normal chassis=convertible family=103C_5335KV G=N L=CON B=HP S=SPT sku=X7V19UA#ABA uuid=35434436-3339-3058-5651-515839334435
  *-core
       description: Motherboard
       product: 827E
       vendor: HP
       physical id: 0
       version: 94.26
       serial: PGEBV028J4426R
       slot: Base Board Chassis Location
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: F.03
          date: 09/03/2016
          size: 64KiB
          capacity: 6080KiB
          capabilities: pci upgrade shadowing cdboot bootselect edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb smartbattery biosbootspecification netboot uefi


I'm very new to Linux, so I can't do any real troubleshooting myself, but I'll be happy to test and provide inputs if needed.
Comment 21 Josh Klar 2017-02-06 18:14:06 UTC
I have the i7/16GB/512GB version of the Spectre x360. Bottom two speakers work (though of course sound like trash because they're low-power tweeters), top two (keyboard grille speakers) do not. Headphone jack is extremely crackly, mostly on the left ear.

Arch Linux, 4.9.6 kernel.

silverboots                 
    description: Convertible
    product: HP Spectre x360 Convertible 13-w0XX (X7V20UA#ABA)
    vendor: HP
    version: Chassis Version
    serial: 5CD6452B2S
    width: 4294967295 bits
    capabilities: smbios-2.8 dmi-2.8 smp vsyscall32
    configuration: boot=normal chassis=convertible family=103C_5335KV G=N L=CON B=HP S=SPT sku=X7V20UA#ABA uuid=35434436-3435-3242-3253-534235344435
  *-core
       description: Motherboard
       product: 827E
       vendor: HP
       physical id: 0
       version: 94.46
       serial: PGEBU048J510K6
       slot: Base Board Chassis Location
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: F.11
          date: 11/18/2016
          size: 64KiB
          capacity: 6080KiB
          capabilities: pci upgrade shadowing cdboot bootselect edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb smartbattery biosbootspecification netboot uefi
Comment 22 Oleg Mikheev 2017-02-14 01:16:15 UTC
That's funny but it actually appeared that my left front (bottom) speaker was broken, sent laptop back to HP. So it's just rear speakers not working in Linux.
Comment 23 Bill Gribble 2017-03-08 16:28:17 UTC
Me too: bottom speakers work fine, nothing from top speakers

Unique to me, it seems: nothing from headphone jack at all, though alsamixer shows that the jack insertion is detected ("Speaker" channel gets muted, "Headphone" channel is unmuted and 100% level when I insert the jack, the reverse when I pull it out). 

My x360 is a i7/16G/1TB version, marked 13t-w000 on the back.  Newer BIOS than the others in this thread (F.20) but otherwise the same. 

Kernel is Debian's 4.9.13 as of this writing.

ghost
    description: Convertible
    product: HP Spectre x360 Convertible 13-w0XX (W9A93AV)
    vendor: HP
    version: Chassis Version
    serial: XXXXXXXXXX
    width: 64 bits
    capabilities: smbios-2.8 dmi-2.8 smp vsyscall32
    configuration: boot=normal chassis=convertible family=103C_5335KV HP Spectre sku=W9A93AV uuid=35434437-3036-3244-544A-4A4436304435
  *-core
       description: Motherboard
       product: 827E
       vendor: HP
       physical id: 0
       version: 94.54
       serial: XXXXXXXXXX
       slot: Base Board Chassis Location
     *-firmware
          description: BIOS
          vendor: American Megatrends Inc.
          physical id: 0
          version: F.20
          date: 12/01/2016
          size: 64KiB
          capacity: 6080KiB
          capabilities: pci upgrade shadowing cdboot bootselect edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb smartbattery biosbootspecification netboot uefi
Comment 24 Tom Briden 2017-03-12 17:32:46 UTC
I've managed to get the top speakers working on the x360 ac004na, which is also ALC295, using HDA Analyzer by unmuting and selecting OUT on Node[0x17].
Comment 25 Maxim Berman 2017-03-12 17:52:39 UTC
Tom Briden: wow, amazing find. I can confirm that this works on my setup too.
Comment 26 Nate Graham 2017-03-12 19:30:33 UTC
Hmm, not working for me, but maybe I'm holding it wrong. How to you permanently apply the settings? They seem to be lost after a reboot, and I don't see any immediate changes after just unmuting and selecting OUT for Node[0x17]. Tried Node[0x16], too.
Comment 27 Bill Gribble 2017-03-12 20:56:25 UTC
Unfortunately doesn't work for me either.  I can turn off the bottom speakers by unselecting OUT or muting on 0x14, so I know hdamonitor is doing something, but I can't get either the headphones or the top speakers to work with any settings I have stumbled across.
Comment 28 Nate Graham 2017-03-12 21:22:59 UTC
Same, Bill. So yeah, hdamonitor is working fine, but pin 0x17 isn't it for me either. Though headphones natively work fine for me.
Comment 29 Tom Briden 2017-03-13 17:48:50 UTC
So I've just gone to try this again today and it doesn't work anymore! I'm 100% sure it worked yesterday as I could mute the speaker pairs independently and control the volumes separately or together from alsamixer depending on which audio source i selected for 0x17. Before I had it working yesterday, I'd been trying lots of things through hdajackretask so maybe it was a combination of things that led to it? Will try and recreate my steps and see if I can get it going again...
Comment 30 Maxim Berman 2017-03-13 22:54:36 UTC
Mh, now I'm wondering if my quick confirmation yesterday was due to more than a placebo. I'll have some time to investigate next week, sorry!
Comment 31 Tom Briden 2017-03-15 19:48:36 UTC
Unfortunately, I'm still unable to get this working again so apologies for getting everyone's hopes up! I've been looking into the hda verb stuff to see if the values in Windows can get us anywhere. I've pulled the PinConfigOverride data from my Windows partition and it matches exactly with what Oleg posted. It translates into hda-verb commands by splitting up like this

01271C30 -> 0x12 (nid) 0x71C (verb) 0x30 (param)

So i ran a script to set the whole lot but it doesn't seem to have any effect:

hda-verb /dev/snd/hwD0C0 0x12 0x71C 0x30                                                                                                                                                                                         
nid = 0x12, verb = 0x71c, param = 0x30                                                                                                                                                                                           
value = 0x0                                                                                                                                                                                                                      
hda-verb /dev/snd/hwD0C0 0x12 0x71D 0x01                                                                                                                                                                                         
nid = 0x12, verb = 0x71d, param = 0x1                                                                                                                                                                                            
value = 0x0                                                                                                                                                                                                                      
hda-verb /dev/snd/hwD0C0 0x12 0x71E 0xA6                                                                                                                                                                                         
nid = 0x12, verb = 0x71e, param = 0xa6                                                                                                                                                                                           
value = 0x0                                                                                                                                                                                                                      
hda-verb /dev/snd/hwD0C0 0x12 0x71F 0xB7                                                                                                                                                                                         
nid = 0x12, verb = 0x71f, param = 0xb7                                                                                                                                                                                           
value = 0x0
...etc

even after running this for all the NIDs there's no update to 
/sys/class/sound/hwC0D0/user_pin_configs like when changing values in hdajackretest so there may still be a step I'm missing..
Comment 32 Ian 2017-03-16 13:04:54 UTC
I am having the same problems as everyone else: bottom speakers work, top speakers don't. Headphone jack turns off speakers, but no sound from headphones.
Model 13-w030ca of the Spectre x360.

In case you don't know what hda verbs are etc, I thought I would point out this helpful blog article aimed at audio noobs like me: http://www.asyndetic.com/2013/04/11/on-debugging-intel-high-definition-audio-in-linux-part-i/
Comment 33 Tom Briden 2017-03-17 09:33:10 UTC
Bit more info, the pincfg's defined in /sys/class/sound/hwC0D0/init_pin_configs are based on the verb params in reverse order. so splitting out the 0x12 node from my last comment gives

012 71C 30
012 71D 01
012 71E A6
012 71F B7

which equates to:

0x12 0xb7a60130

I've done this for all the nids from the windows PinConfigOverrides and they're all identical to init_pin_configs :\

Not sure where to go from here, maybe the realtek driver is changing them on the fly or something? I'm trying to find a hda-verb equivalent for windows to query the nid states but can't find anything
Comment 34 Ian 2017-03-17 20:44:08 UTC
Tom, I can confirm the same results. I get the same output from windows registry as Oleg, and my /sys/class/sound/hwC0D0/init_pin_configs also match them word for word.

I downloaded the windows realtek driver,

http://support.hp.com/ca-en/drivers/selfservice/hp-spectre-13-w000-x360-convertible-pc/12499178/model/13475180#Z7_3054ICK0K8UDA0AQC11TA930O2

and extracted the exe with 7z. There are a lot of files in there, but I have not found anything promising yet.
Comment 35 Tom Briden 2017-03-21 19:24:11 UTC
I've done similar with the ac004na driver, and I think the relevant inf file is 

WIN64/HDXHPNB.INF

given it contains the right subsystem id 103C:827E

"Realtek High Definition Audio" = IntcAzAudModelSRS_FB_HP2014_cNB,   HDAUDIO\FUNC_01&VEN_10EC&DEV_0295&SUBSYS_103C827E


It might be a red herring, but this line from that file could suggest the top speakers are linked to S/PDIF OUT:

HKR,GlobalSettings,SpdifOutputEchosRearRenderWhenNoAc3,1,01,00,00,00 ; Slaves rear panel front channels to SPDIF



I've also been looking through the ALC269 datasheet, which I think 295 may be based on (according to kernel commit log, ALC295 is compatible with ALC225 which is a variant of ALC269)

http://www.hardwaresecrets.com/datasheets/alc269.pdf 

and that indicates the SPDIF out pin is 0x06, which defaults to power state D3 (off) and can be the active node for pin 0x17, also powered off. However I've powered the both to state D0 with hda-verb but still nothing
Comment 36 Tom Briden 2017-03-21 20:24:06 UTC
I got the Microsoft HDAU tool working, but it's no help :|

Basically, you have to set the audio controller to the Microsoft driver, and then the sound drivers to the Microsoft HD Audio driver before it allows you to load the system codec. Having done that, the sound no longer comes out of the top speakers and the hdau tool itself gives all the same info we can already get out of hda-analyzer. Switching back to realtek drivers and the speakers work again

Maybe this confirms at least that we need to do something with a vendor widget?
Comment 37 Ian 2017-03-22 01:31:16 UTC
Looking at the block diagram of the datasheet, I agree that SPI-OUT1-PCM is the likeliest channel for the top speakers because of process of elimination:
 - SP-OUT2 is usually used for HDMI
 - HPOUT Port A (0x15) is designed for headphones
 - SPK-Out Port D (0x14) uses a power saving amp, better for tablet mode, hence the bottom speakers. It also aligns with hda-analyser which mutes/unmutes sounds properly, and is connected through DAC2 0x02
 - No other outputs

I'm wondering where you get pin 0x17 from? I can't find it in the block diagram. Do you mean 0x1E? To me this seems to be the output going through 0x06.

Hopefully pedestrian question: hda-verb returns 'open: Device or resource busy'. Do I need to kill something? Or can I only run this on a fresh boot? Or am I giving bad params (trying 'hda-verb /dev/snd/hwC0D0 0x00 0xF00 0' just to obtain the vendor ID as a test, as per the realtek datasheet).
Comment 38 Ian 2017-03-22 02:04:25 UTC
Okay, yeah, I just needed to restart, now hda-verb works and is spitting out sensible things.
Comment 39 Tom Briden 2017-03-24 13:17:28 UTC
I have sound again! I had upgraded the drivers in Windows the day I thought I had it working and I'm pretty sure that's what breaks it in Linux.

I've just downgraded my windows drivers to 6.0.1.8000 Rev.A, rebooted to windows when prompted by the installer then rebooted to Linux. Then it's just a case of enabling 0x17 in hdajackretask and unmuting and setting to output in hda-analyzer

I'll attach an alsa-info for comparison, what other info is worth grabbing before I reboot and potentially break it again?
Comment 40 Tom Briden 2017-03-24 13:19:05 UTC
Created attachment 255499 [details]
alsa-info working speakers

I manually set the pincfg to 

0x17 0x90170111

to match the conexant x360 fix
Comment 41 Tom Briden 2017-03-24 18:17:29 UTC
suspend kills it and now i'm back to square one again, even rebooting to windows and back. must be something about the windows installer that makes it work briefly on reboot to linux?
Comment 42 Takashi Iwai 2017-03-24 19:34:00 UTC
Once when you get the working state on Linux, try to get the codec#* proc output (or alsa-info.sh output) after setting dump_coef parameter for snd-hda-codec module, e.g.
  echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef

Then it'll contain the COEF values in each proc widget in the codec.
Comment 43 Tom Briden 2017-03-24 20:05:03 UTC
Created attachment 255519 [details]
alsa-info inc coef

Thanks Takashi, attached is the alsa-info after setting dump_coef
Comment 44 Tom Briden 2017-03-24 20:32:32 UTC
if it's easier, here's the coeff diff with a non-working system
                                                                                                                                                                                                        
-    Coeff 0x08: 0x6a8c                                                 
+    Coeff 0x08: 0x6a0c                                      

-    Coeff 0x24: 0x0000                                                                                                   
+    Coeff 0x24: 0x0012                                                                   

-    Coeff 0x26: 0x0000                                                 
+    Coeff 0x26: 0x003a                                         

-    Coeff 0x28: 0x0000                                                  
-    Coeff 0x29: 0x3000                                                                                       
+    Coeff 0x28: 0x1dfe                                                                               
+    Coeff 0x29: 0xb014                                                                       

-    Coeff 0x2b: 0x0000                                                                                  
+    Coeff 0x2b: 0xfdfe                                                                                                                                                                                                         

-    Coeff 0x37: 0xfe05                                         
+    Coeff 0x37: 0xfe15                                        

-    Coeff 0x45: 0x5289                   
-    Coeff 0x46: 0x0004                    
+    Coeff 0x45: 0xd289                                                  
+    Coeff 0x46: 0x00f4                   

-    Coeff 0x67: 0xf200   
+    Coeff 0x67: 0x1000
Comment 45 Takashi Iwai 2017-03-25 07:12:28 UTC
You can adjust the COEF dynamically via hda-verb, e.g.
  hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x08
  hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x6a0c

will set the COEF value 0x6a0c to idx 0x08.
Hopefully some of the differences above has the effect...
Comment 46 Tom Briden 2017-03-25 10:28:43 UTC
I've added the coef's to patch_realtek.c in the kernel and all apply except 0x2b, which won't even take the setting via hda-verb. Still no sound
Comment 47 Tom Briden 2017-03-25 10:38:17 UTC
Created attachment 255529 [details]
patch to fix mute led

on a separate note, i've got the mute led working with the attached patch
Comment 48 Tom Briden 2017-03-29 10:26:21 UTC
Hi Takashi, any ideas for getting that last coefficient to take it's value? I've tried changing all of those that are different in patch_realtek.c using, eg

[ALC269_FIXUP_HP_SPECTRE_COEF] = {
    .type = HDA_FIXUP_VERBS,
    .v.verbs = (const struct hda_verb[]) {
        { 0x20, AC_VERB_SET_COEF_INDEX, 0x2b },
        { 0x20, AC_VERB_SET_PROC_COEF,  0xfdfe },
    { }
},



which, as I mentioned, works for everything except 0x2b which always stays at 0x0, even when using hda-verb.

In fact, after applying that and setting .chained/.chain_id to also apply HDA_FIXUP_PINS for 0x17, the only real difference in my alsa-info for a working and non-working system is that one coef


Thanks
Comment 49 Takashi Iwai 2017-03-29 12:03:19 UTC
It might be some volatile or read-only value.  Only Realtek knows.
Comment 50 Robert 2017-04-22 14:25:46 UTC
Hi,

I have a 13-w023dx with same problem on ubuntu 17.04 kernel 4.10.0-19. only bottom speakers work.
Comment 51 Robert 2017-04-22 14:27:33 UTC
Hi,

I have a 13-w023dx with same problem on ubuntu 17.04 kernel 4.10.0-19. only bottom speakers work.
Comment 52 Frans Skarman 2017-04-23 21:51:39 UTC
I have the same issue on a 13-w003 on arch kernel 4.10.11-1. Retasking port 0x17 to integrated speaker using hdajackretask did not work.

I also have no output through the headphone jack. The only sound comming out of it is a tiny crackle when audio starts and stops playing.
Comment 53 Robert 2017-04-28 21:57:26 UTC
same here. 0x17 has no effect, but the output through headphone jack seems to be right. I was thinking about installing a windows vm and passing the pci device to it, and running hda-verb in linux while the windows vm controls the soudncard. Tried with VB, but if I pass only the sound-card device, I can install windows, install the drivers, but device manager shows "windows cannot start the device". I read that the whole iommu group has to be passed to the vm. I tried that, but in this case the VB vm doesn't start at all.

# dmesg | grep iommu
[    1.269624] iommu: Adding device 0000:00:1f.0 to group 9
[    1.269629] iommu: Adding device 0000:00:1f.2 to group 9
[    1.269634] iommu: Adding device 0000:00:1f.3 to group 9
[    1.269640] iommu: Adding device 0000:00:1f.4 to group 9

# lspci
00:1f.0 ISA bridge: Intel Corporation Device 9d58 (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)
00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)

# for i in 0 2 3 4 ; do VBoxManage modifyvm "win10_pci" --pciattach 00:1f.$i@00:1f.$i ; done

Any clues if my assumption should/could work?
Comment 54 Saagar 2017-05-12 20:26:23 UTC
I have the same issue on a 13" w023dx (currently using Ubuntu - my top speakers don't work, but bottom ones do. After upgrading to Ubuntu 17.04, my headphone jack also stopped working. Downgrading didn't fix it. However, everything works on Windows.

Could someone with a working headphone jack compare my pins to theirs and see if there is any difference? It would be great if I could just get my headphones working on Linux.
Comment 55 Saagar 2017-05-12 20:28:13 UTC
Created attachment 256491 [details]
image of pin configuration (broken headphone jack)
Comment 56 Tom Briden 2017-05-12 20:41:52 UTC
Top speakers should work if you change driver version in Windows. it'll uninstall the current version and prompt a reboot, at that point reboot straight to linux and enable pin 0x17. This consistently works for me.
I don't use wired headphones but I have tried before and they seemed to work fine so compare your pin conf with mine in the alsa-info attached
Comment 57 Steve 2017-05-17 06:33:54 UTC
Created attachment 256589 [details]
Working speakers alsa info

Talked to Tom, ran his method as explained to me via email, and got my speakers working! Originally, I only had the front (bottom) right speaker working, so sound was horrible. I have the model version 13-W013DX. i7 with 8gb ram and 256gb ssd. Did driver reinstall on Windows (where sound worked fine), and during reboot after the drivers were uninstalled and before they were reinstalled, I booted to Ubuntu and did the config Tom suggested, and sound works fine now. After suspending the laptop for a brief second, the sound does go back to the usual (only the right bottom speaker works). So I'm assuming this is just a temp fix for now, hopefully we can get this working properly. Attached is my alsa info after fixing the speakers. Let me know if you need anything more.
Comment 58 Takashi Iwai 2017-05-17 06:46:36 UTC
Hrm, I suspected the difference being the COEF, but according to Tom's test, it doesn't look so.  Could you reconfirm that?  See comments from 42 to 46.
Comment 59 Steve 2017-05-17 06:49:56 UTC
Created attachment 256591 [details]
Speakers working Alsa-Info

Ok apparently I was given the wrong command (thanks Tom), so I redid the alsa info (attached) with 1 in params/dump_coef ?
Comment 60 Tom Briden 2017-05-17 06:54:39 UTC
Hi Takashi, I think it's related to coeff 0x2b. When speakers work it's value is 0xfdfe and when they don't it's 0x0. It seems to be read-only though when in Linux, even if I try to set it in patch_realtek.c

Looks like the same value on Steve's laptop too. Steve, can you please do another alsa-info with non-working speakers and dump_coef set to 1? 

After that, try running:

  hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
  hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xfdfe

which should set the coeff, then 


  hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
  hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0x0

which should get the value you just set. For me that still returns 0x0.
Comment 61 Steve 2017-05-17 07:07:58 UTC
Created attachment 256593 [details]
Alsa info when only one speaker works

Here is the alsa info after suspending the laptop quickly to get it back to only one speaker working. Also, below I'll paste the output of the commands you said to run


steve@steve-x360:~/Scripts/Alsa$ hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
open: Permission denied
steve@steve-x360:~/Scripts/Alsa$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
nid = 0x20, verb = 0x500, param = 0x2b
value = 0x0
steve@steve-x360:~/Scripts/Alsa$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xfdfe
nid = 0x20, verb = 0x400, param = 0xfdfe
value = 0x0
steve@steve-x360:~/Scripts/Alsa$ sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
nid = 0x20, verb = 0x500, param = 0x2b
value = 0x0
steve@steve-x360:~/Scripts/Alsa$ sudo hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0x0
nid = 0x20, verb = 0xc00, param = 0x0
value = 0x0
Comment 62 Frans Skarman 2017-05-17 07:18:00 UTC
I was able to set the coefficient, but when I do, all sound stops working except for a pop when sound starts or stops playing. This is exactly the same thing that happens when I plug in headphones.

```
    sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b                                                                                                                                                                   
    nid = 0x20, verb = 0x500, param = 0x2b
    value = 0x0
    sudo hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0xfdfe                                                                                                                                                            
    nid = 0x20, verb = 0x400, param = 0xfdfe
    value = 0x0
    sudo hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x2b
    nid = 0x20, verb = 0x500, param = 0x2b
    value = 0x0
    sudo hda-verb /dev/snd/hwC0D0 0x20 GET_PROC_COEF 0x0
    nid = 0x20, verb = 0xc00, param = 0x0
    value = 0xfdfe
```
Comment 63 Frans Skarman 2017-05-17 07:23:38 UTC
Suspending and unsuspending the laptop seems to have undone the change and now the coeff seems to be write only.
Comment 64 Kailiang Yang 2017-05-17 09:05:18 UTC
I checked the COEF 10h for verb setting.
The value is correct 0x0020.
Comment 65 Tom Briden 2017-05-17 09:38:20 UTC
Hi Kailiang,

verb setting does work on other coefficients. You can see from the working/non-working alsa-info's attached that the COEF's that are different are:

-    Coeff 0x08: 0x6a8c
+    Coeff 0x08: 0x6a0c

-    Coeff 0x24: 0x0000
+    Coeff 0x24: 0x0012

-    Coeff 0x26: 0x0000
+    Coeff 0x26: 0x003a

-    Coeff 0x28: 0x0000
-    Coeff 0x29: 0x3000
+    Coeff 0x28: 0x1dfe
+    Coeff 0x29: 0xb014

-    Coeff 0x2b: 0x0000
+    Coeff 0x2b: 0xfdfe
-    Coeff 0x37: 0xfe05
+    Coeff 0x37: 0xfe15

-    Coeff 0x45: 0x5289
-    Coeff 0x46: 0x0004
+    Coeff 0x45: 0xd289
+    Coeff 0x46: 0x00f4

-    Coeff 0x67: 0xf200
+    Coeff 0x67: 0x1000


Of these, only 0x2b won't take the value when set via patch_realtek.c or hda-verb. This is why I think that's the one we need to fix the speakers as I can get to a point where that's the only line different between a working/non working alsa-info output.
Comment 66 Takashi Iwai 2017-05-17 09:45:04 UTC
Looking at Steve's alsa-info.sh outputs, the clear difference is the pin 0x17.
I guess you didn't set up via the early patching, right?  If so, try to create a file /lib/firmware/alsa/hp-spectre-x360 containing the following lines:

[codec]
0x10ec0295 0x103c827e 0

[pincfg]
0x17 0x90170111


... then pass it to patch option of snd-hda-intel module, e.g. create /etc/modprobe.d/90-hp-spectre-audio.conf containing the following line:

options snd-hda-intel patch=alsa/hp-spectre-x360


This will give a new mixer element "Bass Speaker" switch, and unmute it.
At least, this should "fix" one thing.  But I guess something else is also still missing too.
Comment 67 Tom Briden 2017-05-17 16:00:49 UTC
Created attachment 256603 [details]
attempt to fix coeffs

I've attached the kernel patch I'm currently using to try and fix this, this is based on 4.11; As I mentioned, all coeffs from the patch get set except for 0x2b. Using this though, I can at least reboot from the windows installer straight into a working system when I need speakers.
Comment 68 Kailiang Yang 2017-05-18 06:32:46 UTC
Hi Tom,

Don't write any thing for coef 0x2b.
It's the read only register.
Maybe 0x67 could do the test.

-    Coeff 0x67: 0xf200
+    Coeff 0x67: 0x1000

I don't know why 0x67 will change to 0x1000.
Comment 69 Kailiang Yang 2017-05-18 07:05:13 UTC
0x17 pin is I2S out.
So, it will have I2S codec connect after 0x17 pin.
Comment 70 Tom Briden 2017-05-18 07:27:53 UTC
Hi Kailiang,

The value of 0x67 can be changed with hda-verb; When the speaker doesn't work it's 0xf200 and when rebooting from Windows during a driver switch (when speakers do work) it's 0x1000. However, changing this coef value from a cold boot doesn't seem to have any effect regardless of which of those values it has.

While being read-only, 0x2b is always 0x0 from a coldboot but does have a value when rebooting from Windows. On a normal reboot from Windows (without a driver change) the value is 0xcf0 but speakers don't work. During a driver switch, when they do work, it's 0xfdfe

For pin 0x17, is there anything in particular we need to do to use the I2S codec?


Thanks
Comment 71 Kailiang Yang 2017-05-18 07:57:18 UTC
I don't know for I2S control.
Because HP maybe no support Ubuntu for this platform.
So, I don't know which hardware architecture.
Comment 72 Kailiang Yang 2017-05-18 09:42:41 UTC
Hi Tom,

This issue only happen on Windows reset then boot into Linux. Right?
Comment 73 Tom Briden 2017-05-18 09:47:35 UTC
The issue is that the top speakers don't work at all in Linux without doing the following:



Boot into Windows and run an installer for a different version of the Realtek drivers than what is currently installed (the HP support site allows you to download previous versions)

The first thing that happens is the current drivers get uninstalled and you're prompted to reboot. By rebooting straight into Linux at this point, and enabling pin 0x17 the speakers will work. 

As soon as the laptop shuts down or suspends, the speakers stop working again.
Comment 74 Steve 2017-05-19 13:21:02 UTC
Interestingly enough, I've just noticed if I simply close the laptop, come back and open it even hours later, I am prompted with a login as if I suspended, however when I log back in the sound still works!
Comment 75 Benjamin Schmitz 2017-05-31 14:16:27 UTC
Not sure how much it helps, but here is my theory:

The top speakers (and possibly headphone jack) are possibly driven by an external amplifier. Under Windows the driver takes care of powering up the amp on system startup and powers it down on shutdown.

Now, if you go ahead and uninstall the Windows driver and reboot, the amp is NOT powered down because the driver was uninstalled. Therefore, the speakers work if you reboot straight into Linux. Once you power cycle the system, it will not come back on, however.

This would also be consistent with Kailiang mentioning that pin 0x17 (which needs to be enabled for the speaker to work) is I2S output. The hda codec might send audio data to the external amplifier via I2S.

I think that with the patches by Takashi and Tom, the hda codec is already set up properly. However, that won't help since the speaker amp is still powered down. 

Maybe it is worth investigating into other directions, beyond the hda driver. Maybe the speaker amp is an external device that can be accessed by other means (e.g. I2C ?). Did anyone open up the x360 to see how the speakers are connected? Maybe we can find a hardware teardown online.

I know we are not any wiser now, but I just wanted to throw that theory out there, in case any of you who are working on this are currently stuck and don't know what to try next.
Comment 76 Robert 2017-05-31 15:40:36 UTC
A shortcut is to install windows in a libvirt machine and pass the sound pci bus through. I've just tried the theory, launched the windows vm and force powered off, so no windows shutdown and got my top speakers working, but vol control works only for the bottom ones. I guess the volume for the top ones is what was set in the windows vm.
Comment 77 Tom Briden 2017-05-31 15:55:07 UTC
Robert, try setting the connection select for pin 0x17 to 'Audio Ouput [0x2]' using hdaanalyzer. you then be able to control the volume using the master volume control
Comment 78 Robert 2017-05-31 16:06:37 UTC
Tom, works. Thanks! the control doesn't seem to be quite right though. up to like 30% is silent and then starts to turn the volume. Not sure if it's the same on windows, didn't notice so far.
Comment 79 Steve 2017-05-31 16:37:32 UTC
Ben, thanks for the input.. Very sound theory there and I appreciate others helping move this issue forward, we are so close to getting this figured out. Can't wait for the day I can finally get rid of Windows completely.

Speaking of, has anyone has any luck running Linux as the only OS? Does the speaker issue remain the same?

Also, Tom, is there any fix to the headphone jack yet? I get the speakers working fine after the boot process and hdaanalyzer fix you told me of, but the headphone jack remains dead, so to speak, in Linux.
Comment 80 Elias Gabrielsson 2017-06-02 11:10:06 UTC
I have used the computer with Linux only with no success.
As Ben suggest maybe some hardware review could gives some new clues.
Here is images of the internals: https://www.laptopmain.com/hp-spectre-x360-disassembly-and-ram-ssd-upgrade-options/
Comment 81 Benjamin Schmitz 2017-06-03 21:24:25 UTC
Small update: Tom, I found that you do not need to uninstall the driver in Windows. It is enough if you disable it in the device manager (just right-click the Realtek device and select disable). You can then reboot straight into Linux and the speakers will be working. 
After power cycling you need to boot into Windows again, then enable and disable the device.

That is a lot faster than uninstalling and reinstalling the driver and should make testing easier.

For those running Windows inside a VM: is it possible to dump the PCI communication with the device and could that be of any help?


Also, even though I can get my speakers working using the above method, my headphone jack still remains without function (apart from detecting when a plug was inserted). Those with working headphone jacks: any comments how to get it working? What kernel version are you using and what is your Spectre model number?
Comment 82 Nate Graham 2017-06-03 21:27:16 UTC
The headphone jack has worked for me from day 1, with every kernel from 4.8.x through 4.11.x. My machine's model number is 13-w013dx.
Comment 83 Tom Briden 2017-06-04 17:42:19 UTC
I've got all speakers working in a libvirt VM (thanks Robert) and Ben's find to just disable/enable the drivers in Device manager works there too with a clean shutdown. I've started looking into kernel tracing using mmiotrace or iommu tracing as described here https://blogs.s-osg.org/how-can-iommu-event-tracing-help-you/ but this is all new to me so not getting very far right now. If anyone following this thread has experience with this or any other suggestions for getting more info via the VM then it'd be appreciated.

As for headphones, I too haven't had any issue with them but I only tried a couple of times as I tend to use BT for headphones. Mine is a 13-ac004na
Comment 84 Steve 2017-06-04 20:07:39 UTC
Interestingly enough, I have the same model (13-w013dx) and I have never been able to get the headphones to work in Ubuntu.. Although I can get the speakers to work via Tom's hdaanalyzer finagling.
Comment 85 Frederic 2017-07-13 10:57:33 UTC
Hi,

I have a 13-w023dx, same problem here. Only bottom speakers work (no headphones too). I'm running the gentoo-4.9.34 kernel.

Headphones unmute in alsa when plugged in, but besides the crackling already mentioned by Oleg, no sound. (they worked on windows, but I wiped it after checking)
Comment 86 Frederic 2017-07-13 10:59:33 UTC
PS I tried upgrading the bios (to F.32), but sadly that didn't help.
Comment 87 Steve 2017-07-15 00:14:42 UTC
Just disabling audio device in device manager in Windows works for me too, though it doesn't last after suspending the laptop.

Could someone give a quick rundown on what needs to be done to run the VM and use that to jimmyrig the sound? Would love to be able to just log into Ubuntu and fix it from there. I've tried using win 10 via virtual box in Ubuntu but I can't figure out pushing the sound bus through to it or get it to work. Would be greatly appreciated.

Fredric, must be our model that has something different with the headphone jack, for the life of my I can't get mine to work either, but I can eventually jimmyrig the speakers you work.
Comment 88 Robert 2017-07-15 11:02:47 UTC
Created attachment 257531 [details]
qemu xml for sound card pci passthrough

Hi Steve, 

I've also tried to get it working with virtualbox with no luck. It works fine with kvm. See my xml attached. You'll need to adjust the path to disk and iso images ....

Cheers,
Robert
Comment 89 Tom Briden 2017-07-20 10:26:45 UTC
Just thought I'd add an update to this. A while back I did some vfio tracing with the pci card passed through to qemu but unfortunately the tracing didn't seem very useful. To try and get a feel for what was actually being traced, I ran some hda-verb commands via a qemu Fedora VM: https://pastebin.com/QDQS9nwP

Given the log didn't contain the known values I was seeing from hda-verb, I asked in #vfio-user on irc:

<awilliam> tombriden: seems like you're assuming a programmed I/O model of the device rather than a DMA model, those accesses could just be poking the device to go read the next command in memory
<awilliam> I'd go look in the linux code to see what those registers are
<awilliam> I'd guess 48/4a are some sort of head/tail pointers in a queue, we write a new head or tail, then 5d seems like a "go" register and we're OR'ing it with 4 to kick it

<awilliam> between the qemu monitor and a gdb session, if you knew where this queue thing was you could break on vcpu access to it and see what is getting written there.  It's substantially harder and you need to know something about the programming model of the device to do it


So yeah, this may be beyond my expertise now!
Comment 90 Frederic 2017-07-21 19:35:41 UTC
Maybe someone from hp will be willing to help. I posted the bug on their support forum:
https://h30434.www3.hp.com/t5/Notebook-Audio/Headphone-jack-and-top-speakers/m-p/6233434#M86120

If there's something I missed, please correct me.
Comment 91 Alejandro Díaz-Caro 2017-08-12 23:39:50 UTC
Hi, I have the same problem in my Spectre. I am trying to use the trick with QEMU/KVM, however, I cannot pass the Audio device to QEMU/KVM since, in my computer, the device is in the same IOMMU group as the Memory Controller (and the Memory Controller cannot be passed with vfio). I am trying with a kernel patch (https://aur.archlinux.org/cgit/aur.git/tree/add-acs-overrides.patch?h=linux-vfio) which allows to pass some of the devices without passing all of them. However, I wonder how did you managed this problem.

Here are the devices I have in the same IOMMU:
IOMMU Group 9 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:9d4e] (rev 21)
IOMMU Group 9 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-LP PMC [8086:9d21] (rev 21)
IOMMU Group 9 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:9d71] (rev 21)
IOMMU Group 9 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-LP SMBus [8086:9d23] (rev 21)

Sorry for the noise, this is not directly related to the bug, but to the only working workaround commented here.
Comment 92 Saagar 2017-10-12 05:13:21 UTC
Has anyone made any progress on either the headphone or top speaker problem?
Comment 93 David 2017-12-18 03:55:35 UTC
I found a solution to the headphone problem - same sound card, but different laptop model.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1648183
Comment 94 Tom Briden 2017-12-18 19:03:44 UTC
Doesn't work for me unfortunately.
Comment 95 Nate Graham 2017-12-18 19:04:58 UTC
What model? That fix does work for me with a 13-w013dx.
Comment 96 Tom Briden 2017-12-18 19:10:36 UTC
Ah sorry, I got excited thinking this was a fix for the B&O speakers not working! I should have read it properly beforehand. I never actually experienced the issue with the headphones crackling, my model is ac004na
Comment 97 Nate Graham 2017-12-18 19:18:50 UTC
Originally I didn't either--or just didn't notice it--but either way it had become noticeable in the past few weeks and the fix listed there took care of it.

Also Tom, would you be able to submit your mute LED patch? It looks like it got missed here.

Finally, what are our options for figuring out why we can't set pin 0x17 in Linux without first doing the Windows rigmarole?
Comment 98 Tom Briden 2017-12-18 19:31:39 UTC
I think the issue is actually to do with the Realtek drivers powering the speakers on/off on boot/shutdown, so by disabling the drivers it never gets a chance to power them off. Setting pin 0x17 is just an extra step required for them to work once powered. There's a kernel patch I attached a while back that sets the pins and coeff's to match what their values are once it's in a working state, if you apply the patch then the speakers will just work once the windows VM releases the PCI device, rather than having to do that step manually too. Interestingly, I'm setting the COEF for 0x67 to 0x1000 in that patch, not 0x3000 as suggested in the other thread, do you mind checking if using 0x1000 works too?

I purposely hadn't submitted the mute patch as I think I'm still missing something there. I dual-boot android-x86 and that patch results in the light being always on under android which isn't something I've seen on other laptops. I might get a chance to look into that soon though so we can at least have that fixed in mainline!
Comment 99 Oleg Mikheev 2017-12-18 20:32:56 UTC
Created attachment 261247 [details]
attachment-1613-0.html

Is there any way to understand how this "powering the speakers on/off on boot/shutdown" actually works?
Something tells me if it's still unresolved in 1 year then upgrading the laptop would be an easier option vs trying to fix it...

On December 18, 2017 2:31:39 PM EST, bugzilla-daemon@bugzilla.kernel.org wrote:
>https://bugzilla.kernel.org/show_bug.cgi?id=189331
>
>--- Comment #98 from Tom Briden (tbriden@googlemail.com) ---
>I think the issue is actually to do with the Realtek drivers powering
>the
>speakers on/off on boot/shutdown, so by disabling the drivers it never
>gets a
>chance to power them off. Setting pin 0x17 is just an extra step
>required for
>them to work once powered. There's a kernel patch I attached a while
>back that
>sets the pins and coeff's to match what their values are once it's in a
>working
>state, if you apply the patch then the speakers will just work once the
>windows
>VM releases the PCI device, rather than having to do that step manually
>too.
>Interestingly, I'm setting the COEF for 0x67 to 0x1000 in that patch,
>not
>0x3000 as suggested in the other thread, do you mind checking if using
>0x1000
>works too?
>
>I purposely hadn't submitted the mute patch as I think I'm still
>missing
>something there. I dual-boot android-x86 and that patch results in the
>light
>being always on under android which isn't something I've seen on other
>laptops.
>I might get a chance to look into that soon though so we can at least
>have that
>fixed in mainline!
>
>-- 
>You are receiving this mail because:
>You reported the bug.
Comment 100 David 2017-12-18 20:41:22 UTC
(In reply to Nate Graham from comment #95)
> What model? That fix does work for me with a 13-w013dx.

I have an 13-ac023dx.

i7, 16GB RAM, 512GB SSD, 1080p.
Comment 101 ibrokemypie 2018-01-02 16:27:20 UTC
on the 13-ae0xx audio seems to only play out the back speakers.

    description: Convertible
    product: HP Spectre x360 Convertible 13-ae0xx (2YS36PA#ABG)
    vendor: HP
    version: Chassis Version
    serial: 5CD7443N5L
    width: 4294967295 bits
    capabilities: smbios-3.0 dmi-3.0 smp vsyscall32
    configuration: boot=normal chassis=convertible family=103C_5335KV HP Spectre sku=2YS36PA#ABG uuid=35434437-3434-334E-354C-4C4E34344435
Comment 102 ibrokemypie 2018-01-11 03:29:12 UTC
My device is specifically the 13-ae024tu
Comment 103 John LF 2018-04-21 14:51:02 UTC
I have a HP Spectre x360 w063nr. The top speakers do not work and no sound from headphone jack.

I've tested on multiple distros(therefore multiple kernels) and this issue remains a major problem even after 2 years.

From what I'm seeing no one is able to fix it despite this laptop being a top-seller for multiple years.

Is there any hope? Because I am thinking of just selling off this machine at this point.
Comment 104 Osip Fatkullin 2018-04-21 20:22:43 UTC
(In reply to John LF from comment #103)
> Is there any hope? 

I think it's possible make headphones work. Because when I've installed Arch Linux first time it was working and become broken only after second installation.
Infourtanetly I don't know what changed between installations and what makes headphones not work.
Comment 105 John LF 2018-04-22 16:50:37 UTC
(In reply to Osip Fatkullin from comment #104)
> (In reply to John LF from comment #103)

> I think it's possible make headphones work.

I believe only HP can help resolve this issue. But of course they won't step in since there isn't enough noise around this issue. Only a tiny fraction of buyers have linux installed on these machines. 

As you can see above, a lot of work went in to trying to fix this but they've hit dead-ends. Unfortunately, I think this will remain unsolved.
Comment 106 Alejandro Díaz-Caro 2018-04-24 13:24:08 UTC
I twitter to HP Support:

 https://twitter.com/JanusDC/status/988765061849255937

and there is a post in their forum:

https://h30434.www3.hp.com/t5/Notebook-Audio/Headphone-jack-and-top-speakers/m-p/6233434#M86120

Maybe we should try to make some noise? Please, RT the twit and like or comment in the forum.
Comment 107 ibrokemypie 2018-04-24 13:27:04 UTC
(In reply to Alejandro Díaz-Caro from comment #106)
> I twitter to HP Support:
> 
>  https://twitter.com/JanusDC/status/988765061849255937
> 
> and there is a post in their forum:
> 
> https://h30434.www3.hp.com/t5/Notebook-Audio/Headphone-jack-and-top-speakers/
> m-p/6233434#M86120
> 
> Maybe we should try to make some noise? Please, RT the twit and like or
> comment in the forum.

in your tweet you mention the OPPOSITE of the problem, the problem is that ONLY the front speakers work, whereas your tweet states they DON'T work, which will be confusing to anyone who looks at this
Comment 108 Alejandro Díaz-Caro 2018-04-24 13:30:51 UTC
Sorry, I did not notice that everybody says "front speakers" for the bottom ones. For me, the "front" were those at top.
Here is a corrected twit.

https://twitter.com/JanusDC/status/988772165859381248
Comment 109 Dario 2018-04-25 23:02:52 UTC
I've just rt, same issues here regarding top/upper speakers.
Comment 110 Tom Briden 2018-04-26 11:23:32 UTC
I thought I'd have another crack at this over the last week and I feel like I'm getting close, but still not there yet. I want to get the steps written down in case others have any ideas as I am now able to access the command and response buffers used to communicate to the sound card from Windows.

Firstly, to access the memory you need a kernel built with CONFIG_STRICT_DEVMEM=N

With this kernel setting, you can get a memory dump of the "base address registers" for the sound card. Using 'lspci -v' you can get the register physical addresses, eg:

00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) (prog-if 80)
        Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio
        Flags: bus master, fast devsel, latency 32, IRQ 16
        Memory at dc228000 (64-bit, non-prefetchable) [size=16K]
        Memory at dc200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel, snd_soc_skl

and dump to file with dd 

sudo dd if=/dev/mem bs=1 count=16k skip=$((16#dc228000)) of=realtek.dump

and use hexdump -x realtek.dump to analyze

Referencing the device register table from https://wiki.osdev.org/Intel_High_Definition_Audio#Device_Registers and monitoring the vfio_region_write traces from qemu, the memory dump values nicely match up with values being written. However these values aren't the actual commands/responses.

Two of the device registers are for lower addresses of the 'command output ring buffer' and the 'response input ring buffer' but the values written there by the driver are virtual addresses. Using trace_events=iommu on the laptop kernel, you can trace the memory mappings of the VM and find the physical address that maps to the virtual address block; then calculate the actual physical memory address using the offset of the lower addresses in that block.
To confirm this, booting Windows with the device disabled in device manager and dumping those ring buffers shows a few commands already in there, one of which is 000f0000 which has a corresponding response of 10ec0295 and that matches perfectly to the hda-verb command "0x0 PARAMETERS 0x0"

The size of those ring buffers allows for 256 commands and responses before looping back through the same memory. Unfortunately, enabling the driver in Windows uses more than 256 commands so you need to attach gdb to the qemu process and set a breakpoint on the vfio_region_write command when the address being written is 0x48 and the value is 0x0 and then dump the memory, this can all be done automatically from gdb:

gdb> break hw/vfio/common.c:130 if (addr==72) && (data==0)
gdb> commands
gdb> shell dd if=/dev/mem bs=1 count=1k skip=$((16#349FCA000)) of=win_enable-$(date +%s.%N).dump
gdb> continue
gdb> end

The result is about 30 dumps of the command output buffers that contain all the commands sent by the driver to the sound card from Windows. Promising as this is, I turned them back into hda-verb commands and ran them all through in Linux but it still doesn't fix the issue. Weirdly though, some of the commands result in 'invalid verb' errors so there's probably something else I need to do with those.
Comment 111 Egor 2018-04-26 11:40:00 UTC
(In reply to Tom Briden from comment #110)

Nice catch! Thanks for your explanation.
If we still can't use hda-verb command then maybe is it possible to make some kind of low-level workaround to replay all the things what windows driver do on boot?
Comment 112 Tom Briden 2018-04-28 15:34:34 UTC
I have sound from a cold boot!!!!!

There were a couple of issues with my testing the other day, firstly I needed my breakpoint in gdb to dump the memory when data==255 so I was missing a few of the commands. Secondly, I was using the hda-verb.c source to reverse the memory back into nid/verb/param which actually wasn't right, I needed to reverse the bit-shifting the kernel code does to generate the command.
So, having sorted those two isses, I got some new dumps and turned them into a script with ~6500 hda-verb commands; after running that and resetting pulseaudio - sound was working!!

I've now removed all the 'Get' commands from the list and created a kernel patch but there are still over 5000 verbs in the array. Most of them probably aren't necessary as they'll already be set up by the kernel but it's going to be a long tedious process to work out which commands specifically fix the speakers. (and playing sound while running them through hda-verbs doesn't work).

For now, I'll attach the current patch for anyone who wants to test and confirm. It's based on 4.17-rc2 but should be pretty straight forward to apply to older versions if required.
Comment 113 Maxim Berman 2018-04-28 15:40:22 UTC
(In reply to Tom Briden from comment #112)
> I have sound from a cold boot!!!!!
> 
> There were a couple of issues with my testing the other day, firstly I
> needed my breakpoint in gdb to dump the memory when data==255 so I was
> missing a few of the commands. Secondly, I was using the hda-verb.c source
> to reverse the memory back into nid/verb/param which actually wasn't right,
> I needed to reverse the bit-shifting the kernel code does to generate the
> command.
> So, having sorted those two isses, I got some new dumps and turned them into
> a script with ~6500 hda-verb commands; after running that and resetting
> pulseaudio - sound was working!!
> 
> I've now removed all the 'Get' commands from the list and created a kernel
> patch but there are still over 5000 verbs in the array. Most of them
> probably aren't necessary as they'll already be set up by the kernel but
> it's going to be a long tedious process to work out which commands
> specifically fix the speakers. (and playing sound while running them through
> hda-verbs doesn't work).
> 
> For now, I'll attach the current patch for anyone who wants to test and
> confirm. It's based on 4.17-rc2 but should be pretty straight forward to
> apply to older versions if required.

Amazing news! Congratulations, I'm very eager to test it out.
Comment 114 Tom Briden 2018-04-28 15:43:52 UTC
Created attachment 275647 [details]
Fix speakers by applying ALL verbs applied by Windows
Comment 115 Frederic 2018-04-28 16:52:46 UTC
Good fortune smiles upon us! I just compiled the patch and it _works_.
Tom, thank you. May the Old One give you and your family all the desires of your heart and make all your plans succeed. I'm blasting Ice Ice Baby and downloading some old Star Trek TOS. You've made my week -- I hope yours will be exquisite as well. <deep bow>
Comment 116 Oleg Mikheev 2018-04-28 18:48:25 UTC
Unfortunately doesn't work out of the box here

Possible differences are:

- kernel 4.16.5
- mine is 13-w023dx (same as Frederic)
- I didn't upgrade BIOS (version: F.11 date: 11/18/2016)
- my lspci -v is very different from Tom's:

00:1f.3 Audio device: Intel Corporation Device 9d71 (rev 21) (prog-if 80)
	Subsystem: Hewlett-Packard Company Device 827e
	Flags: bus master, fast devsel, latency 32, IRQ 129
	Memory at dc228000 (64-bit, non-prefetchable) [size=16K]
	Memory at dc200000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 3
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl
Comment 117 Takashi Iwai 2018-04-28 19:19:31 UTC
Great to hear that you crack the stuff finally.

Could you try to get the diff of COEF dump?  Try the following:

- Set dump_coef=1 option to snd-hda-codec module, e.g. create a file /etc/modprobe.d/50-hda-coef.conf containing

  options snd-hda-codec dump_coef=1

- Load the unpatched HD-audio module, and get the proc file output from /proc/asound/card0/codec#0 (or the file corresponding to your codec).

- Do the same for the patched driver.

In this way, we can compare the COEF dumps.  Please upload these two.
Comment 118 Oleg Mikheev 2018-04-28 22:12:15 UTC
upgraded BIOS to F.45 and applied patch to kernel 4.17-rc2, still no luck but must be so close
Comment 119 Dario 2018-04-29 00:51:53 UTC
Created attachment 275653 [details]
attachment-5374-0.html

Guys, I wonder how did you managed to upgrade to F.45, since I'm only
getting this version
<https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-spectre-13-ae000-x360-convertible-pc/16779579/model/17959161/swItemId/ob-206143-1>

---
Lic. Darío Silva Morán

On Sat, Apr 28, 2018 at 7:12 PM, <bugzilla-daemon@bugzilla.kernel.org>
wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=189331
>
> --- Comment #118 from Oleg Mikheev (omikheev@gmail.com) ---
> upgraded BIOS to F.45 and applied patch to kernel 4.17-rc2, still no luck
> but
> must be so close
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>
Comment 120 Oleg Mikheev 2018-04-29 01:10:38 UTC
F.45 is here https://support.hp.com/us-en/drivers/selfservice/swdetails/hp-spectre-13-w000-x360-convertible-pc/12499178/model/13443279/swItemId/ob-206872-1

Are there any other success stories with the latest patch?
Comment 121 Alejandro Díaz-Caro 2018-04-29 01:31:31 UTC
F.31 here, with kernel 4.16.4 in Arch Linux. It worked like a charm.
Thank you Tom, it is amazing to finally hear the sound of those speakers.

I cannot upgrade the BIOS since I do not have any windows installed. But anyway, the patch worked without problems with this old BIOS version.

For those with Arch Linux: you can follow the instructions here on how to easily build the official Arch kernel, adding the patch from #comment114:
https://wiki.archlinux.org/index.php/Kernels/Arch_Build_System

I just did a 

zcat /proc/config.gz > .config

first, so I did not have to touch anything else from the config. It is just vainilla kernel with the standard patchs by Arch, and with Tom's magic patch.
Comment 122 Tom Briden 2018-04-29 07:54:37 UTC
Hi Takashi, I've just diff'd the coeffs like you suggested and tried to manually set each but that doesn't work. I'll upload the 2 outputs in a sec. 
what's interesting is that there seems to be a lot of SET_COEF_INDEX calls followed by various different verbs that aren't SET_PROC_COEF (eg 0x48d, 0x402, etc). There also seem to be a lot of COEF's set on nid 0x58 as well as 0x20.

I've now removed all the pairs of SET_COEF_INDEX and GET_PROC_COEF from the verb array so that's down to ~3500. If anyone also wants the mute LED to work, you can clone/cherry-pick from my kernel fork here: https://github.com/tombriden/linux/commits/master
Comment 123 Tom Briden 2018-04-29 07:55:53 UTC
Created attachment 275655 [details]
cat /proc/asound/card0/codec#0 - working
Comment 124 Tom Briden 2018-04-29 07:56:32 UTC
Created attachment 275657 [details]
cat /proc/asound/card0/codec#0 - not working
Comment 125 Takashi Iwai 2018-04-29 08:36:38 UTC
The diff shows that it's not only about COEF but some pin setups differ.
The most significant one is the NID 0x17 pin configuration.  The non-working case is disabled while the working case has 0x90170110.  Maybe this is more important?
Comment 126 Takashi Iwai 2018-04-29 08:38:47 UTC
Oh, and GPIO[2] also differs.
Comment 127 ibrokemypie 2018-04-29 10:30:58 UTC
The kernel patch doesnt seem to have worked for me either with 4.17
model 13-ae024TU
fdisk -v:
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) (prog-if 80)
	Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio
	Flags: bus master, fast devsel, latency 32, IRQ 139
	Memory at dcc28000 (64-bit, non-prefetchable) [size=16K]
	Memory at dcc00000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 3
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl
Comment 128 Tom Briden 2018-04-29 11:01:15 UTC
Takashi, I had done my tests with 0x17 enabled but setting the different COEFs manually didn't work. 
Can you take a look at this patch (https://github.com/tombriden/linux/commit/abe94ea0f078b00eef2b0e2565f60822ebf536da); 
It also works fine but just sets up 0x17 properly and then runs through all the coeffs that Windows does. It doesn't seem to be any single value that fixes it but more the combination of some/all of them. One thing I noticed while using hda-verb to set them all is the coeff index 0x2b is read-only if you try and set with hda-verb but actually changes to different values throughout the process of setting the rest, by the end of the run it's gone from 0x0000 to 0xffff
Comment 129 Frans Skarman 2018-04-29 11:18:53 UTC
No luck for me either. bios 4.16.5-1 on a 13-w0xx with bios version F.20 (which seems to be the latest one i can install). Both the top speakers and headphone jack are still quiet.

And this is the output of `lspci -v`

```
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21) (prog-if 80)
        Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio
        Flags: bus master, fast devsel, latency 32, IRQ 145
        Memory at dc228000 (64-bit, non-prefetchable) [size=16K]
        Memory at dc200000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel, snd_soc_skl
```
Comment 130 Tom Briden 2018-04-29 14:13:57 UTC
Can someone who this isn't working for run the following commands and attach the output from the second (while running the patched kernel)

echo 1 | sudo tee /sys/module/snd_hda_codec/parameters/dump_coef
cat /proc/asound/card0/codec#0
Comment 131 Frans Skarman 2018-04-29 14:31:15 UTC
Sure, here is the output

https://gist.github.com/TheZoq2/351849e1fb8c18685cc41982661a2781


By the way, is there a way to tell if the patch has been applied to the kernel. Since this is my first time building a custom kernel I wouldn't be surprised if I missed some step somewhere.
Comment 132 Tom Briden 2018-04-29 14:49:51 UTC
Frans, I'm not sure if you are running with the patch. If you used the one I attached to this thread your output for Node 0x17 should show a "Pin default" of 0x90170110
Comment 133 Takashi Iwai 2018-04-29 16:00:41 UTC
(In reply to Tom Briden from comment #128)
> Takashi, I had done my tests with 0x17 enabled but setting the different
> COEFs manually didn't work.

Interesting.  Since it writes to the same index 0x29 or others, maybe the sequence must be important.  These are possibly the indirect indexing to DSP or COEF table like EQ.

> Can you take a look at this patch
> (https://github.com/tombriden/linux/commit/
> abe94ea0f078b00eef2b0e2565f60822ebf536da); 
> It also works fine but just sets up 0x17 properly and then runs through all
> the coeffs that Windows does. It doesn't seem to be any single value that
> fixes it but more the combination of some/all of them. One thing I noticed
> while using hda-verb to set them all is the coeff index 0x2b is read-only if
> you try and set with hda-verb but actually changes to different values
> throughout the process of setting the rest, by the end of the run it's gone
> from 0x0000 to 0xffff

For the COEF setup, an easier way would be to have a struct coef_fw table and write it via alc_process_coef_fw() in a fixup function.
Comment 134 Frans Skarman 2018-04-29 16:22:25 UTC
(In reply to Tom Briden from comment #132)
> Frans, I'm not sure if you are running with the patch. If you used the one I
> attached to this thread your output for Node 0x17 should show a "Pin
> default" of 0x90170110

You are right, I added the patch to the prepare() funktion in pkgbuild and the top speakers seem to work now. 

However, I don't think any of the coeff values changed from the last time I checked the /proc/asound/card0/codec#0 thing. For reference, here is the output https://gist.github.com/TheZoq2/2d606f9b099ad39acb7d3ec8793a7d7c

Also, my headphone port is still quiet though I suppose that might be another issue.
Comment 135 Benjamin Schmitz 2018-04-29 16:53:45 UTC
I applied the patch by Tom Briden, and the top speakers are indeed working. However, the sound is extremely loud and distorted.

Using hda-analyzer I reconfigured the connection of PIN [0x17] from "Audio Output [0x06]" to "Audio Output [0x02]". This gave me the ability to control the volume of the speakers using the master volume control. Master then controls the volume of all speakers, top and bottom.

The problem is not fixed, though: the volume of the top speakers is still way too loud compared to the bottom speakers. At anything above 50% the volume becomes unbearable and heavy distortion occurs. Even at lower volumes, the sounds seems unbalanced with way too much treble. But that is probably a result of the top speakers being too loud compared to the bottom speakers.

Do you know how I could configure it, so I can control the volume of the top and bottom speakers independently? Then it should be possible to fix the distortion problems.

In case it helps, here is my asound dump output: https://pastebin.ca/4019558
Comment 136 Benjamin Schmitz 2018-04-29 17:25:32 UTC
(In reply to Benjamin Schmitz from comment #135)

> Do you know how I could configure it, so I can control the volume of the top
> and bottom speakers independently? Then it should be possible to fix the
> distortion problems.

In reply to my own comment:

Connecting PIN [0x17] to "Audio Output [0x03]" allows me to control the volume of the top speakers separately using the "Headphone" volume control in alsamixer. Setting the volume of the top speakers to 50% using this method gives me a very pleasant sounding result.

However, for some reason the connection setting appears to revert automatically from time to time when I pause and resume playback (might be a problem with pulseaudio, or maybe the codec going into power saving mode?). This is very unpleasant because it causes the top speakers to go back to their extremely loud, distorted volume setting. After re-applying the connection setting with hda-analyzer, it works fine again. When it happens, hda-analyzer still claims that the pin is connected to 0x03, but I can not control the volume unless I change the setting to something else and then back to 0x03.

Any ideas why the setting would revert itself, and how I can make it "stick"?
Comment 137 Benjamin Schmitz 2018-04-29 17:31:38 UTC
(In reply to Benjamin Schmitz from comment #136)
> (In reply to Benjamin Schmitz from comment #135)
> 
> When it happens,
> hda-analyzer still claims that the pin is connected to 0x03, but I can not
> control the volume unless I change the setting to something else and then
> back to 0x03.

Sorry for comment spam. I just want to point out that what I said above is incorrect. The pin connection completely reverts to 0x06 after pausing and resuming playback. I can see it by restarting hda-analyzer. Probably hda-analyzer does not refresh the value.
Comment 138 Tom Briden 2018-04-29 18:29:31 UTC
Takashi, Ive moved the coef's into a coef_fw table as you suggested: https://github.com/tombriden/linux/commit/4f6bc5364ed1512fc39be589dba353b15b41621f

Is there anything else I need to do for us to get this (and the previous commit on that branch for mute led) applied into mainline?


Ben, that's weird that it's defaulting to 0x06. I used to have that issue when using the windows vm to enable the speakers but with the patch it's been defaulting to 0x02
Comment 139 Takashi Iwai 2018-04-29 18:43:38 UTC
You can hook ALC295_FIXUP_DISABLE_DAC3 to disable NID 0x06.

Also, I wonder what role GPIO pin does.  Can you figure out?
It's better not to include unnecessary thing, of course.
Comment 140 Tom Briden 2018-04-29 18:54:40 UTC
i'm not sure about the GPIO pin, just figured I should try and get everything as close to how Windows does it as possible. Have removed that now though and it all still works. Also updated to call alc295_fixup_disable_dac3 instead of duplicating the code in there
Comment 141 Benjamin Schmitz 2018-04-29 20:28:52 UTC
(In reply to Takashi Iwai from comment #139)
> You can hook ALC295_FIXUP_DISABLE_DAC3 to disable NID 0x06.

Ah, yes that was the missing piece, thank you. I was using the version of the patch which Tom initially attached to this bug. Now I used this (https://github.com/tombriden/linux/commit/abe94ea0f078b00eef2b0e2565f60822ebf536da).

Now, the former "Headphone" mixer control is named "Bass Speaker" and I can use it to control the volume of the high-pitched top speakers. It not longer reverts when I pause playback. Awesome!

I only have 1 remaining issue: I can not use the volume control in pulseaudio, because touching it will reset the "Bass Speaker" control to 100%, which sounds terrible.

Any ideas? For example, is it possible to "artificially" limit the range of an alsa mixer control? I would set it so that 100% on the "Bass Speaker" control equals actual 50% or 30%.

Or otherwise, tell pulseaudio to keep its fingers off that control...
Comment 142 Oleg Mikheev 2018-04-30 00:04:57 UTC
I can confirm that the patch works now.
After doubting my kernel patching skills for a while it appeared that I had a setting in modprobe alsa options snd_hda_intel model=hp-gpio-led probe_mask=1 that lived there since I last tried to fix this.
Thank you so much for all the hard work!
Comment 143 ibrokemypie 2018-04-30 07:32:25 UTC
https://github.com/tombriden/linux/commit/abe94ea0f078b00eef2b0e2565f60822ebf536da works for me with the speakers (after applying the mute patch first) however the mute led still does not work for me
kernel 4.17 rc3
Comment 144 Maxim Berman 2018-04-30 18:41:37 UTC
Thanks Tom, I'm so happy to have normal sound under linux now ;)

I patched kernel 4.13.0-39-generic under Ubuntu 17.10. Note that I just replaced the whole patch_realtek.c from the one in Tom Briten's fork.

The mute led does not seem to work, but that's a non-issue for me anyway.
Comment 145 Tom Briden 2018-04-30 18:56:28 UTC
Great to hear the sound fix at least is working for everyone so far :) Hopefully Takashi will get the patch into mainline so it can work its way into the different distros. The latest commit on my spectre branch (https://github.com/tombriden/linux/commits/spectre) is for the most recent (force pushed) change (removing unnecessary setting of gpio and using existing function to remove 0x06 from 0x17 selection), the one before it being the mute led fix. 

For those that the mute led still doesn't work for, does it come on at all if you change the VREF dropdown between HIZ and 80 for node 0x1b in hda-analyzer? If not, how about nodes 0x18 or 0x19? They seem to be one's that are used on other hp laptops
Comment 146 Maxim Berman 2018-05-01 14:02:39 UTC
Instead of simply swapping out realtek_patch.c in the older kernel, I now applied the mute and hda commits from Tom Briden's fork in order as commits on kernel 4.15.18 and the mute LED works.

With sound tests I noticed the front left speaker seems louder than the front right speaker though, is anyone else noticing this?
Comment 147 Alejandro Díaz-Caro 2018-05-01 14:08:25 UTC
Created attachment 275689 [details]
attachment-12893-0.html

I couldn't make it work with 4.16.5 (it worked well on 4.16.4). Is it
possible that there is something different on that version?
Comment 148 Connor Kuehl 2018-05-01 14:18:11 UTC
 (In reply to Maxim Berman from comment #146)
> With sound tests I noticed the front left speaker seems louder than the
> front right speaker though, is anyone else noticing this?

Yeah, I noticed the same thing. 

I also don't have the working mute LED. I could have applied the patch wrong. Am I supposed to apply all the patches uploaded here or just the most recent patch?
Comment 149 Tom Briden 2018-05-01 14:36:13 UTC
Rather than uploading new patches here, I've been force-pushing to a github branch: https://github.com/tombriden/linux/commits/spectre

You can download the commits from there as patches by copying the commit link, and adding '.patch' to the end. so for those 2 it's currently:

https://github.com/tombriden/linux/commit/7945cebba5f9185074744bd7d21911e917092735.patch

and

https://github.com/tombriden/linux/commit/062be2abbc5df28e945c479e79786ca25b34db03.patch

Give those a try and let me know if they also have balancing issues. If they do, I'll run the memory dumps again later and check i didn't have some weird volume balance set in my VM.
Comment 150 Maxim Berman 2018-05-01 15:06:31 UTC
I have been using those two commits as patches indeed. The output seems more balanced when I set set Val[1] to 80 while leaving Val[0] to 60 in Node[0x02] AUD_OUT in HDAAnalyzer.
Comment 151 Dario 2018-05-01 15:49:15 UTC
It seems every sub-model of HPSpectrex360 13-xxx, even all being KabyLake, have different bios versions. I'm still running the latest available for my hw: F.15.
I wonder if anyone has tried the patch under this particular version.
Also, is there any guideline on how to apply the patch?
Thanks to all
Comment 152 Maxim Berman 2018-05-01 16:05:10 UTC
Dario, how to apply the patch depends on your distribution. Under ubuntu I followed these guidelines to build the kernel

https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel

and applied the patches to the sources before building with e.g. `patch -p1 < audio.patch`

Ubuntu also maintains newer kernels under http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D

but after trying different kernels I would not recommend 4.16 or 4.17 under ubuntu because the broadcom wifi drivers for these kernels are not shipped (unless you have ubuntu 18.04 already). Also I had trackpad issues with these kernels.

Regarding bios versions, I have F.40, I'm not sure which factors are used by the bios upgrade tool to determine available bios versions for your particular model.
Comment 153 Osip Fatkullin 2018-05-01 16:23:49 UTC
Thanks a lot for working on patch! But I have strange behavior after applying it. 

My environment: HP Spectre x360 13-w013dx with F.45, kernel 4.16.5

What I did: I've applied two patches after all other patches in PKGBUILD

What I get:
1) Mute led working
2) Top speakers working but very strange. When i run `speaker-test -c6` right top is very loud, left top is quiet, bottom are very quiet and can't hear bottom left.
After applying patch I see in pavucontrol, that available "Digital Surround 4.0" instad of "Stereo Duplex". I've switched to it to get controll on channels and fix volume levels, but after that running `speaker-test -c6` works only for Rear Left and Right (and it is top speakers o.o)

There are my coef dumps with: https://gist.github.com/OsipXD/9aab066edf73cd7141333d2a0056f332#file-with-patch-txt and without patch: https://gist.github.com/OsipXD/9aab066edf73cd7141333d2a0056f332#file-without-patch-txt
(idk why with patch 0x17 pin default is 0x411111f0)
Comment 154 Dario 2018-05-01 20:08:29 UTC
Thank you Maxim.

I've checked the latest bios version with HP Support directly, and they confirmed the latest for my particular sub-model is F.15. So I won't try another one, just in case.

I forgot to mention I'm using Ubuntu 18.04, sorry about that. The link you provided gives me a starting point, thanks for that. I wasn't sure actually that a full kernel build would work. So I'm gonna try that.

Which kernel is recommended then? 4.17-rc3 seems to be the latest one


(In reply to Maxim Berman from comment #152)
> Dario, how to apply the patch depends on your distribution. Under ubuntu I
> followed these guidelines to build the kernel
> 
> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
> 
> and applied the patches to the sources before building with e.g. `patch -p1
> < audio.patch`
> 
> Ubuntu also maintains newer kernels under
> http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D
> 
> but after trying different kernels I would not recommend 4.16 or 4.17 under
> ubuntu because the broadcom wifi drivers for these kernels are not shipped
> (unless you have ubuntu 18.04 already). Also I had trackpad issues with
> these kernels.
> 
> Regarding bios versions, I have F.40, I'm not sure which factors are used by
> the bios upgrade tool to determine available bios versions for your
> particular model.
Comment 155 Maxim Berman 2018-05-01 20:42:18 UTC
(In reply to Dario from comment #154)
You could probably stick to 4.15 as it is the default kernel for ubuntu 18.04

(general)
I compiled again with the original patch proposed by Tom Briden and attached in this thread, with ~5000 verbs in the array, instead of using the latest commit in the fork. This works better, I don't have this left/right imbalance issue anymore. I think the SET_COEF_INDEX / GET_PROC_COEF verbs must have an impact.

Incidentally, I think I used that full patch the first time I tried, and also why I hadn't realized the imbalanced then.
Comment 156 Takashi Iwai 2018-05-17 06:31:33 UTC
Tom, could you brush up your patches and submit formally to ML?
At least you need to put your signed-off-by line.  Otherwise we can't merge it from legal reasons.

Also, I'll ping Kailang at Realtek to take a look at the large COEF things.
Comment 157 Tom Briden 2018-05-19 11:27:47 UTC
Thanks Takashi, given the volume of coefs that are being set, do you think it would be better to initialise the array in a header file that's included in patch_realtek?

The number is actually now up to 4000 coefs. I found while trying to work out why the sound seemed to be off balance, that the write pointer offset for the command buffer doesn't always increment by 1 so dumping the memory whenever the offset was 255 was actually missing a bunch of commands for when the offset went from 254 back to 0, etc. Also, there are coefs written to a different nid than 0x20 which seems to give it some extra bass. 
I can apply these from a userspace app with ioctl and it works great but for some reason having that many in the coef_fw array results in all coefs being unset after boot.
The full list of coefs that doesn't apply properly on boot, is here https://github.com/tombriden/linux/commit/db060473adfac0f659750cab800d80f398eed3b1
Comment 158 Tom Briden 2018-05-19 15:03:44 UTC
Ignore previous comment about the coefs not applying when done in the kernel, I'd output the array completely wrong! Can someone please compile this branch (or apply latest two commits to your current version) and let me know if you think it sounds better

https://github.com/tombriden/linux/commits/all_coefs
Comment 159 Ryan Hanlon 2018-05-19 17:08:08 UTC
(In reply to Tom Briden from comment #158)
> Ignore previous comment about the coefs not applying when done in the
> kernel, I'd output the array completely wrong! Can someone please compile
> this branch (or apply latest two commits to your current version) and let me
> know if you think it sounds better
> 
> https://github.com/tombriden/linux/commits/all_coefs

Yes the latest two commits are working for me. I have the 13-ac0xx, bios F.45
Comment 160 Benjamin Schmitz 2018-05-19 21:59:20 UTC
I also tried the latest patches. My model is 13-w003ng and bios F.34.

These are my findings:

+ Sound quality is now very good, even at maximum volume. No more distortion.
+ The maximum volume is now really loud (with unpatched stock kernel it is very quiet)
+ Mute LED is working
- Headphone jack does not output anything. It detects that something was plugged in and turns of the speakers, but there is no sound on the headphones. 
- during startup there are some faint popping noises and the mute led flashes a couple of times
- Some time after boot (I already reached my desktop) my system led out a pretty loud, very high-pitched beep. It was a very unpleasant, startling sound. Only lasted a split second, though.

Overall, awesome job! The speakers now work perfectly. I didn't expect the headphone jack to work anyway. The only unsettling thing is that annoying beep. I will check if that comes back on every boot.
Comment 161 Julien Langlois 2018-05-19 22:53:42 UTC
I can report the same as Benjamin Schmitz on a 13-w063nr with bios F.45.
Comment 162 Julien Langlois 2018-05-19 23:28:36 UTC
(Meaning all points except the beep)
Comment 163 Tom Briden 2018-05-20 15:21:46 UTC
Ben, did you experience that beep again? I can't say it's something I've noticed, but I have had those faint pops on boot. 
I'm assuming from your comment that the headphone jack has never worked for you, and the patch just hasn't changed that? 
I want to get the patch submitted, so assuming that beep isn't a consistent thing I'll send it tonight or tomorrow
Comment 164 Benjamin Schmitz 2018-05-20 15:29:38 UTC
(In reply to Tom Briden from comment #163)
> Ben, did you experience that beep again? I can't say it's something I've
> noticed, but I have had those faint pops on boot. 

No, so far it has not happened again. I did a couple of reboots without any problems. I suspect that I did an unclean reboot from stock kernel (i.e. without power cycling) when it happened.

> I'm assuming from your comment that the headphone jack has never worked for
> you, and the patch just hasn't changed that? 

Yes, that is correct.
Comment 165 Oleg Mikheev 2018-05-20 16:21:39 UTC
Created attachment 276073 [details]
attachment-27196-0.html

If this patch is submitted would that mean there's no chance for headphones to start working?
I had them working before the patch, with that kernel parameter.

On May 20, 2018 11:29:38 AM EDT, bugzilla-daemon@bugzilla.kernel.org wrote:
>https://bugzilla.kernel.org/show_bug.cgi?id=189331
>
>--- Comment #164 from Benjamin Schmitz (vortex@wolpzone.de) ---
>(In reply to Tom Briden from comment #163)
>> Ben, did you experience that beep again? I can't say it's something
>I've
>> noticed, but I have had those faint pops on boot. 
>
>No, so far it has not happened again. I did a couple of reboots without
>any
>problems. I suspect that I did an unclean reboot from stock kernel
>(i.e.
>without power cycling) when it happened.
>
>> I'm assuming from your comment that the headphone jack has never
>worked for
>> you, and the patch just hasn't changed that? 
>
>Yes, that is correct.
>
>-- 
>You are receiving this mail because:
>You reported the bug.
Comment 166 Tom Briden 2018-05-20 16:24:50 UTC
What was the kernel parameter you had that made them work? There's definitely a way to get them working, if I put every command sent from the Windows driver into the kernel, they work fine but I doubt that would be accepted as a patch so I need to try and get just the minimum required verbs/coefs in.
Comment 167 Ryan Hanlon 2018-05-20 17:17:52 UTC
I can confirm that my headphones did work be for the latest patches. Now i get i quiet static from the headphone jack. I'm not sure if it's applicable but, i did need to apply a workaround for the snap crackle and pop's from headphones before.

hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000

also it the 13-ac033dx not 13-ac0xx
Comment 168 Oleg Mikheev 2018-05-21 05:13:36 UTC
headphones worked with vanilla kernel and these module parameters:

snd_hda_intel model=hp-gpio-led probe_mask=1

but the way they worked was not actually tolerable - there was static noise when volume was above the middle
Comment 169 Tom Briden 2018-05-21 09:39:29 UTC
ugh, fix one thing break another. I can get sound from the top speakers or a perfectly working headphone jack, but yet to be able to have both! May have to wait til next weekend to do any more digging into this
Comment 170 Frans Skarman 2018-05-21 15:29:08 UTC
I also experience the poping sounds with the patch applied, I haven't heard a beep though.

Nice to also see the headphone issue being worked on, if you can't come up with a fix for both, would it be possible to make a separate patch for the headphone jack for people like me who use headphones more often than speakers?
Comment 171 Tom Briden 2018-05-22 17:10:47 UTC
Have just force pushed to the all_coefs branch (re-based on 4.17-rc6) with working speakers and headphones! The coefs being set on nids 0x58 and 0x5b were the culprit so I've just removed them all. Apart from the pops on boot (which I think we can live with?), I think we're all good. If a couple of people can confirm, I'll get the patches submitted.

https://github.com/tombriden/linux/commits/all_coefs
Comment 172 Benjamin Schmitz 2018-05-22 19:39:17 UTC
(In reply to Tom Briden from comment #171)

No change for me with the latest patch. Meaning speakers are still working perfectly but headphone jack is completely dead. Headphone jack never worked for me.
Comment 173 Julien Langlois 2018-05-22 20:04:11 UTC
Would the model of headphone make a difference? E.g. Apple headphones use AHJ pinout... I don't know if switching between standards happens at a lower level than the Intel hda chipset? I haven't had a chance to try out the newest patches yet, but I will asap.
Comment 174 Ryan Hanlon 2018-05-23 00:19:01 UTC
I have not noticed any change with the headphones, still the same quite hiss. But the front/top speakers work great.
Comment 175 Oleg Mikheev 2018-05-23 02:44:47 UTC
same, speakers work beautifully, headphones don't, tried everything in hda analyzer
Comment 176 Julien Langlois 2018-05-23 03:06:30 UTC
I'm compiling now... Does it make sense to say what model of headphones we're all using? Would TRRS (https://en.wikipedia.org/wiki/Phone_connector_(audio)#TRRS_standards) make a difference here?
Comment 177 Julien Langlois 2018-05-23 04:06:57 UTC
I just get slight static or no noise from a variety of headphones, so my previous comment doesn't make any sense.
Comment 178 Tom Briden 2018-05-23 17:32:59 UTC
Not sure what I can do on this now unfortunately. If I compile completely vanilla kernel, headphones work perfectly but speakers do not. With the patch I posted on Saturday, the top speakers work but headphones don't. 

To debug, I just applied the 0x17 pin config change to kernel and applied coefs using hda-verb. Top speakers would come on as they ran through. With headphones in, they'd work and then turn off while running through the same coefs. From there I narrowed it down to those nids I mentioned and now I consistently have both working from a cold boot.

So, if the headphones work for you on a stock kernel then they _should_ work with the latest patches. I'm using standard earbuds, no mic and my model is 13-ac004na. Can those that have had hp working double check you're using the right patch (make sure there are no lines in sound/pci/hda/hp_x360_helper.c that start 'WRITE_COEFEX(0x58' and remove any module params that you may have been using before to fix them?
Comment 179 Frans Skarman 2018-05-25 11:25:49 UTC
I just heard the high pitch noise that was discussed a while back using the kernel from 2018-05-01
Comment 180 Julien Langlois 2018-05-28 02:49:31 UTC
I just heard the high pitch noise as well. Is happened after resuming from suspend.
Comment 181 Takashi Iwai 2018-05-29 09:42:06 UTC
Kailang provided the full verbs that was extracted from BIOS setup, and cooked up to be applicable on top of Tom's tree.

Could you guys try to replace sound/pci/hda/hp_x360_helper.c with the attached one below, and test whether it works better?

Meanwhile, I'll submit and apply the mute LED patch beforehand (with another patch for code refactoring, too).
Comment 182 Takashi Iwai 2018-05-29 09:50:55 UTC
Created attachment 276251 [details]
Replacement of hp_x360_helper.c
Comment 183 Tom Briden 2018-05-29 16:26:40 UTC
Yep, that replacement is working for me; top speakers enabled, booting is 'pop' free and headphones are working fine too. Wish we could have had that info a year ago! :) I've force pushed to my master branch for anyone compiling from there.

One thing I did notice though, that I've mentioned before, is that coefs sent on a different nid do something to change the sound (maybe its used by the b&o audio control for the 'b & o experience' setting?)
Anyway, now we have the correct coefs for these speakers on 0x20, I've narrowed that one down to a single coef. To see what I mean, once you're running the latest patch, run these commands with some audio playing and let me know if you think it improves the sound:

sudo hda-verb /dev/snd/hwC0D0 0x53 0x500 0x00 && sudo hda-verb /dev/snd/hwC0D0 0x53 0x4c0 0x6a


Thanks Takashi and Kailang!
Comment 184 Takashi Iwai 2018-05-29 19:34:26 UTC
OK, I'm going to submit & merge the speaker patch, too.

The 0x53 COEFs can be tweaked later, if any.
Comment 185 Alejandro Díaz-Caro 2018-05-29 21:14:52 UTC
I confirm that the last version of Tom branch works perfectly for me in my 13t-ac0000 model.
I couldn't test the command, though, because I cannot install hda-verb since it seems that suse ftp is down.
In any case, great job! Many thanks.
Comment 186 Alejandro Díaz-Caro 2018-05-29 21:23:52 UTC
Ok, I got the program from here https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1254745/+attachment/3921477/+files/hda-verb-0.4.tar.gz

I confirm, the sound seems better after these commands.

In any case, I had to apply them to /dev/snd/hwC1D0 since hwC0D0 does not exists.
Comment 187 Julien Langlois 2018-05-30 05:29:34 UTC
I can also confirm that the sound improves after setting the the above verbs.
Comment 188 Julien Langlois 2018-05-30 05:30:47 UTC
Also no more popping. However headphones still don't work.
Comment 189 Osip Fatkullin 2018-05-30 06:44:32 UTC
Created attachment 276265 [details]
attachment-19470-0.html

Sound from speakers is perfect now.
But headphones not worķs on 13-w013dx.
I had it worked on first archlinux install, but after reinstallation it
never work

ср, 30 мая 2018, 8:30 <bugzilla-daemon@bugzilla.kernel.org>:

> https://bugzilla.kernel.org/show_bug.cgi?id=189331
>
> --- Comment #188 from Julien Langlois (LANGLOIS.JF@GMAIL.COM) ---
> Also no more popping. However headphones still don't work.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 190 ibrokemypie 2018-06-04 14:53:29 UTC
Everything seems to be working fine for me, whats left to do before this can be mainlined?
Comment 191 Sean 2018-06-04 17:36:15 UTC
Compiled from Tom's branch - top speakers and headphones working great.

Model 13-ac033dx

Thank you!
Comment 192 Vivek 2018-06-17 21:29:05 UTC
I am new at this, sorry i am asking very basic question. could someone please help me how can i apply this patches ?
i am facing same issue in my laptop hp 360 no Bang and OLufsen/headphone sound .
Comment 193 Lev McKinney 2018-06-18 21:40:29 UTC
(In reply to Vivek from comment #192)
> I am new at this, sorry i am asking very basic question. could someone
> please help me how can i apply this patches ?
> i am facing same issue in my laptop hp 360 no Bang and OLufsen/headphone
> sound .

Also quite new to this side of Linux and have been doing my best to solve this issue. The patch has been added to the newest version of the kernel: https://github.com/torvalds/linux/commit/126f7051b4daa3716d9af2851dcb55316e4c2b25

You can get it from kernel.org anything newer than 4.18-rc1 should have the patch.

If you are running arch here is a nice guide on how to build the kernel : https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation

One big caveat here even with the kernel patch I still have the issue. It may be a compounding problem with pulse audio but I'm pretty much in the dark to. :C
Comment 194 Frans Skarman 2018-06-18 21:52:36 UTC
(In reply to Vivek from comment #192)
> I am new at this, sorry i am asking very basic question. could someone
> please help me how can i apply this patches ?
> i am facing same issue in my laptop hp 360 no Bang and OLufsen/headphone
> sound .

As far as I understand this patch only fixes the top speakers but not the headphone problem.
Comment 195 Sean 2018-06-19 00:21:33 UTC
(In reply to Frans Skarman from comment #194)
> (In reply to Vivek from comment #192)
> > I am new at this, sorry i am asking very basic question. could someone
> > please help me how can i apply this patches ?
> > i am facing same issue in my laptop hp 360 no Bang and OLufsen/headphone
> > sound .
> 
> As far as I understand this patch only fixes the top speakers but not the
> headphone problem.

This fixed both headphones and top speakers for me.
Comment 196 Frans Skarman 2018-06-19 11:59:52 UTC
I just tested it by installing aur/linux-git which gave me kernel x86_64 Linux 4.18.0-rc1-gba4dbdedd3ed. The top speakers and mute LED work but headphones do not.

This is with a 13-w003 which has never had working headphones under linux.
Comment 197 Robert 2018-06-19 21:55:25 UTC
it works here as well on 13-w023dx.
Headphones were working before as well.
speakers and mute led working with the 4.18-rc1

great work! thank you!!
Comment 198 Vivek Roy 2018-07-01 14:24:07 UTC
I am sorry, I am on Ubuntu and my model is ae012dx. I tried both 4.18-rc1 and 4.18-rc2 from http://kernel.ubuntu.com/~kernel-ppa/mainline/ but none of them seem to fix the top speakers or the mute LED. Can anyone help me? Thank you.
Comment 199 tacchinotech 2018-07-03 08:45:45 UTC
Hi, thanks for your support. I have a HP ENVY 13-ad102nl and this computer has the same exact issues as the Spectre x360. I tried to install Manjaro using the latest available kernel (4.18rc1 and 4.18rc2) but this did not lead to any solution. My question is: can these patches also be used on a computer other than a Specter?
Comment 200 Francesco Cuius Iuculano 2018-07-03 10:40:55 UTC
Hello, I am on 13-w0XX.
First of all, thanks for your hard work.

I installed 4.18rc1, 4.18rc2 and Tom Briden's github fork on Arch, but none of them has working top speakers, they only fix the mute led.

As for the headphones, I had them working at first. They stopped working when I updated the BIOS from F.10 to F.45. I cannot check if this has been the real cause or just a coincidence, but it might worth to have a look at that.

Finally (I am not sure if this is related to our problem, though), I noticed that since kernel 4.17 the volume buttons don't work when the screen is flipped to tablet mode, while they still work fine on the LTS kernel
Comment 201 Francesco Cuius Iuculano 2018-07-03 10:46:14 UTC
Forgot to mention that the top speakers worked with the original patch by Tom Briden, the one with the crackling noise at boot, which is currently the only that works for me.
Comment 202 uzivatelmp 2018-07-20 14:37:10 UTC
Created attachment 277445 [details]
lspci -nnv on ae-012nc (mute LED and top speakers not working, different PCI id)
Comment 203 uzivatelmp 2018-07-20 14:40:56 UTC
Created attachment 277447 [details]
alsa-info on ae-012nc (mute LED and top speakers not working, different PCI id)
Comment 204 tacchinotech 2018-07-20 15:33:39 UTC
Created attachment 277449 [details]
alsa-info hp_envy_ad102nl

I think to have a similar problem of uzivatelmp but with a hp envy ad102nl.

Furthermore (lspci ad102nl):

00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21) (prog-if 80)
	Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio [103c:83a9]
	Flags: bus master, fast devsel, latency 32, IRQ 139
	Memory at a4328000 (64-bit, non-prefetchable) [size=16K]
	Memory at a4300000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl
Comment 205 uzivatelmp 2018-07-20 16:37:48 UTC
I modified the PCI ID in the upstreamed patch in hope that it will fix the problem. It didn't fix the top speakers, but the mute LED started working.

I then grabbed the libvirt definition that Robert posted in https://bugzilla.kernel.org/show_bug.cgi?id=189331#c88 and booted a Windows 10 VM with the B&O drivers and all four speakers worked there. I disabled the device in Windows and shut down the VM gracefully, but I still didn't get all four speakers in Linux. Pavucontrol however displayed new 4.0 Surround Output, but all of the channels controlled the bottom speakers.

I could maybe do the vfio tracing which Tom Briden did in https://bugzilla.kernel.org/show_bug.cgi?id=189331#c110. But I don't have the knowledge to convert the dumps to verbs.
Comment 206 uzivatelmp 2018-07-20 16:45:00 UTC
Created attachment 277451 [details]
alsa-info on ae012nc after W10 VM

Booted a W10 VM, tested sound -> all speakers working
Disabled the HDA codec in Device Manager
Shutted Down gracefully
Comment 207 Ryan Laird 2018-08-22 06:27:20 UTC
Hi all, 

I had the same issue on my HP Envy 13T-Y000 x360 (headphones worked, but no speaker functionality. All audio worked fine in windows, but not Ubuntu)
 System:
   - Ubuntu 18.04.1 LTS (64-bit)
   - Kraby Lake GT2
   - Linux v4.15.3 (generic)

I installed Linux 4.18.3 as my new kernal and now have full audio!
Comment 208 Vivek Roy 2018-08-22 07:52:14 UTC
HP-spectre x360-13-ae0xx
Tried with kernel 4.18.3 on arch linux. No use.

I don't know much about all these but here is lspci, it shows two memory addresses (though one of them is dcc00000) -

00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio [8086:9d71] (rev 21) (prog-if 80)
        Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio [103c:83b9]
        Flags: bus master, fast devsel, latency 32, IRQ 148
        Memory at dcc28000 (64-bit, non-prefetchable) [size=16K]
        Memory at dcc00000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: [50] Power Management version 3
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel, snd_soc_skl

Alsa-info shows soundcard at one address -

!!Soundcards recognised by ALSA
!!-----------------------------

0 [PCH            ]: HDA-Intel - HDA Intel PCH
                     HDA Intel PCH at 0xdcc28000 irq 148


But I think if it was so simple, people would have figured it out long back :P
Comment 209 Vivek Roy 2018-08-22 08:05:09 UTC
I just tried:

speaker-test -c 4 


The top(rear) speakers do produce output but way-way lower volume than the bottom(front) speakers. I do not know how to adjust their volume. alsa-mixer and pulsemixer don't seem to have any knobs that I can turn up.
Comment 210 Vivek Roy 2018-08-22 08:07:46 UTC
Okay. Turns out that the low volume that is coming when speaker-test says Rear left and Rear right are coming from the front(bottom) speakers only and not the rear(top) speakers.

The top speakers are still not working at all.
Comment 211 Takashi Iwai 2018-08-22 08:12:14 UTC
(In reply to Vivek Roy from comment #208)
> 00:1f.3 Audio device [0403]: Intel Corporation Sunrise Point-LP HD Audio
> [8086:9d71] (rev 21) (prog-if 80)
>         Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio
> [103c:83b9]

This one is known to be incompatible with the already-fixed x360 model, and unfortunately, no workaround is found.  Blame HP.
Comment 212 Holger Dehnhardt 2018-08-24 17:13:26 UTC
Hi, I own an HP Spectre x360 13-ae002ng too - and of course have the same problem.
Is there anything I can do to help sorting this out? (I fear that blaming HP will not help too much;-)
Comment 213 uzivatelmp 2018-08-25 11:38:52 UTC
Hi, I was working together with Tom Briden (thanks!) to try and repeat his steps. I successfully dumped the CORB buffer, but when I tried to replay the COEFFs using hda-verb, it didn't work. The next step is to try and replay all the commands, in case there is something else to it (different pin cfgs etc.)
Comment 214 Giuseppe 2018-08-30 11:58:42 UTC
Hi, 
I didn't read all the comment.
My situation :
Yesterday on Manjaro with KDE and kernel 4.14.66-1, my left speaker doesn't worked at all.
I booted to Windows, and same behaviour.
So I installed bios v37 from HP, I just reinstalled the bios to the same v37. v37 was already installed.

I think it's a bios problem.

hp spectre 15-BL112DX.

I can help to test if needed.
Comment 215 Holger Dehnhardt 2018-08-31 17:20:36 UTC
@uzivateImp: 
I have tried to extract the settings with hda-converter and add these settings with hda-verb. Is this the same what you mean with COEFS? Otherwise can you send the coefs to this forum? What did not work in replaying them with hda-verb? 
Holger
Comment 216 Holger Dehnhardt 2018-08-31 17:23:39 UTC
Created attachment 278217 [details]
Pinconfig extracted in Windows
Comment 217 Mar Ses 2018-09-08 12:56:44 UTC
I have a 13t-w090nz (i7,16G,1TB) and my headphones and top speakers weren't working. I upgraded my kernel to 4.18.6-041806-generic, which should include this patch right? However, the top speakers still don't work. When testing Sound in the Ubuntu Settings, I only have the option to test the front two, the top speakers don't appear.

test-speaker also didn't produce sound in the top speakers.
Comment 218 Holger Dehnhardt 2018-09-15 07:11:00 UTC
@Mar_Ses: The fix works only for some models.

@Takashi and Kailang: Can I "extract the full verbs from BIOS" by myself? I really would love to at least get the headphones enabled. (13-ae002ng)

@all: For the models where the patch works: Does speakertest is able to address each of the four speakers individually? Do we have a list of models which are known to work with the patches?

Thanks Holger
Comment 219 Mayank Sharma 2018-09-22 08:06:16 UTC
I am also having the same issue, that neither the mute LED works nor the rear speakers. 

I have a laptop from an entirely different line, i.e. AU series of laptops, but these also use the same B&O Speakers. Headphone jack works flawlessly (initially it had some cracking in left speaker but it was patched and is now in mainline kernel). I am trying to get this fixed for the whole AU series (it was a budget line, and was quite successful in India) since all of them use the same board and have similar specs.

I have been able to emulate windows 10 inside qemu and get the rear speakers working using PCI passthrough.  

I can also confirm that setting VREF in hda-analyzer for pin 0x1b to 50, 80 and 100 causes the mute LED to work (but it just keeps turned on; doesn't turn on/off upon muting). 

Further, I'm absolutely new to these things and trying to understand the basics. I don't know how to dump the verbs (is it the same as running alsa-info.sh? :-? )

@Takashi @Tom Briden Can you please guide us or give us some reading material to understand how it all works? 

Thanks in advance. :)
Comment 220 Holger Dehnhardt 2018-09-24 07:43:31 UTC
Hi Mayank,
it's nice that someone else is still taking care of this threads. There is a detailed description from Intel for the hda standard: https://www.intel.de/content/www/de/de/standards/high-definition-audio-specification.html
But the document is very long. So I wanted to see if the HDA verbs can be read somehow under Windows to compare them. The only program I found is PinConfigOverride. My A-B comparisons (without mute button, with mute button, without headphones, with headphones) didn't show any difference. Obviously these really are read only override values - values that are not changed dynamically. Now I'm at a loss again. Let's see if there is a hint in the documentation how to read out all HDA values under Windoes. Actually this should be possible.
Holger
Comment 221 Michal Raska 2018-09-26 17:19:02 UTC
I have same problem with HP Spectre 13 x360 ae0xx kernel 4.15.5. 

Audio codec is Realtek ALC 265. Its compatible with ALC225. I didn't found any information about ALC225, but I found schematic diagram of motherboard with ALC295 used in Acer Spin3. In this laptop is secondary codec? ALC1006 and it is used for subwoofer. In final product this amplifier is not used. This combination is maybe used in Spectre and ALC1006 used for speaker under LCD.   

Interface for ALC1006 is I2S, and connected to ALC295. Searching for datasheet ALC295 and ALC1006 failed. Similar combination is used in Huawei MatebookPro (ALC298/ALC1006).

I don't know if ALC1006 need initialization from driver or if this procedure is done from ALC295.
Comment 222 Mayank Sharma 2018-09-28 10:47:40 UTC
(In reply to Holger Dehnhardt from comment #220)
> Hi Mayank,
> it's nice that someone else is still taking care of this threads. There is a
> detailed description from Intel for the hda standard:
> https://www.intel.de/content/www/de/de/standards/high-definition-audio-
> specification.html
> But the document is very long. So I wanted to see if the HDA verbs can be
> read somehow under Windows to compare them. The only program I found is
> PinConfigOverride. My A-B comparisons (without mute button, with mute
> button, without headphones, with headphones) didn't show any difference.
> Obviously these really are read only override values - values that are not
> changed dynamically. Now I'm at a loss again. Let's see if there is a hint
> in the documentation how to read out all HDA values under Windoes. Actually
> this should be possible.
> Holger

So, I went through the whole thread once again and realized that comment 110 was the breakthrough step in finding the right hda-verbs. The ones which are in kernel 4.19.0-rc4, specifically for the x360 model don't work for me (How do I check if the patch is working or not?). I tried to get my head through Tom Briden's comment 110 but I couldn't understand much from it, especially the part about getting vfio_region_write traces from qemu. 

The output of lspci -v, specifically the Audio Device part is:
```
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
	Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio
	Flags: bus master, fast devsel, latency 32, IRQ 133
	Memory at b4328000 (64-bit, non-prefetchable) [size=16K]
	Memory at b4310000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 3
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel, snd_soc_skl
```

I also ran PinConfigOverride and retrieved hda-verbs. There were 4 files, PinConfigOverride001-004.txt, and looking at them, files 1 and 3 were exactly same and so were 2 and 4. I combined them and they're attached. 

https://gist.github.com/mayanksha/fa215be6b59bcb0cd43bd36520e02f8c
Comment 223 Holger Dehnhardt 2018-09-28 10:55:23 UTC
I think, the override values are not enough. We need all hda verbs. I already installed Visual Studio on my Windows system (have a dual boot) an will try - when there is time - to read out all hda verbs from windows. I hope!!! there is a way to do it with the windows api - but it will take time. It's about 20 years that I wrote my last Windows app.
Comment 224 Antoine 2018-09-30 06:21:26 UTC
Hi, 

I encounter the same bug on my HP Envy 13 Ad106nf: only two of the speakers work. The sound is high-pitched and therefore of poor quality compared to the warm and bass-rich sound of the speakers on Windows. 
Also, the mute button led does not work out of the box. 
I'm on kernel 4.18.10-arch1-1-ARCH. I did not update my bios by the way. 

I am interested in any hints to solve that issue.
Comment 225 John LF 2018-10-03 15:47:31 UTC
Headphone jack still not working on model x360 w063nr. I've tested with kernel version 4.18

But I'm glad to see so much progress made over the past few months. Hopefully this will be fixed for all models.
Comment 226 Mayank Sharma 2018-10-20 07:12:55 UTC
@Holger Did you make any progress with dumping the hda-verbs?
Comment 227 Bill Gribble 2018-10-20 20:37:57 UTC
I've been following this ticket for years and I'm sad to report that my x360 (machine info waaay up in comment 23) is still only producing audio out of two speakers and never headphones.  I'm currently on Debian's 4.18.10-2 package. 

FWIW the mute LED does work!
Comment 228 Holger Dehnhardt 2018-10-20 20:57:48 UTC
@Mayank: I started and immediately became frustrated by the Windows API. Somehow nothing works as expected and when I google then some macro call is missing which is not mentioned in the Windows documentation...
Anyway, I'm at least ready to display the device (or the device driver). Next I need a handle on it, but I've failed so far.
If anyone wants to deal with it Please, please, please:-), I can publish the code. (
Comment 229 Tom Briden 2018-10-24 15:54:59 UTC
@Holger, you may not get far reading the verbs out in Windows as you'll only get the final values once the speakers are enabled. On my x360, it requires a specific sequence of coeff's to be set to bring the speakers to life, often changing the same coef index over and over; to get these involved dumping the command output ring buffer (CORB) every time the buffer index hit the max value before looping back to 0.
I've had some time recently to recreate my steps for getting the CORB buffers dumped and made some slightly more detailed instructions. Hopefully these can help someone make some progress with the other variants that aren't working. 

Some pre-requisites:

kernel built with: CONFIG_DEVMEM=y
kernel boot param: trace_event=iommu
qemu installed with debugging symbols


Disable mmap in the vm (win10 is the name of my VM, modify to match your own):

$ virsh
$ edit win10

add qemu namespace to domain element: xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0', eg

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>


Then add following before closing tag '</domain>'

<qemu:commandline>                         
  <qemu:arg value='-set'/>
  <qemu:arg value='device.hostdev2.x-no-mmap=on'/>
</qemu:commandline>


In win vm, disable audio device in device manager, reboot

find memory address for the soundcard

$ lspci -v

On mine it's: Memory at dc228000 (64-bit, non-prefetchable) [size=16K]:


Get the VM address of the CORB (replacing dc228000 with your address found above) into a variable:

$ CORB=$(sudo dd status=none if=/dev/mem bs=1 count=4 skip=$((16#dc228000 + 16#0040))|hexdump -v -e '"%08_ax: "' -e ' 4/4 "%08x " " \n"' |cut -d' ' -f2)


Now get the physical address that it maps to

$ sudo grep ' map' /sys/kernel/debug/tracing/trace|awk '{ print $8, $9, $10}'|while read line; do eval $line; if [ -n $iova ] && [ $((16#${iova/0x})) -lt $((16#$CORB)) ] && [ $(( $((16#${iova/0x})) + $size )) -gt $((16#$CORB)) ]; then printf "%0x\n" $(( $(( $((16#$CORB)) - $((16#${iova/0x})) )) + $((16#${paddr/0x})) )); fi; done|tail -1


hook into the running qemu process with

$ sudo cgdb -p $(pgrep qemu-system-x86 )


#init some values
gdb>set $prev=0
gdb>set $dumpnum=1

#increase the dumpnum ever time we loop round
gdb>break hw/vfio/common.c:130 if (addr==72) && data<$prev && data<=255
gdb>commands
>set $dumpnum=$dumpnum+1
>set $prev=data
>cont
>end


#(re-)dump every time data >250 to catch all possible max 'data' values before looping round (the final value before rolling back isn't consistent)
# ** Change $ADDR below to the output of the physical CORB address found above

gdb>break hw/vfio/common.c:130 if (addr==72) && (data>250) && data<=255
gdb>commands
>eval "shell sudo dd status=none if=/dev/mem bs=1 count=1k skip=$((16#$ADDR))
>of=corb-%02d", $dumpnum
>set $prev=data
>cont
>end
gdb>continue

Enable sound card in vm device manager, wait a few seconds until output stops in gdb terminal


press ctrl+c in gdb to get to a prompt, then grab the final dump 
(assuming current data isn't 255, this will contain part of the previous dump too)

gdb>eval "shell sudo dd status=none if=/dev/mem bs=1 count=1k skip=$((16#$ADDR)) of=corb-%02d", $dumpnum
gdb>exit

you should now have a bunch of corb files in your current directory. On a clean boot with the soundcard disabled, i had 49 after enabling in device manager. If anyone gets this far we can try extracting the coef sets and turning them into hda-verb commands
Comment 230 Holger Dehnhardt 2018-10-25 19:32:04 UTC
Thank you for your explanation, @Tom!

"you may not get far reading the verbs out in Windows as you'll only get the final values once the speakers are enabled. On my x360, it requires a specific sequence of coeff's to be set to bring the speakers to life, often changing the same coef index over and over; to get these involved dumping the command output ring buffer (CORB) every time the buffer index hit the max value before looping back to 0."

This is really bad! But ok, then I can stop my effords in reading the verbs.

I hope I will have time at the end of next week to try your suggested workflow. As I have a dual boot, I first have to create a Windows VM...

Hopefully I will come back with some results than.

Holger
Comment 231 Matthijs 2018-11-14 08:42:02 UTC
This might also help as it seems to be the similar as to what Tom did:

https://jcs.org/2018/11/12/vfio
Comment 232 Mayank Sharma 2018-11-14 09:43:28 UTC
@Tom Thanks a lot man! I was really scratching my head trying to grasp what you had mentioned in comment #110. This information gives a completely new direction to solving this.   

@Holger I will try whatever Tom mentioned in some days and get back those corb files. Hopefully, we can have something substantial in our hands by the first week of next month.  

@Matthijs Thanks. That's a valuable piece of information. :)
Comment 233 uzivatelmp 2018-11-16 13:42:29 UTC
Hi,

Spectre x360 13 ae012nc

I tried the steps from https://jcs.org/2018/11/12/vfio, but the log I got from it contained only lines like this:

CORBWP advance to 187, last WP 186
CORB[187] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0x0 (ex 0x0)
CORBWP advance to 188, last WP 187
CORB[188] = 0x0 (caddr:0x0 nid:0x0 control:0x0 param:0x0)
CORB caddr:0x0 nid:0x0 control:0x0 param:0x0 response:0x0 (ex 0x0)

After that, I tried the steps outlined in comment #229 and got the 7 attached dumps.
Comment 234 uzivatelmp 2018-11-16 13:43:49 UTC
Created attachment 279473 [details]
Dumps from Spectre x360 13" ae012nc
Comment 235 Holger Dehnhardt 2018-11-17 12:05:59 UTC
@uvivatelmp: Thank you for your effords!
@tom: I have tried to convert the output as described in Comment 31 but this does not seem to be enough. When using hda-ver to apply the results I got a lot of errors (mostly invalid nid) Can you give us a hint on how to convert the CORB buffer files?

Here my convert-script:

----
#!/bin/bash
FILES=$(ls corb*)

echo "#!/bin/bash" > verbs.sh

for FILE in $FILES
do
        echo $FILE
        hexdump  -v  -e '3/1 "%02X" /1 "%02X\n"' $FILE | awk -v FIELDWIDTHS="3 3 2" '{print "hda-verb /dev/snd/hwC0D0 0x"$1 " 0x" $2 " 0x" $3}' >> verbs.sh
        #hexdump  -v  -e '/1 "hda-verb /dev/snd/hwC0D0 0x%0.02x" 2/1 "%0.02x" /1 " 0x%0.02x" 2/1 "%0.02x" /1 " 0x%0.02x" /1 "%0.02x\n"' $FILE >> verbs.sh
done
----
Comment 236 David 2018-11-23 22:38:14 UTC
I haven't been following this thread very closely, but I just wanted to report that I just updated to 4.19.2 on my 13-ac023dx and my top speakers are now working! Thanks to @tom and everyone else who has helped work on this.
Comment 237 Oleg Mikheev 2018-11-24 23:17:26 UTC
Do headphones work for you?

On 11/23/2018 05:38 PM, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=189331
> 
> --- Comment #236 from David (davidl2381@gmail.com) ---
> I haven't been following this thread very closely, but I just wanted to
> report
> that I just updated to 4.19.2 on my 13-ac023dx and my top speakers are now
> working! Thanks to @tom and everyone else who has helped work on this.
>
Comment 238 Gagandeep Arora 2018-11-24 23:29:51 UTC
Headphones work for me and they were working before as well. However, top speakers do not work for me even after the recent kernel update to 4.19.3-300.fc29.x86_64. Product Name: HP Spectre x360 Convertible 13-ae0xx.
Comment 239 M. Emre Aydin 2018-11-27 14:55:20 UTC
HP Spectre x360 Convertible 13-ae0xx (2LU95UAR#ABA)

4.19.4-1-MANJARO

Top speakers don't work. No problem with the mute LED.
Headphone jack works but messes up with the existing speaker's output, creates a buzzing sound which is not mutable in any way. Restarting Pulseaudio or any relevant process doesn't help, only reboot solves the issue.

To get the top speakers working, tried tinkering with

hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000

didn't help.
Comment 240 let4be 2018-12-02 10:30:53 UTC
Hey there!
Having HP Spectre x360 13-w001ur sounds works in general but when I connect headphones - I hear nothing. Tried various headphones, works on windows...
I also checked that output is not muted, when I connect headphones speakers get properly muted

What can I try?
Thanks!
Comment 241 ralphtrotter 2018-12-16 03:17:30 UTC
It appears as stated in comment 105 this is is an issue only HP can resolve. Currently running Pclinuxos on HP Envy x360 13-y013cl i7 Kaby Lake. Have tested and/or installed all major linux operating systems on this notebook with same results: no sound either Live or Installed. There is never any sound on cold boot into Linux. However, Restart from Windows 10 directly into linux gives sound on all speakers.  Appears that the problem is caused by Hp BIOS. Seems that HP BIOS makes sound amplifier available to Windows only and not to Linux. However, on a boot into Linux after a Restart from Windows, the original Windows activation of the sound amplifier is kept in a persistent state which allows Linux operating system drivers to connect to the amplifier at Linux login. It is necessary to boot into Windows first (don't have to login) and simply Restart to Linux system boot and everything works. HP needs to get on the ball and do a BIOS update.
Comment 242 wang ming heng 2018-12-18 16:21:21 UTC
Hi there, mine is w053nr, a 8GB ram model. The audio subsystem is identified as 103c:827e, should be the same as w063nr's. My problem is no sound from headphones after I updated bios to F.48, and I think everything was working before, except some noises from the headphones. I didn't pay attention to my old bios version but I got this laptop around January 2017 and have been on Linux ever since, so the original bios on it must have been very old. Can someone please try downgrading the bios to the initial release and see if the audio works, if possible, because it always gets stuck at initializing when I try to flash older bios using a recovery usb flashdrive.

I'm using Fedora 29 and currently the running kernel is 4.19.8-300, and personally I've never noticed any difference in audio the last few months, so I assume headphones no sound is caused by bios update.
Comment 243 wang ming heng 2018-12-19 08:36:18 UTC
btw, I tried booting into windows 10 using a WinToGo usb to make sure all audio devices were working, then rebooted into Fedora. Unlike the others with dual boot, my headphones are still dead. Also I need to manually set pin 17 to internal speaker in HDAJackRetask for rear speakers to work in gnome settings' sound test. Honestly I'm not sure if the two rear speakers were working before, as their volume is really low compared to the bottom two. Perhaps I just lost headphones for nothing after this bios update.
Comment 244 drich 2018-12-23 14:38:18 UTC
(In reply to Tom Briden from comment #229)

First, thank you for your instructions, I would have spent weeks to figure out how to do all of this.

Having a similar problem on Envy x360 with Ryzen 2500U and ALC295 (bass speaker not working or is very low), I used your method to extract CORB files, but from now I'm a bit lost about how to apply them.
Comment 245 Tom Briden 2018-12-30 11:40:35 UTC
Hi all, had some time to remind myself how to get the corb buffers into hda-verb commands. 

Given the bit shifting done by the kernel to turn nid/verb/param into the command (https://elixir.bootlin.com/linux/v4.20/source/sound/hda/hdac_device.c#L228), we can split them back out with the following bash

cmd=001f2000
NID=$(( 16#$cmd >> 20 ))   #0x01
VERB=$(( $(( 16#$cmd >> 8 )) & 16#FFF )) #0xf20
PARAM=$(( 16#$cmd & 16#FF ))  #0x00

Putting those into a one-liner to iterate each command from the dumps and turn them into hda-verb args gives:

hexdump -v -e ' 1/4 "%08x " " \n"' corb-0*|while read cmd; do printf "0x%02x 0x%03x 0x%02x\n" $(( 16#$cmd >> 20 )) $(( $(( 16#$cmd >> 8 )) & 16#FFF )) $(( 16#$cmd & 16#FF )); done |while read args; do echo hda-verb $args; eval hda-verb /dev/snd/hwC0D0 $args; echo; done


If you run that while you have sound playing you'll hopefully notice the top speakers come to life
Comment 246 drich 2018-12-30 12:50:47 UTC
Doing this results in many "value = 0xffffffff" errors, will have to dig more in my case.

btw, is anyone working on Bang & Olufsen GUI settings ? Using an API monitor I figured out that it creates a COM interface using CoCreateInstance, but don't know what to do next
Comment 247 Siddhesh Rane 2018-12-30 19:36:54 UTC
I have Spectre x360 Convertible 13-ac0XX (bought in India) and on kernel 
4.19.0-041900rc6-generic. I can confirm that the top speakers are working for me. As for headphone jack, I have never had any problems and still don't, apart from crackling which is fixed with the following snippet:

  #comment 167 in this thread
  hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
  hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
  #comment 183 in this thread
  hda-verb /dev/snd/hwC0D0 0x53 0x500 0x00
  hda-verb /dev/snd/hwC0D0 0x53 0x4c0 0x6a

A big thank you to Tom and everyone who have stayed persistent on this issue over two years.
Comment 248 Siddhesh Rane 2018-12-30 20:04:18 UTC
(In reply to wang ming heng from comment #242)
> Hi there, mine is w053nr, a 8GB ram model. The audio subsystem is identified
> as 103c:827e, should be the same as w063nr's. My problem is no sound from
> headphones after I updated bios to F.48, and I think everything was working
> before, except some noises from the headphones. I didn't pay attention to my
> old bios version but I got this laptop around January 2017 and have been on
> Linux ever since, so the original bios on it must have been very old. Can
> someone please try downgrading the bios to the initial release and see if
> the audio works, if possible, because it always gets stuck at initializing
> when I try to flash older bios using a recovery usb flashdrive.

I have the same audio subsystem at mem addr dc228000 abd dc200000. My laptop is ac059tu and I have both speakers working. my bio version is F.31 release date 04/27/2017 Revision 15.31 firmware 94.60. Have you tried this bios version?
Comment 249 wang ming heng 2019-01-01 03:06:37 UTC
(In reply to Siddhesh Rane from comment #248)
> I have the same audio subsystem at mem addr dc228000 abd dc200000. My laptop
> is ac059tu and I have both speakers working. my bio version is F.31 release
> date 04/27/2017 Revision 15.31 firmware 94.60. Have you tried this bios
> version?

I want to, but I don't know how. Later on a Win2Usb I realized that HP's proprietary tools didn't allow BIOS downgrading, and I couldn't find any third party tools that supported this laptop either. I'm stuck.
Comment 250 Juan 2019-02-22 00:45:02 UTC
I purchased a late 2017 Spectre X360, model 13-ae013dx. I was able to solve this bug consistently using HDAJackRetask under Antergos by performing the following:

- Override pin 0x14 and set it to Internal Speaker (LFE). I believe this enables the amplifier that drives the top speakers. Setting it to something other than just "Internal Speaker" is important, so that pulseaudio does not try to redirect sound to that channel.

- Override pin 0x1e and set them to "Internal Speaker". 

Hit Apply Now, and voila you have sound out of all four speakers.

Screenshot below:

https://pasteboard.co/I2gloyk.png


I'm currently running Kernel 4.20.10-arch1-1-ARCH, and I have tried absolutely everything on this thread to no avail. Hope this helps!
Comment 251 uzivatelmp 2019-02-22 12:50:12 UTC
Hi Juan,

the steps you posted worked for me, but when I apply that, it sounds more tinny, than it does normally.

If I override only 0x14 to Internal Speaker, it sounds fine, but I lose volume control (the Master slider in alsamixer doesn't do anything, only mute works). I tried setting Channel Group to 1 (from 5), but then the top speakers stop working.
Comment 252 Holger Dehnhardt 2019-02-22 22:11:23 UTC
Wow Juan,

this simply works for me (x360 13-ae002ng)! Many many thanks!!!!!
@uzivateImp It definitely sounds different, but I think it's as it is intended. The Front speakers seem to boost the treble. 
Jouan, how did you found out? Only try and error?
Does your headphone jack work as well? 

Holger
Comment 253 Holger Dehnhardt 2019-02-22 22:44:21 UTC
When I disable auto mute in alsamixer, switching to headphones works as well. Bofore the speakers were not muted when plugging in the headphones.
Unfortunately after disconnecting the headphones, the speakers sounds terrible...
Comment 254 Holger Dehnhardt 2019-02-22 22:54:47 UTC
(In reply to Holger Dehnhardt from comment #253)
> When I disable auto mute in alsamixer, switching to headphones works as
> well. Bofore the speakers were not muted when plugging in the headphones.
> Unfortunately after disconnecting the headphones, the speakers sounds
> terrible...

Sorry for spamming... but the problem with the terrible sound after diconnection seemes only occur when auto mute is enabled. I can now say that everything works except the mute led.
Smile!
Comment 255 sharkcow 2019-02-23 20:42:15 UTC
Way to go Juan! Thank you for this incredibly easy fix (compared to the rest in this thread... :) Works also on my x360 13-ae004ng. However, I have to agree that there is way too much treble in the sound now. Maybe the bottom speakers should only be fed the bass signal? Maybe the signals should be distributed differently between the two speaker pairs (don't see in my alsa controls how that could be done though)? But again, the fix is great already!
Comment 256 Juan 2019-02-26 00:38:29 UTC
Hi guys. I just took some time to test things out. With the fix per post 250, I have perfect sound out of my headphones. I can't really tell a difference in the sound I'm getting from Windows or Linux after the fix. 

I did get a weird behavior, in which headphones were not detected in Windows. Sound kept playing through the speakers. I had never tried headphones in Windows before, so no idea if this is caused by messing around in Linux or not.

Thank you everyone for the feedback!
Comment 257 wang ming heng 2019-02-26 11:30:04 UTC
(In reply to sharkcow from comment #255)
> Way to go Juan! Thank you for this incredibly easy fix (compared to the rest
> in this thread... :) Works also on my x360 13-ae004ng. However, I have to
> agree that there is way too much treble in the sound now. Maybe the bottom
> speakers should only be fed the bass signal? Maybe the signals should be
> distributed differently between the two speaker pairs (don't see in my alsa
> controls how that could be done though)? But again, the fix is great already!

if that works for you perhaps it means these models hardwares are very different. w053nr and w063nr users need pin 0x17 to be connected to "internal speaker LFE"  for 4 working speakers, and our headjack stays dead on Linux. Mine was caused by BIOS update, but then again I have seen posts claiming that theirs died after installing OS, so who knows.
Comment 258 Fred Krauss 2019-03-12 14:00:14 UTC
Inspired by comment #250, I finally got all 4 speakers to work (including volume control) on my x360 13-ae0xx. I tested this on a clean install of Ubuntu 18.04.2.

Using HDAJackRetask, I overwrote the following pin values:

- Set pin 0x14 to "Internal speaker"
- Set pin 0x17 to "Internal speaker (back)"
- Set pin 0x1e to "Dock Line out"

When I only overwrote 0x14 and 0x17, I also had all 4 speakers work but volume control was missing. Frankly I don't understand why setting pin 0x1e to "Dock Line out" fixes the volume control, but I believe that pin 0x1e is somehow necessary for volume control, while pins 0x14 and 0x17 drive the front and rear speakers respectively.
Comment 259 Juan 2019-03-13 01:08:10 UTC
(In reply to Fred Krauss from comment #258)
> Inspired by comment #250, I finally got all 4 speakers to work (including
> volume control) on my x360 13-ae0xx. I tested this on a clean install of
> Ubuntu 18.04.2.
> 
> Using HDAJackRetask, I overwrote the following pin values:
> 
> - Set pin 0x14 to "Internal speaker"
> - Set pin 0x17 to "Internal speaker (back)"
> - Set pin 0x1e to "Dock Line out"
> 
> When I only overwrote 0x14 and 0x17, I also had all 4 speakers work but
> volume control was missing. Frankly I don't understand why setting pin 0x1e
> to "Dock Line out" fixes the volume control, but I believe that pin 0x1e is
> somehow necessary for volume control, while pins 0x14 and 0x17 drive the
> front and rear speakers respectively.

These settings work even better than my original ones on comment #250. The sound is no longer tinny, volume is louder and I get full control of balance/fade for the 4 speakers.

This will be my default setup from now on.

Nice work!
Comment 260 Juan 2019-03-13 01:48:30 UTC
(In reply to Juan from comment #259)
> (In reply to Fred Krauss from comment #258)
> > Inspired by comment #250, I finally got all 4 speakers to work (including
> > volume control) on my x360 13-ae0xx. I tested this on a clean install of
> > Ubuntu 18.04.2.
> > 
> > Using HDAJackRetask, I overwrote the following pin values:
> > 
> > - Set pin 0x14 to "Internal speaker"
> > - Set pin 0x17 to "Internal speaker (back)"
> > - Set pin 0x1e to "Dock Line out"
> > 
> > When I only overwrote 0x14 and 0x17, I also had all 4 speakers work but
> > volume control was missing. Frankly I don't understand why setting pin 0x1e
> > to "Dock Line out" fixes the volume control, but I believe that pin 0x1e is
> > somehow necessary for volume control, while pins 0x14 and 0x17 drive the
> > front and rear speakers respectively.
> 
> These settings work even better than my original ones on comment #250. The
> sound is no longer tinny, volume is louder and I get full control of
> balance/fade for the 4 speakers.
> 
> This will be my default setup from now on.
> 
> Nice work!

A small update.

If I set pin 0x1e to Dock Line Out, I get no sound from headphones.

Go to Advanced Override, and set:

- Pin 0x1e to "Aux"

This fixes the headphone sound, plus you get no extra "Line Out" output device on your settings panel.

Hope this works for you!
Comment 261 uzivatelmp 2019-03-13 10:00:13 UTC
(In reply to Juan from comment #260)
> (In reply to Juan from comment #259)
> > (In reply to Fred Krauss from comment #258)
> > > Inspired by comment #250, I finally got all 4 speakers to work (including
> > > volume control) on my x360 13-ae0xx. I tested this on a clean install of
> > > Ubuntu 18.04.2.
> > > 
> > > Using HDAJackRetask, I overwrote the following pin values:
> > > 
> > > - Set pin 0x14 to "Internal speaker"
> > > - Set pin 0x17 to "Internal speaker (back)"
> > > - Set pin 0x1e to "Dock Line out"
> > > 
> > > When I only overwrote 0x14 and 0x17, I also had all 4 speakers work but
> > > volume control was missing. Frankly I don't understand why setting pin
> 0x1e
> > > to "Dock Line out" fixes the volume control, but I believe that pin 0x1e
> is
> > > somehow necessary for volume control, while pins 0x14 and 0x17 drive the
> > > front and rear speakers respectively.
> > 
> > These settings work even better than my original ones on comment #250. The
> > sound is no longer tinny, volume is louder and I get full control of
> > balance/fade for the 4 speakers.
> > 
> > This will be my default setup from now on.
> > 
> > Nice work!
> 
> A small update.
> 
> If I set pin 0x1e to Dock Line Out, I get no sound from headphones.
> 
> Go to Advanced Override, and set:
> 
> - Pin 0x1e to "Aux"
> 
> This fixes the headphone sound, plus you get no extra "Line Out" output
> device on your settings panel.
> 
> Hope this works for you!

Hi, I have ae012nc, I tried setting 0x1e to Dock Aux, but then I lose volume control. I stop seeing Headphones (unplugged) in pavucontrol in both cases (Dock Line Out and Dock Aux).
Comment 262 sharkcow 2019-03-16 09:33:36 UTC
Great work guys, this really is it for my x360 13-ae004ng!

Some notes for the ingenious like me: 
* make sure 0x1e is in the same group as 0x14 and 0x17 (5 in my case)
* to make "boot override" work for this, I had to set 0x14 and 0x17 in "advanced override" as well (otherwise the override would be lost after boot). My settings:

0x14: 
Jack | Internal | Speaker | Other Analog
Unknown | Not Present | 5 | Front

0x17:
Jack | Internal | Speaker | Other Analog
Unknown | Not Present | 5 | Back

0x1e:
Jack | Dock Front | Aux | 3.5mm
Green | Present | 5 | Front