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.
Created attachment 246201 [details] alsa-info 2.9.0-rc7
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.
If I find it out is it going to be a code fix in the form of a new model or something?
I also tried latest Ubuntu LiveCD, there's no sound and no devices except for Dummy. So I guess it's a real problem.
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.
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
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.
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.
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. :)
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. ?
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).
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
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.
I can confirm that both bottom speakers work on mine and headphones are not crackly. Headphones sound great, actually.
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...
@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
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.
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.
Any news, Maxim?
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.
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
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.
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
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].
Tom Briden: wow, amazing find. I can confirm that this works on my setup too.
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.
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.
Same, Bill. So yeah, hdamonitor is working fine, but pin 0x17 isn't it for me either. Though headphones natively work fine for me.
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...
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!
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..
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/
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
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.
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
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?
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).
Okay, yeah, I just needed to restart, now hda-verb works and is spitting out sensible things.
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?
Created attachment 255499 [details] alsa-info working speakers I manually set the pincfg to 0x17 0x90170111 to match the conexant x360 fix
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?
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.
Created attachment 255519 [details] alsa-info inc coef Thanks Takashi, attached is the alsa-info after setting dump_coef
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
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...
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
Created attachment 255529 [details] patch to fix mute led on a separate note, i've got the mute led working with the attached patch
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
It might be some volatile or read-only value. Only Realtek knows.
Hi, I have a 13-w023dx with same problem on ubuntu 17.04 kernel 4.10.0-19. only bottom speakers work.
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.
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?
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.
Created attachment 256491 [details] image of pin configuration (broken headphone jack)
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
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.
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.
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 ?
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.
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
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 ```
Suspending and unsuspending the laptop seems to have undone the change and now the coeff seems to be write only.
I checked the COEF 10h for verb setting. The value is correct 0x0020.
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.
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.
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.
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.
0x17 pin is I2S out. So, it will have I2S codec connect after 0x17 pin.
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
I don't know for I2S control. Because HP maybe no support Ubuntu for this platform. So, I don't know which hardware architecture.
Hi Tom, This issue only happen on Windows reset then boot into Linux. Right?
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.
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!
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.
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.
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
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.
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.
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/
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?
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.
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
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.
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)
PS I tried upgrading the bios (to F.32), but sadly that didn't help.
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.
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
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!
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.
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.
Has anyone made any progress on either the headphone or top speaker problem?
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
Doesn't work for me unfortunately.
What model? That fix does work for me with a 13-w013dx.
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
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?
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!
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.
(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.
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