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: | alfonsofernandezyf, antoine.bernez, aroragagan24, bastett, bennyrobot1143, bermanmaxim, bruttofra87, bugzilla, cipkuehl, contact, danhosler, dario.asm, datakid, dislabled, djvw1983, dmaroulidis, dridri85, e.vakhromtsev, elias.gabrielsson, etnguyen03, fattony4, foss, francesco.cuius.98, frans.skarman, fredericok, g.korelin, gdm105658, giuseppe06, grabowski.frederic, grib, hhben10, holger, ian.hincks, ic2, ifoolb, ivan, j, jason, jrda, kailang, kingsid911, kj4tmp, klajdi.hysenaj.h.k, lalochcz, LANGLOIS.JF, let4be, levmckinney, m.aragnet, mateusz.tomasz.doroszko, matthewbtjones2000, mayank8019, mayurvirkar, me, mpc7400, nicolas.grimbaum, nrobert13, osip.fatkullin, philip.leis, pjmdr11, redlane, reg.krn, reg.pkm, roseb70583, Ryan.Laird, sagarsaini, sareen_eng, sharkcow, tacchinotech, thezealousfool, tiwai, ushmax, uzivatelmp, vortex, yurii.tvardyi, zxc011991 |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 4.9.0-rc7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| 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 attachment-7789-0.html Pin configuration for HP Envy x360 13-ag0xxx attachment-17450-0.html |
||
|
Description
Oleg Mikheev
2016-11-29 07:35:22 UTC
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. 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
My device is specifically the 13-ae024tu 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. (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. (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. 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 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 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 I've just rt, same issues here regarding top/upper speakers. 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.
(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? 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. (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. Created attachment 275647 [details]
Fix speakers by applying ALL verbs applied by Windows
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> 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 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. upgraded BIOS to F.45 and applied patch to kernel 4.17-rc2, still no luck but must be so close 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. > 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? 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. 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 Created attachment 275655 [details]
cat /proc/asound/card0/codec#0 - working
Created attachment 275657 [details]
cat /proc/asound/card0/codec#0 - not working
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? Oh, and GPIO[2] also differs. 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 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 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
```
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 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. 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 (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. (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. 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 (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"? (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. 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 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. 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 (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... 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! 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 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. 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 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? 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?
(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? 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. 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. 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 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. 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) 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. (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. 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. 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 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 (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 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. I can report the same as Benjamin Schmitz on a 13-w063nr with bios F.45. (Meaning all points except the beep) 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 (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. 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. 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. 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 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 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 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? 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 (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. 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. I have not noticed any change with the headphones, still the same quite hiss. But the front/top speakers work great. same, speakers work beautifully, headphones don't, tried everything in hda analyzer 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? I just get slight static or no noise from a variety of headphones, so my previous comment doesn't make any sense. 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? I just heard the high pitch noise that was discussed a while back using the kernel from 2018-05-01 I just heard the high pitch noise as well. Is happened after resuming from suspend. 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). Created attachment 276251 [details]
Replacement of hp_x360_helper.c
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! OK, I'm going to submit & merge the speaker patch, too. The 0x53 COEFs can be tweaked later, if any. 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. 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. I can also confirm that the sound improves after setting the the above verbs. Also no more popping. However headphones still don't work. 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. Everything seems to be working fine for me, whats left to do before this can be mainlined? Compiled from Tom's branch - top speakers and headphones working great. Model 13-ac033dx Thank you! 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 . (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 (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. (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. 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. 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!! 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. 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? 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 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. Created attachment 277445 [details]
lspci -nnv on ae-012nc (mute LED and top speakers not working, different PCI id)
Created attachment 277447 [details]
alsa-info on ae-012nc (mute LED and top speakers not working, different PCI id)
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
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. 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
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! 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
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. 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. (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. 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;-) 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.) 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. @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 Created attachment 278217 [details]
Pinconfig extracted in Windows
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. @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 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. :) 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 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. (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 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. 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. 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. @Holger Did you make any progress with dumping the hda-verbs? 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! @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. ( @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 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 This might also help as it seems to be the similar as to what Tom did: https://jcs.org/2018/11/12/vfio @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. :) 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. Created attachment 279473 [details]
Dumps from Spectre x360 13" ae012nc
@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 ---- 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. 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. > 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. 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. 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! 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. 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. 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. (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. 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 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 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. (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? (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. 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! 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. 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 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... (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! 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! 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! (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. 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. (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! (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! (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). 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 Does not work for x360 15-cp0001nf, these pin settings enable "4.0 analog output" in pavucontrol, but sound is exactly the same (no sound coming from bottom speakers) (In reply to sharkcow from comment #262) > 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 This setup does work up to point on my "HP ENVY x360 Convertible 13-ag0xxx". This model has the ALC285 codec. Specifically with this setup headphones don't work, but I dont't really care (I don't use them much), and sound coming from the left front (bottom) and the two back (top) speakers (left and right). Also, when volume is at 50% or less the top speakers are silenced and only the bottom left works. (My guess is that pin 0x14 maybe is the subwoofer or something else) Were you able to get the microphone working? Created attachment 282097 [details]
attachment-7789-0.html
Yes, the microphone works but there's a bit of static, that disappears if you lower the mic volume. Also, since, I installed the boot override with hdajackretask I get sound from those 3 speakers is Windows, too. Apparently Windows doesn't bother to reset the pin configuration on boot.
Can you please share your pin config for the microphone? Well I haven't remapped it. It's what the system setup from the beginning.
The kernel recognized pin 0x19 as "Black Mic, Left side"
Jack | Left | Microphone | 3.5mm
Black | Present | 4 | Front
And pin 0x12 as "Internal Mic, Mobile-in"
| Other bottom | Microphone | Other Digital
Unknown | Not present | 12 | Front
Also, I haven't retasked pin 0x1e as in comment #262 as it breaks the headphone port, and I have issues when plugging and unplugging my headphones with the system not recognizing whether the jack is or isn't connected.
If anyone wants I can share my full configuration (there 're 12 pins).
Please do share the full configuration. Is there any way to detect pins which are active but undetected? Also, Maybe you can help me with this? https://bugzilla.kernel.org/show_bug.cgi?id=203129 Created attachment 282109 [details]
Pin configuration for HP Envy x360 13-ag0xxx
I've tried hdajacksensetest. My full configuration is attached. (Sorry for the quality; The display is upscaled)
(In reply to Dimitris from comment #271) > Created attachment 282109 [details] > Pin configuration for HP Envy x360 13-ag0xxx > > I've tried hdajacksensetest. My full configuration is attached. (Sorry for > the quality; The display is upscaled) Here's my alsa-info: http://alsa-project.org/db/?f=bb468c3097b7721125c01feb8668506ece3a0dba I'm having the same issue as Dimitris. Model: HP Envy 13-ad059na using the ALC295 codec Detects: Internal Mic, Mobile-In Pin ID 0x12 Internal Speaker Pin ID 0x17 Black Mic, Left side Pin ID 0x19 Black Headphone, Left side Pin ID 0x21 Sound is quiet, only coming from front speakers by default, using the configuration provided by Juan sound comes from the back speakers as well however the volume control only works for the back and the front ones are permanently at 100% unless you mute entirely. (In reply to Dimitris from comment #271) > Created attachment 282109 [details] > Pin configuration for HP Envy x360 13-ag0xxx > > I've tried hdajacksensetest. My full configuration is attached. (Sorry for > the quality; The display is upscaled) Thanks, thar worked great. I needed to switch the output to 4.0 output in pulseaudio. I have a problem though, volume control does not work properly. Volume slider moves but does not affect sound volume. It's either on or off. If you set it to 0 it mutes audio, but anything above 1% is full volume. Have you had a problem like this? Thanks (In reply to Alfonso Fernandez from comment #274) > (In reply to Dimitris from comment #271) > > Created attachment 282109 [details] > > Pin configuration for HP Envy x360 13-ag0xxx > > > > I've tried hdajacksensetest. My full configuration is attached. (Sorry for > > the quality; The display is upscaled) > > Thanks, thar worked great. I needed to switch the output to 4.0 output in > pulseaudio. > > I have a problem though, volume control does not work properly. Volume > slider moves but does not affect sound volume. It's either on or off. If you > set it to 0 it mutes audio, but anything above 1% is full volume. > > Have you had a problem like this? > > Thanks Yes. It took me a while to notice this but I do experience it. Also, the speakers are quieter at max volume in Arch than in Windows, you'll probably need to go above 100% to achieve the same volume. Another thing is that I've tried reinforcing the realtek drivers from HP in Windows but that didn't reset the chipset configuration to normal factory settings, even thought other linux live distros, without the specific remapping, use only the front left speaker. If anyone has any insight into why this is happening please share. (In reply to Dimitris from comment #275) > (In reply to Alfonso Fernandez from comment #274) > > (In reply to Dimitris from comment #271) > > > Created attachment 282109 [details] > > > Pin configuration for HP Envy x360 13-ag0xxx > > > > > > I've tried hdajacksensetest. My full configuration is attached. (Sorry > for > > > the quality; The display is upscaled) > > > > Thanks, thar worked great. I needed to switch the output to 4.0 output in > > pulseaudio. > > > > I have a problem though, volume control does not work properly. Volume > > slider moves but does not affect sound volume. It's either on or off. If > you > > set it to 0 it mutes audio, but anything above 1% is full volume. > > > > Have you had a problem like this? > > > > Thanks > > Yes. It took me a while to notice this but I do experience it. Also, the > speakers are quieter at max volume in Arch than in Windows, you'll probably > need to go above 100% to achieve the same volume. Another thing is that I've > tried reinforcing the realtek drivers from HP in Windows but that didn't > reset the chipset configuration to normal factory settings, even thought > other linux live distros, without the specific remapping, use only the front > left speaker. If anyone has any insight into why this is happening please > share. I noticed that pulse audio volume slider only dimms the top speakers. The bottom ones remain @ 100% until yo go to 0% then both top and bottom mute. I tried resetting my pulseaudio config files but got the same result. you can try to decouple the locked audio sliders in pulseaudio by changing in /usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common in the PCM section "volume = merge" to "volume = ignore" Then use e.g. alsamixer to control PCM individually. Hi I'm a HP Spectre x360 13-w0XX user. Recently trying out dual boot with elementary OS. Facing the same issue having the top speaker not working. I'm not very sure about the configs for hdajackretask. I tried testing all pin that are fitted to internal speaker to "internal speaker" config. Nothing works. From what I understand Pin ID 0x14 is the side speakers, my front speaker doesn't work. IDK if it has any relation with Bang & Olufsen drivers Hi, I got a HP Spectre x360 13t-ap000 (Whiskey Lake), it is the latest model, known as "Gem Cut". On this model I have the same problem: I only get audio from the back speakers and not from the front speakers. The audio card is ACL285. Internal speaker is by default setted at PIN 0x17. I tried several configurations changing pins 0x14 and 0x1e, but none of these attempts worked. Have anyone tried this model? Sorry, the "back speakers" in my comment are what you are calling the "front speakers" and the "front speakers" are those near the screen. I have a Spectre x360 13-w023dx, and I'm having the issue where the headphones are detected but no audio is heard through them. Has there been a successful fix for this problem; if so, what is the fix? I've tried retasking pin 0x14, 0x17, and 0x1e; and the two `hda-verb` commands with no luck. So I've (In reply to Dimitris from comment #275) > (In reply to Alfonso Fernandez from comment #274) > > (In reply to Dimitris from comment #271) > > > Created attachment 282109 [details] > > > Pin configuration for HP Envy x360 13-ag0xxx > > > > > > I've tried hdajacksensetest. My full configuration is attached. (Sorry > for > > > the quality; The display is upscaled) > > > > Thanks, thar worked great. I needed to switch the output to 4.0 output in > > pulseaudio. > > > > I have a problem though, volume control does not work properly. Volume > > slider moves but does not affect sound volume. It's either on or off. If > you > > set it to 0 it mutes audio, but anything above 1% is full volume. > > > > Have you had a problem like this? > > > > Thanks > > Yes. It took me a while to notice this but I do experience it. Also, the > speakers are quieter at max volume in Arch than in Windows, you'll probably > need to go above 100% to achieve the same volume. Another thing is that I've > tried reinforcing the realtek drivers from HP in Windows but that didn't > reset the chipset configuration to normal factory settings, even thought > other linux live distros, without the specific remapping, use only the front > left speaker. If anyone has any insight into why this is happening please > share. I tried reinstalling windows from the on board recovery partition, with HP's customer support, and ended up sending the device for service since it didn't reset the chipset's pin configuration *. I would expect that HP's audio drivers would reconfigure the chipset at some point during installation, but apparently it doesn't?? Or, I have screwed up something with the retasking and made it permanent? Any thoughts? * I think they're going to replace the mainboard. (In reply to Dimitris from comment #282) > I tried reinstalling windows from the on board recovery partition, One question: when you reinstall windows with the HP recovery, does it crash also the Linux partitions, or it just reinstall over the windows partition leaving Linux untouched? I would like to try the same, but I do not want to delete my Linux partition in the process. (In reply to Alejandro Díaz-Caro from comment #283) > (In reply to Dimitris from comment #282) > > I tried reinstalling windows from the on board recovery partition, > > One question: when you reinstall windows with the HP recovery, does it crash > also the Linux partitions, or it just reinstall over the windows partition > leaving Linux untouched? > > I would like to try the same, but I do not want to delete my Linux partition > in the process. It restores the entire machine to factory conditions, i.e. it's just like when you first unboxed the laptop (the recovery repartitions the disk). (No linux) Quick update. After a few iterations and distros, I think I found the sweet spot for this hardware. I have all four speakers, volume control, microphone and headphones. 0x14: Jack | Front | Speaker | Other Analog Unknown | Not Present | 5 | Front 0x17: No override JacBlankk | Internal | Speaker | Other Analog Unknown | Not Present | 1 | Front Blank 0x1e: Jack | Rear | Speaker | Other Analog Green | Not Present | 5 | Front (In reply to Juan from comment #285) > Quick update. After a few iterations and distros, I think I found the sweet > spot for this hardware. > > I have all four speakers, volume control, microphone and headphones. > > 0x14: > Jack | Front | Speaker | Other Analog > Unknown | Not Present | 5 | Front > > 0x17: > No override > > JacBlankk | Internal | Speaker | Other Analog > Unknown | Not Present | 1 | Front > > Blank > > 0x1e: > Jack | Rear | Speaker | Other Analog > Green | Not Present | 5 | Front That worked great on Envy x360 13-ag0002la, but I don't JacBlankk. Do you mean leave 0x17 connectivity blank? Both arrays of speakers sound loud and clea, and volume control works correctly. The only problem I have is a crackling sound when recording sound from microphone or line in. Maybe it is related to the pin config. https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1827440 Apologies, typo. It should've been "Blank". As far as microphone I had no issues recording clean audio. No idea what might be different on your hardware :( Hi everyone. I've been following this thread for a couple of years since I got my spectre x360. I never got to get everything functionning, and I wanted to know if anyone have a clue to help me move forward with this ? When I apply the fixes that Juan proposed @285 I get the four speakers work. If i set up the profile as 4.0 surround in pavucontrol, internal mic doesn't show up anymore, neither does the headphones (unplugged and plugged). If i set up the profile as stereo output or duplex stereo, i get this : - internal mic and microphone(unplugged) as audio inputs. Although, it looks like they are the same. - Speakers and headphones(unplugged) as audio outputs. Although, when I plug in the headphones, it doesn't switch to them. If i manually change the output device to headphones(unplugged), it works. Also, if I look into alsamixer, I get that the headphones are muted, whether they're plugged in or not, and I can manually unmute them, and mute the speakers to get sound only on headphones. I have to do the reversed operations to get sound back from speakers. This is slightly annoying as I do use headphones a lot (especially now), so I won't be keeping those tweaks that you found. On another hand, I'm really frustrated about not using those top speakers for 2 years now, especially now that I know that I can make them work. Volume control works fine anyway. Any idea ? Thanks for you help, and making this thread ! When I plug in a headset into the built in sound card of my HP Spectre x360 the mic works but headphones not. Adjustments mentioned in the Comment 285 don't help. So as a workaround I use a Ugreen USB External Sound Card Adapter with my headset. Maybe it will be helpful for other people. https://www.ugreen.com.cn/products/usb-external-sound-card-adapter I had this same problem and I just entirely fixed it by doing a physical hard shut down. Just while the laptop is on, hold down the power button without touching/clicking anything on the screen until it shuts off and keep holding it until it powers back on by itself(you see the hp boot up logo) or it has some text in the upper left of the screen. Your laptop should boot up normally and work perfectly. (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 worked for my spectre x360 15 df-100 model. Only top speakers are really low volume. I also tried to boot into windows, which gives full volume, and disable drivers and reboot. This trick did not work for me. (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. How do you get HDAJackRetask? I am on Ubuntu 19.10 and can't find it in the Repos: sudo apt install HDAJackRetask E: Paket HDAJackRetask kann nicht gefunden werden. Created attachment 289153 [details] attachment-17450-0.html In ubuntu run: $ sudo apt install alsa-tools-gui On Wed, May 13, 2020 at 12:20 AM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=189331 > > --- Comment #292 from 3ddd@gmx.de --- > (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. > > How do you get HDAJackRetask? I am on Ubuntu 19.10 and can't find it in the > Repos: > sudo apt install HDAJackRetask > E: Paket HDAJackRetask kann nicht gefunden werden. > > -- > You are receiving this mail because: > You are on the CC list for the bug. i still have the same problem on hp envy x360. kernel 5.4.0.36. I can't understand why hdajackretask won't accept any changes, every time I do install boot override on reboot it's all the same. I also have no sound from the headphone output, though everything else - all four speakers, mute w/LED and all volume keys, headphone/microphone presence detection, volume controls in KDE Plasma - all work perfectly. hdajackretask shows "Black Headphone, Left side" pinID 0x21, but I cannot tell what else may need to be set in order to enable it; I do not know what I'm doing. I'd be happy to follow instructions and post results if it will help sort this out. Hardware is HP x360 model 13-w030ca. ALSA information is located at http://alsa-project.org/db/?f=b087498a3796ba2cccacb5af0ef9f351e11c4b78 I have an hp spectre x360 13-ae052nr running manjaro kernel 4.19.126-1 I have two speakers, headphone jack, headphone jack microphone, internal microphone. Manual switching only for headphones vs. speakers vs. line out and internal vs. external microphone. The line out does nothing. This is the best I could do, if I change 0x14 to "speakers", i get 4 speakers but the microphones and headphones don't work. using hdajackretask 0x14 override checked jack | internal | other | other analog unknown | not present | 5 | front 0x17 override checked jack | internal | speaker | other analog unknown | not present | 5 | front 0x19 override checked jack | left | microphone | 3.5mm black | not present | 3 | front 0x1e override checked jack | dock front | line out | 3.5mm black | not present | 5 | front 0x21 override checked jack | left | headphone | 3.5mm green | not present | 3 | channel 30 & 31 Anyone have any ideas? Using both Juan's and sharkcow's (who seems to have a very similar model to me) configs on a HP Spectre x360 ae004na works great but the only problem is that at medium-high volume the left channel on the headphones jack crackles fairly significantly. Any ideas on how to fix it? Ryan's commands don't seem to help either. Using both Juan's and sharkcow's (who seems to have a very similar model to me) configs on a HP Spectre x360 ae004na works great but the only problem is that at medium-high volume the left channel on the headphones jack crackles fairly significantly. Any ideas on how to fix it? Ryan's commands don't seem to help either. (In reply to ralphtrotter from comment #241) > 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. Hey did you managed to fix the sound for this hp envy y013cl laptop anyhow? I have been hopping distros for the sound to work properly and currently using manjaro kde. Sound doesn't works on cold boot but after restarting the laptop sound works fine.Let me know if you have found any workarounds for this laptop. I had no-audio on ae014dx. I tried all sorts of hdajackretask combinations, and nothing worked quite right. The best I could get was thin half-volume sound out of 2-speakers. Then I updated BIOS with the latest flash tool from HP's website, and the audio is now fine. So maybe that's the solution for some laptops. Pro tip - since HP's flash tool is Windows-only, you can use "wintousb" program to create a bootable USB drive and flash from there. do you also have internal mic now? (In reply to DDD from comment #301) > do you also have internal mic now? Yes. Headphones also work. There is a slight chance this is because I was logged into Windows (to run the flash tool), but I don't think so because the audio actually didn't work in Windows (no drivers for some reason), so I don't think it could have send those magical instructions to setup the hardware correctly. i flashed the .14 BIOS oder my .11 under Windows. In Windows i have MIC, but not on Linux. 00:1f.3 Multimedia audio controller: Intel Corporation Sunrise Point-LP HD Audio (rev 21) Subsystem: Hewlett-Packard Company Sunrise Point-LP HD Audio Flags: bus master, fast devsel, latency 64, IRQ 178 Memory at 1ffb018000 (64-bit, non-prefetchable) [size=16K] Memory at 1ffb000000 (64-bit, non-prefetchable) [size=64K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel Kernel: 5.4.0-58-generic #64-Ubuntu SMP 5.715754] snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) [ 5.716230] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 5.766256] snd_hda_codec_generic hdaudioC0D0: autoconfig for Generic: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker [ 5.766261] snd_hda_codec_generic hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.766265] snd_hda_codec_generic hdaudioC0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0) [ 5.766267] snd_hda_codec_generic hdaudioC0D0: mono: mono_out=0x0 [ 5.766270] snd_hda_codec_generic hdaudioC0D0: inputs: [ 5.766273] snd_hda_codec_generic hdaudioC0D0: Mic=0x19 http://alsa-project.org/db/?f=914714ad3845debf133b6c3d46cc198f0e32eaac (In reply to DDD from comment #303) 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 157 Memory at dcc28000 (64-bit, non-prefetchable) [size=16K] Memory at dcc00000 (64-bit, non-prefetchable) [size=64K] Capabilities: <access denied> Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel Kernel: 5.8.0-7630-generic #32~1609174078~20.10~4b8d17c-Ubuntu [ 5.654774] spectra360-popos kernel: snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380 [ 5.654790] spectra360-popos kernel: snd_hda_intel 0000:00:1f.3: enabling device (0000 -> 0002) [ 5.654989] spectra360-popos kernel: snd_hda_intel 0000:00:1f.3: Applying patch firmware 'hda-jack-retask.fw' [ 5.655327] spectra360-popos kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) [ 5.713654] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC295: line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker [ 5.713656] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 5.713658] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 5.713659] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 [ 5.713660] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: inputs: [ 5.713661] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: Mic=0x19 [ 5.713662] spectra360-popos kernel: snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 I am using the "internal mic", which you don't seem to get. @DDD try disabling "jack detect" in hdajackretask (it's under "Parser hints"). i have to select a Codec, HDMI KB or Conexant, when i set jack detect to no on both and apply this, i see a Error: The Device or Ressource is in use (In reply to DDD from comment #305) > i have to select a Codec, HDMI KB or Conexant, when i set jack detect to no > on both and apply this, i see a Error: The Device or Ressource is in use Select the internal audio card, "Realtec ALC295" is for me. Then don't try to "Apply", but just "Install boot override" and then reboot. now i see a mic in the settings, but in skype and arecord i can't record anything. http://alsa-project.org/db/?f=63bbf4aee2ac8cef38e110364b943d94e13dd1a5 It's really frustrating to see this bug since 2016 still unpatched or without any valid solution. I can still confirm for HP Envy x360 (15-cn0700ng) from 2018 with Bang&Olufsen speakers. I couldn't find any way to contact HP per Email and Bang&Olufsen said they don't have to do anything with it, it's HP's problem. Just noticed that on my HP Spectre x360 Convertible 15-eb0045ur I can get audio by overriding 0x14 pin (to Internal Speaker LFE) only when using Nouveau driver. With Nvidia drivers it has no effect. > It's really frustrating to see this bug since 2016 still unpatched or without > any valid solution. I successfully fixed the same problem on HP Envy x360 13-AR0107AU and the patch is currently on review: https://lore.kernel.org/linux-sound/20240310140249.3695-1-foss@athaariq.my.id/T/#u. For your model, I compiled and uploaded the kernel with my patch included via GitHub: https://github.com/Thor-x86/linux/releases/tag/v6.7.8-hp-envy_13_ar0xxx. Please let me know if it works on your model or not, so I can generalize the solution scope or adjust it to make it work. (In reply to Athaariq Ardhiansyah from comment #310) > > It's really frustrating to see this bug since 2016 still unpatched or > without > > any valid solution. > > I successfully fixed the same problem on HP Envy x360 13-AR0107AU and the > patch is currently on review: > https://lore.kernel.org/linux-sound/20240310140249.3695-1-foss@athaariq.my. > id/T/#u. For your model, I compiled and uploaded the kernel with my patch > included via GitHub: > https://github.com/Thor-x86/linux/releases/tag/v6.7.8-hp-envy_13_ar0xxx. > Please let me know if it works on your model or not, so I can generalize the > solution scope or adjust it to make it work. I just booted with your kernel, but I still cannot make all 4 speakers work. I only hear sound from the bottom two speakers (on the keyboard's back), but volume control works correctly for those two. Tell me if you want to test anything else. I have a HP Envy x360 13-ag0xxx running ArchLinux. > I have a HP Envy x360 13-ag0xxx running ArchLinux. Good to know, I'm using Arch too coincidentally. > I still cannot make all 4 speakers work. I only hear sound from the bottom > two speakers (on the keyboard's back), but volume control works correctly for > those two. Did you removed all overrides on HDAJackRetask and any other snd_hda_intel options in modprobe.d? If yes then wait until I pushed another kernel where amplifier 0x2 and 0x3 assigned to both speaker 0x14 and 0x17. Just to make sure, are headset speaker and mic work properly? I removed all hda jack retask overrides, by deleting the modprobe file created by it. I couldn't test the speaker/mic combo 3.5mm jack because I don't have any 3.5mm headphones anymore 😁. -------- Αρχικό Μήνυμα -------- Την 12/3/24 12:49, ο/η <bugzilla-daemon@kernel.org> έγραψε: > https://bugzilla.kernel.org/show_bug.cgi?id=189331 > > --- Comment #312 from Athaariq Ardhiansyah (foss@athaariq.my.id) --- > > I have a HP Envy x360 13-ag0xxx running ArchLinux. > > Good to know, I'm using Arch too coincidentally. > > > I still cannot make all 4 speakers work. I only hear sound from the bottom > > two speakers (on the keyboard's back), but volume control works correctly > for > > those two. > > Did you removed all overrides on HDAJackRetask and any other snd_hda_intel > options in modprobe.d? If yes then wait until I pushed another kernel where > amplifier 0x2 and 0x3 assigned to both speaker 0x14 and 0x17. > > Just to make sure, are headset speaker and mic work properly? > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. Hi Dimitris, I compiled the alternate patch which assigns 0x2 and 0x3 amps to all speakers instead of only back speakers. https://github.com/Thor-x86/linux/releases/tag/v6.7.9-hp-envy_13_ag0xxx Let me know if it works or another quirk shows up (In reply to Dimitris from comment #311) > (In reply to Athaariq Ardhiansyah from comment #310) > > > It's really frustrating to see this bug since 2016 still unpatched or > > without > > > any valid solution. > > > > I successfully fixed the same problem on HP Envy x360 13-AR0107AU and the > > patch is currently on review: > > https://lore.kernel.org/linux-sound/20240310140249.3695-1-foss@athaariq.my. > > id/T/#u. For your model, I compiled and uploaded the kernel with my patch > > included via GitHub: > > https://github.com/Thor-x86/linux/releases/tag/v6.7.8-hp-envy_13_ar0xxx. > > Please let me know if it works on your model or not, so I can generalize > the > > solution scope or adjust it to make it work. > > I just booted with your kernel, but I still cannot make all 4 speakers work. > I only hear sound from the bottom two speakers (on the keyboard's back), but > volume control works correctly for those two. > > Tell me if you want to test anything else. I have a HP Envy x360 13-ag0xxx > running ArchLinux. Athaariq I'm still facing the same issue as before. Didn't test the audio jack. Sound coming out from the two bottom-firing speakers. Removed all hda-jack-retask modifications before booting your second kernel and added the modprobe file you suggested in your github page. |
