Bug 210633

Summary: Sound does not work on Tiger Lake if cold booted
Product: Drivers Reporter: Alan Olsen (alan)
Component: Sound(ALSA)Assignee: Jaroslav Kysela (perex)
Status: NEW ---    
Severity: normal CC: alan, dave.greengas, davide, dskoterov, jonathan.a.clarke, kernelorg, marc, maxbowsher, michael.plezbert, pierre-louis.bossart, tiwai
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: 5.10.7 Subsystem:
Regression: No Bisected commit-id:
Attachments: Test patch
dmesg output
kernel log
patch for HP x360 14 top/rear speaker & mic/mute leds
qemu "verb-sniffing" output
RtHDDump output

Description Alan Olsen 2020-12-11 16:53:44 UTC
[This is migrated from bug 210355]

I have an HP Spectre X360 14 laptop with a Tiger Lake chipset.

If I boot from power off, the sound does not work.

If I boot into Windows first and then soft reboot into Linux, the sound works.

0000:00:1f.3 Multimedia audio controller: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20)
	Subsystem: Hewlett-Packard Company Device 87f6
	Flags: bus master, fast devsel, latency 32, IRQ 207
	Memory at 603f290000 (64-bit, non-prefetchable) [size=16K]
	Memory at 603f000000 (64-bit, non-prefetchable) [size=1M]
	Capabilities: [50] Power Management version 3
	Capabilities: [80] Vendor Specific Information: Len=14 <?>
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Kernel driver in use: sof-audio-pci
	Kernel modules: snd_hda_intel, snd_sof_pci

[alan@localhost ~]$ amixer contents 
numid=4,iface=MIXER,name='Master Playback Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=on
numid=3,iface=MIXER,name='Master Playback Volume'
  ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1
  : values=36250,35566
numid=2,iface=MIXER,name='Capture Switch'
  ; type=BOOLEAN,access=rw------,values=1
  : values=off
numid=1,iface=MIXER,name='Capture Volume'
  ; type=INTEGER,access=rw------,values=2,min=0,max=65536,step=1
  : values=29274,29274

Audio works with the Gnome sound test. (Using the soft reboot of Windows trick.)

This plays. I could not find a hardware name that worked.

[alan@localhost ~]$ aplay -vv  /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 48000
  exact rate   : 48000 (48000/1)
  msbits       : 16
  buffer_size  : 24000
  period_size  : 6000
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 6000
  period_event : 0
  start_threshold  : 24000
  stop_threshold   : 24000
  silence_threshold: 0
  silence_size : 0
  boundary     : 6755399441055744000

With sound working:

http://alsa-project.org/db/?f=0d2053ebb002740fa311aeaa5b7d7bbc56cb3aab

With sound not working:

http://alsa-project.org/db/?f=199e89c343201a96779e85e401ad7281f6a349f6
Comment 1 Artem S. Tashkinov 2020-12-11 23:03:45 UTC
You might need to have alsa-sof-firmware installed.
Comment 2 Alan Olsen 2020-12-11 23:22:15 UTC
The firmware is installed.  I have used the firmware from Fedora 33, as well as the firmware from Intel's repository. (Version 1.6 of the sof firmware.)

It works if I boot into Windows first and then reboot into Linux. How can I tell if the firmware is even being loaded? The kernel modules load the same either way. Is there something in dmesg I should look for? Can I force the load of the firmware to test it?
Comment 3 Alan Olsen 2020-12-11 23:44:58 UTC
This might be the problem...

[alan@localhost ~]$ dmesg | grep sof | grep -i firmware
[   31.738174] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:6:0-e9637
[   31.738176] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:17:0 Kernel ABI 3:16:0

Any way to get the ABI versions to match?
Comment 4 Alan Olsen 2020-12-11 23:56:51 UTC
I have a 5.10.0 kernel loading and the ABI versions now match. Sound still does not work without booting Windows, even with the latest firmware update from Intel. (Checked as of 12/11/2020.)

Firmware shows as loaded in both cases. (Unless I am misinterpreting something.)
Comment 5 Alan Olsen 2021-01-19 17:52:31 UTC
I found a possible issue with the driver.

In linux/sound/soc/sof/sof-pci-dev.c about line 240.

static const struct sof_dev_desc tglh_desc = {
        .machines               = snd_soc_acpi_intel_tgl_machines,
        .alt_machines           = snd_soc_acpi_intel_tgl_sdw_machines,
        .resindex_lpe_base      = 0,
        .resindex_pcicfg_base   = -1,
        .resindex_imr_base      = -1,
        .irqindex_host_ipc      = -1,
        .resindex_dma_base      = -1,
        .chip_info = &tglh_chip_info,
        .default_fw_path = "intel/sof",
        .default_tplg_path = "intel/sof-tplg",
        .default_fw_filename = "sof-tgl-h.ri",
        .nocodec_tplg_filename = "sof-tgl-nocodec.tplg",
        .ops = &sof_tgl_ops,
};

sof-tgl-h.ri does not exist. sof-tgl.ri does exist and a different structure references it.

Is this a reference to an older firmware blob?
Comment 6 Jaroslav Kysela 2021-01-19 20:28:01 UTC
No, TGL-H will be supported from SOF FW 1.7.0 (which is not released yet). Also, it's unclear, if the 5.10 kernel is sufficient to fully support your hardware. There's generic code, machine specific configuration and codec code. All things must be configured / used / supported properly...

Adding Intel to Cc...
Comment 7 Jaroslav Kysela 2021-01-19 20:33:47 UTC
The Speaker / Headphone no sound issue is probably due to missing BIOS initialization. Apparently, the Windows driver initializes additional hardware (amplifier chips).

The SOF driver is used for the internal digital microphones for this machine.
Comment 8 Pierre Bossart 2021-01-19 20:41:03 UTC
This looks like a regular HDAudio + DMIC machine.

[  112.152028] sof-audio-pci 0000:00:1f.3: hda codecs found, mask 5

TGL-LP and TGL-H are different chipsets and as mentioned by Jaroslav you need a dedicated firmware file.

But in your case you have a regular TGL-LP chipset so things should work out of the box.

8086:a0c8 ->

#if IS_ENABLED(CONFIG_SND_SOC_SOF_TIGERLAKE)
	{ PCI_DEVICE(0x8086, 0xa0c8), /* TGL-LP */
		.driver_data = (unsigned long)&tgl_desc},
	{ PCI_DEVICE(0x8086, 0x43c8), /* TGL-H */
		.driver_data = (unsigned long)&tglh_desc},

#endif

Can you check if the headphone playback works? If yes, this could be a case where the speaker amplifiers are not configured properly, and this is a codec configuration issue. That's be my most likely source of issues if you can get sound with booting Windows first, it means there's an config beyond the scope of SOF that is not handled in Linux.

FWIW see also https://thesofproject.github.io/latest/getting_started/index.html#debugging-audio-issues-on-intel-platforms, that may give you some ideas to test further.
Comment 9 Pierre Bossart 2021-01-19 20:42:35 UTC
@Jaroslav, there is no initialization required for headphones, but if amplifiers are connected with an I2C link to the HDaudio codec, there's a need to set up those amps with an HDaudio command that configures the I2C. 

that's why I suggested testing different endpoints.
Comment 10 Alan Olsen 2021-01-20 17:20:33 UTC
Headphone jack works.

If it is a codec issue, who handles that?
Comment 11 Jaroslav Kysela 2021-01-20 17:24:25 UTC
BIOS or the driver. It may be tricky to obtain the right information. You may try contact the Realtek developer Kailang Yang (see sources - patch_realtek.c).
Comment 12 Pierre Bossart 2021-01-20 17:45:38 UTC
It's indeed tricky to find the settings on a lot of platforms with external amplifiers connected to the HDaudio codec, there are quite a few reports on issues with other OEMs. It gets worse when the amplifiers and HDaudio codecs are not from the same manufacturer...
Comment 13 Michael Plezbert 2021-02-10 07:07:39 UTC
I found this bug entry while trying to get the sound working on the exact same model of laptop (HP Spectre X360 14).

Based on some information I found while trying to fix this problem I discovered something that might help. If I run these commands (waiting a second between each command)

hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR 0x01
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x01
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x01
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00

then the speakers will work, but only as long as sound keep playing. If no sound is played for more than a few seconds then the speakers stop working until I run the commands again.

From what little I understand, I think this is turning on the amplifier. But I have not been able to figure out how to make it work permanently. Hopefully this will help someone who knows more about this than I do come up with a solution.
Comment 14 Takashi Iwai 2021-02-10 14:49:02 UTC
Aha, it's an interesting discovery.  So, it needs a on-off toggle, and it can't work only to turn the GPIO bit on, right?

If the toggle is really needed, a patch like below might work.
Comment 15 Takashi Iwai 2021-02-10 14:49:31 UTC
Created attachment 295187 [details]
Test patch
Comment 16 Pierre Bossart 2021-02-10 15:51:54 UTC
Comment unrelated to this specific issue, but as it turns out it seems that we have "HP Spectre X360 Convertible" devices that can be either with HDaudio or SoundWire. 

I've spent quite a bit of time fixing the SoundWire issues, see here:
https://github.com/thesofproject/linux/issues/2700

To make sure there's no interference between the two configurations, would you mind adding the following to /etc/modprobe/sof-dyndbg.conf (name does not matter, just location and extension), and then share the full dmesg log.

options snd_sof_intel_hda_common dyndbg=+p
options snd_sof_intel_hda dyndbg=+p
options snd_sof dyndbg=+p
options snd_sof_pci dyndbg=+p
options soundwire_bus dyndbg=+p
options soundwire_generic_allocation dyndbg=+p
options soundwire_cadence dyndbg=+p
options soundwire_intel_init dyndbg=+p
options soundwire_intel dyndbg=+p
options snd_soc_skl_hda_dsp dyndbg=+p
options snd_intel_dspcfg dyndbg=+p
Comment 17 Michael Plezbert 2021-02-11 01:07:37 UTC
Created attachment 295215 [details]
dmesg output

Here's the output from dmesg after creating /etc/modprobe/sof-dyndbg.conf as requested and rebooting.
Comment 18 Pierre Bossart 2021-02-11 15:40:20 UTC
(In reply to Michael Plezbert from comment #17)
> Created attachment 295215 [details]
> dmesg output
> 
> Here's the output from dmesg after creating /etc/modprobe/sof-dyndbg.conf as
> requested and rebooting.

Thanks for the test, much appreciated. The logs show there's no conflict, the BIOS does not advertise any SoundWire links:

[   75.885183] sof-audio-pci 0000:00:1f.3: skipping SoundWire, no links enabled

That was the part I was paranoid about, and the problem you have is squarely on the codec driver side (as suggested by Takashi's patch).
Comment 19 Michael Plezbert 2021-02-14 22:17:02 UTC
(In reply to Takashi Iwai from comment #15)
> Created attachment 295187 [details]
> Test patch

I managed to patch and build the current ubuntu kernel (5.8.0-43.49) and it works!

There was one problem with the patch. When I applied it, I got an error that it couldn't apply hunk #4 so I manually added the fourth change to what looked like the right location.
Comment 20 Takashi Iwai 2021-02-15 08:06:11 UTC
The patch was made for the very latest version, i.e. for 5.11 kernel, so yes, you might need some manual adjustment for applying to the older kernels.

I'm going to submit and merge the patch for 5.12-rc1.

Do you have any other issues than the amp problem fixed by this patch?
Comment 21 Michael Plezbert 2021-02-16 00:17:52 UTC
(In reply to Takashi Iwai from comment #20)
> The patch was made for the very latest version, i.e. for 5.11 kernel, so
> yes, you might need some manual adjustment for applying to the older kernels.
> 
> I'm going to submit and merge the patch for 5.12-rc1.
> 
> Do you have any other issues than the amp problem fixed by this patch?

No other issues related to sound, at least that I've found. There are a couple of other unrelated issues (keyboard not working for up to 30 seconds after boot and suspend not working properly) but I assume those should be reported as separate bugs.
Comment 22 Davide Depau 2021-02-26 13:38:22 UTC
Hi,

I have the same laptop. I noticed the attached patch has been merged in the current Linux master branch, I tested it and I can confirm that it does work.

However, neither with the patch nor with the hda-verb command sequence the top speakers are enabled - only the back/bottom ones. I see that a similar laptop with the ALC295 chip has a quirk in patch_realtek.c for what seems to be the same issue.

I'll provide the extra info requested above as soon as I can.

Regarding other issues I also experience the ~30 sec keyboard delay, and additionally (potential regression) the touchpad/touchscreen isn't detected on my build from master, it works on 5.11 (Arch Linux repo package). I will try to bisect this and open a new issue.
Comment 23 Michael Plezbert 2021-03-01 19:12:37 UTC
(In reply to Davide Depau from comment #22)
> Hi,
> 
> I have the same laptop. I noticed the attached patch has been merged in the
> current Linux master branch, I tested it and I can confirm that it does work.
> 
> However, neither with the patch nor with the hda-verb command sequence the
> top speakers are enabled - only the back/bottom ones. I see that a similar
> laptop with the ALC295 chip has a quirk in patch_realtek.c for what seems to
> be the same issue.
> 
> I'll provide the extra info requested above as soon as I can.
> 
> Regarding other issues I also experience the ~30 sec keyboard delay, and
> additionally (potential regression) the touchpad/touchscreen isn't detected
> on my build from master, it works on 5.11 (Arch Linux repo package). I will
> try to bisect this and open a new issue.

Sorry, I guess I was so excited that the sound worked at all that I didn't notice only some of the speakers were working.
Comment 24 Davide Depau 2021-03-10 00:24:57 UTC
Created attachment 295779 [details]
kernel log
Comment 25 Davide Depau 2021-03-10 00:25:25 UTC
Here is my kernel log as well, dumped with the modprobe.d config specified earlier in the thread, on Linux 5.11.2. At the end of the log you can find the output of dmidecode.

Here are the results of some things I tried.

What works out of the box as of 5.11.2:
- Microphone
- Headphone jack (including external mic)

What works with the attached patch applied, with the hda-verb GPIO toggle workaround posted earlier in the thread, or on 5.12-rc1 (rc2 untested)
- Back speakers

What doesn't work with any of the above:
- Front speakers
- Mic LED
- Mute LED

Not tested: HDMI audio

----

The microphone LED seems connected to GPIO 4, or whatever you call the GPIO controlled by the 4th bit counting from the LSB.

In fact, the following enables the mic mute LED (LSB is still set for the speakers workaround):

hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DIR  0x05
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_MASK 0x05

hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x00  # LED on
hda-verb /dev/snd/hwC0D0 0x01 SET_GPIO_DATA 0x04  # LED off


I was not able to find any GPIO that controls the mute LED.


For the front speakers: I enabled the legacy driver (options snd-intel-dspcfg dsp_driver=1) and played a little with hdajackretask (it seems to hang with SOF).

Default configuration:
- 0x17 [Internal Speaker] ⇒ Internal speaker
- 0x19 [Black Mic, Right side] ⇒ Microphone
- 0x21 [Headphone, Right side] ⇒ Headphone
- everything else not connected

I observed that:  (note: all of the below implies that the default 0x17 is retasked to "Not connected" when not specified)

- Retask 0x14 to "Internal speaker" ⇒ On PA restart, no sound. After mute/unmute, sound from front speakers. After GPIO LSB toggle workaround, sound from ALL speakers but on full blast, volume doesn't work
- Retask 0x1b, 0x1e to "Internal speaker" - Same behavior as no action (no sound on PA restart, back speakers work after performing workaround)

I also tested retasking pairs of devices to "Internal speaker (Back)" + "Internal speaker (LFE)" (which one is set to which doesn't seem to affect the results in a meaningful way).
I switched to Pipewire for this test, so I could easily redirect channels using Catia/Cadence, but I also verified the behavior does not change with PulseAudio after increasing its max channels to 4 and setting the audio profile to surround 4.0.

- 0x14 + 0x17: On PW restart, no sound. After mute/unmute sound from front speakers. After GPIO LSB toggle workaround sound from ALL speakers but on full blast, volume doesn't work

- 0x14 + 0x1e: On PW restart no sound, after mute/unmute front, after workaround ALL speakers with working volume control. However disconnecting channels with Catia reveals that both speaker sets are using the same set of channels, front if 0x14 is tasked to LFE, back otherwise. In fact, nothing changes if I select the stereo profile.

- Other combinations of the same sets of pins: no sound on PW start, only hda-verb workaround makes back speakers work. Volume works.

Finally, I also observed that the mic doesn't work with the legacy driver, but it does with SOF.
Comment 26 hottwaj 2021-09-10 08:53:13 UTC
Hi there, I have this laptop and am using it with Linux Mint (Ubuntu 20.04 derivative) and a 5.13 series kernel.

I was therefore expecting the patch mentioned above to make sound work out of the box, but I find that sound from the internal speakers does not work on a cold boot.

If I run the verb "hda-verb" commands listed above to activate the amplifier **while sound is playing**, then I hear sound.  

However once sound stops playing, if I then a few seconds later play another sound, I don't hear sound through the internal speaker anymore, and I have to re-run the "hda-verb" commands to get sound again.

An extra thing to consider: if I first boot into Windows and then soft-reboot into Linux, sound works all the time from the internal speakers and the "hda-verb" commands are never needed, even if i) sound is stopped for a while, or ii) I suspend the laptop (this laptop uses S0ix suspend).

So Windows must be doing some extra step to keep the amplifier working after initialising it?

I suspect it does not make a difference but I notice I am using a newer BIOS than originally reported by the OP Alan Olsen: HP Spectre x360 Convertible 14-ea0xxx/87F6, BIOS F.11 04/23/2021

Finally, I suspect this is off topic for this bug report, but I also experience the same issues reported by Davide Depau & Michael Plezbert:

- "hda-verb" commands and soft-reboot from Windows only activate the speakers at the front underside of the laptop, not the speakers next to the screen hinge

- Mic & speaker mute LEDs do not work

- Keyboard not working for up to 30 seconds after boot.  A temporary workaround until a better fix is available is to use "i8042.dumbkbd=1" in the args for booting your kernel - see e.g. discussion here and note that this workaround prevents keyboard caps-lock light from working https://bbs.archlinux.org/viewtopic.php?id=261108&p=2

- Suspend issues. I find that the laptop will enter suspend and come out of it when you press a key/open the lid, but about 50% of the time when I suspend the laptop it will silently come straight back out of suspend (i.e. screen stays off until a key is pressed/lid lifted), and will feel warm when picked up after several hours.  If this happens then battery drain during the time I thought it was suspended is significant, and looking at system logs the laptop clearly only remained suspended for a moment before something woke it back up.

Anyway the sound issue is the biggest problem for me and that is what this thread is for :)
Comment 27 hottwaj 2021-09-10 14:20:17 UTC
It seems that another recent HP model had a similar issue with the amplifier getting switched off once no sound is played for a while.  https://bugzilla.kernel.org/show_bug.cgi?id=212873

A working patch has been proposed there by Takashi.

Maybe something similar is also needed for the HP Spectre 14 we are discussing here?

Though it seems other users of the HP Spectre 14 in this thread did not have the issue I'm having and were happy with the already implemented patch for the Spectre 14?

Thanks
Comment 28 hottwaj 2021-09-20 20:27:25 UTC
After some further investigation I found that my HP Spectre 14 has a slightly different subvendor ID to the one listed in the original patch above by Takashi in comment #15

The subvendor ID in Takashi's patch is 0x87f7, while the one on my HP Spectre 14 (which also seems to be using the Realtek 245 codec) is 0x87f6.  

See some snippets from alsa-info below.

!!DMI Information
!!---------------

Manufacturer:      HP
Product Name:      HP Spectre x360 Convertible 14-ea0xxx
Product Version:   
Firmware Version:  F.11
System SKU:        2Z6X7EA#ABU
Board Vendor:      HP
Board Name:        87F6

!!HDA-Intel Codec information
!!---------------------------

Codec: Realtek ALC245
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0245
Subsystem Id: 0x103c87f6
Revision Id: 0x100001


I therefore found that adding the quirk below to patch_realtek.c got audio working for my laptop:

SND_PCI_QUIRK(0x103c, 0x87f6, "HP Spectre x360 14", ALC245_FIXUP_HP_X360_AMP),

This was all that was needed, despite what I was wondering in my previous comment #27.

Would it help for me to submit a patch or is this enough info to go by?

Thanks!
Comment 29 hottwaj 2021-10-20 20:22:35 UTC
Created attachment 299281 [details]
patch for HP x360 14 top/rear speaker & mic/mute leds

I did a bit of work trying to get the top/rear speaker working in addition to the bottom/front speaker (which is the only one working with current kernel), and eventually have had success - see patch attached.  I also got the mic and micmute LEDs working

Like Davide mentioned in #25 I initially found that enabling the top/rear speaker at 0x14 made the volume control stop working for the bottom/front speaker (it got locked at full volume)

I eventually found the Realtek diagnostic program "RtHDDump" mentioned in [1], and when running it in Windows found that the bottom/front speaker (0x17) is only connected to the amplifier 0x02, whereas on Linux it defaults to connection 0x02, 0x03, 0x06.  That connection list seems to cause speaker 0x17 to get locked at full volume when used in conjunction with 0x14.  The attached patch therefore forces use of only amp 0x02 for speaker 0x17.

For the mic and micmute LEDs, Davide had already found the micmute verbs in #25, and I found the mute verbs using a "verb-sniffing" tool and qemu+windows - see [2].  Note that the micmute keyboard button doesn't work without adding something to /lib/udev/hwdb.d but if I use the gnome sound mixer program to mute the mic the light comes on with this patch.

[1] https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1852922
[2] https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver

p.s. I found that someone else had already noticed that subsystem 0x103c87f6 needed the same x360 14 patch mentioned in my previous post #28.  Hopefully I'm not late to the game on this speaker stuff too :)
Comment 30 hottwaj 2021-10-20 20:35:58 UTC
Created attachment 299283 [details]
qemu "verb-sniffing" output

This is from a boot of windows running in qemu, I played some sounds, muted sound and mic on/off a couple of times, then shutdown.  Apart from finding the verbs for micmute, I wasn't able to get anything else interesting when replaying verbs from this.
Comment 31 hottwaj 2021-10-20 20:37:20 UTC
Created attachment 299285 [details]
RtHDDump output

RtHDDump output on Windows while playing sound at full volume
Comment 32 David Greengas 2022-03-11 20:29:04 UTC
I have the following version:
!!DMI Information
!!---------------

Manufacturer:      HP
Product Name:      HP Spectre x360 Convertible 14t-ea100
Product Version:   
Firmware Version:  F.25
System SKU:        446B0AV
Board Vendor:      HP
Board Name:        89DA

Notice that it is 89DA and not 87F6 like #28

The sound card is detected, but sound does not work from any speaker. I only booted Windows long enough to update the BIOS and remove it.

I am not sure if the existing Spectre quirks for the ALC245 patches work.

Here is a link to my alsa-info:
http://alsa-project.org/db/?f=c4361509ac6e34a6c2de2eec7e819e05df932fe4
I did have another usb sound card plugged in when running the script.
Comment 33 David Greengas 2022-03-14 22:57:53 UTC
(In reply to David Greengas from comment #32)
> I have the following version:
> !!DMI Information
> !!---------------
> 
> Manufacturer:      HP
> Product Name:      HP Spectre x360 Convertible 14t-ea100
> Product Version:   
> Firmware Version:  F.25
> System SKU:        446B0AV
> Board Vendor:      HP
> Board Name:        89DA
> 
> Notice that it is 89DA and not 87F6 like #28
> 
> The sound card is detected, but sound does not work from any speaker. I only
> booted Windows long enough to update the BIOS and remove it.
> 
> I am not sure if the existing Spectre quirks for the ALC245 patches work.
> 
> Here is a link to my alsa-info:
> http://alsa-project.org/db/?f=c4361509ac6e34a6c2de2eec7e819e05df932fe4
> I did have another usb sound card plugged in when running the script.

I have an update. I was able to get just the bottom speaker when I used the hda-verb command while audio was playing. For example, I started a video on YouTube and, while it was playing, I ran the 3 hda-verb commands with a 2 second sleep between each one. After the last command, the bottom speaker was working. If I went back in my browser to choose a different video, the sound would not work again. It seems like there is some timeout value that causes it toggle.
Comment 34 Marc Doughty 2022-06-15 14:50:46 UTC
Adding an additional alsa-info output from latest revision hardware:

http://alsa-project.org/db/?f=0bdf8fdc84b2fec6bdd70a0394995bd021672265