You might need to have alsa-sof-firmware installed.

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?

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?

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.)

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?

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...

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.

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.

@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.

Headphone jack works.

If it is a codec issue, who handles that?

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).

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...

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.

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.

Created attachment 295187 [details]
Test patch

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

Created attachment 295215 [details]
dmesg output

Here's the output from dmesg after creating /etc/modprobe/sof-dyndbg.conf as requested and rebooting.

(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).

(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.

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?

(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.

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.

(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.

Created attachment 295779 [details]
kernel log

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.

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 :)

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

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!

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 :)

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.

Created attachment 299285 [details]
RtHDDump output

RtHDDump output on Windows while playing sound at full volume

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.

(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.

Adding an additional alsa-info output from latest revision hardware:

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