I encountered an issue where there was no default audio output on device 0x43c8 in FreeBSD. To resolve this, I modified the HDA module, adding the device using the definition: #define HDA_INTEL_TGLH HDA_MODEL_CONSTRUCT(INTEL, 0x43c8). Additionally, I redirected the pin output using "hints devices" during boot with specific configurations: hint.hdaa.0.nid20.config="as=1 seq=1 device=Line-out" hint.hdaa.0.nid27.config="as=1 seq=2 device=Line-out" These changes successfully fixed the bug, and audio output now works flawlessly without the need for manual adjustments during boot.
Created attachment 251434 [details] Tiger Lake-H HD Audio Controller support Adds support for Tiger Lake-H HD Audio Controller, e.g.: none5@pci0:0:31:3: class=0x040100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x43c8 subvendor=0x17aa subdevice=0x22e5 vendor = 'Intel Corporation' device = 'Tiger Lake-H HD Audio Controller' class = multimedia subclass = audio Becomes: hdac1@pci0:0:31:3: class=0x040100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x43c8 subvendor=0x17aa subdevice=0x22e5 vendor = 'Intel Corporation' device = 'Tiger Lake-H HD Audio Controller' class = multimedia subclass = audio
(In reply to Adam Retter from comment #1) I tested this on a Lenovo ThinkPad X1 Extreme Gen 4
(In reply to Adam Retter from comment #1) Thank you, I will merge this patch in. Can you attach a git format patch please? (Or, confirm git --author="Adam Retter <adam.retter@googlemail.com>" is acceptable.)
Ed, that is the correct author for me. However, it is really Miguel Salcedo's work, I only did the work to format what he already had as a patch. Also I am experiencing a small issue with the internal mic, see: https://lists.freebsd.org/archives/freebsd-multimedia/2024-June/002411.html I am not sure if that should stop this or not, it may just be a /boot/device.hints issue that I have with my specific Laptop, I am hoping someone can tell me...
(In reply to Adam Retter from comment #4) You wrote the patch that I'm committing, so are the appropriate author. The internal mic not working sounds like PR242527, an issue I encountered on my Lenovo X1 Carbon 7th gen. I haven't looked at the device number / routing issue yet; hopefully Christos can comment.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fb1028dcd4aedc4d48dbd97314f008c663b2e711 commit fb1028dcd4aedc4d48dbd97314f008c663b2e711 Author: Adam Retter <adam.retter@googlemail.com> AuthorDate: 2024-06-14 15:57:15 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2024-06-14 16:24:59 +0000 hda: add support for Tiger Lake-H PR: 272682 Reported by: Miguel Salcedo Reviewed by: emaste sys/dev/sound/pci/hda/hdac.c | 1 + sys/dev/sound/pci/hda/hdac.h | 2 ++ sys/dev/sound/pci/hda/hdacc.c | 1 + 3 files changed, 4 insertions(+)
Not that I am objecting the change, but it makes me wonder why is it even needed at all for more than cosmetic purposes? IIRC HDA controllers should be detected just based on the PCI class value. Is there something special about this Tiger Lake-H HD Audio Controller why it is not reported and standard HDA?
(In reply to Alexander Motin from comment #7) I am afraid that they were not detected correctly before this patch. "Intel Tiger Lake-H HD Audio Controller" is detected as class=multimedia (04h) and subclass=audio (01h). Whereas hda is normally class=multimedia (04h) and subclass=hda (03h). See section 1.5 here - https://pcisig.com/sites/default/files/files/PCI_Code-ID_r_1_11__v24_Jan_2019.pdf
Right. But what made Intel to report them differently? Do they violate HDA specs in some way? Do they need special handling as result?
(In reply to Alexander Motin from comment #9) Good question! I am afraid that all of this is way outside of my knowledge base. I can try and learn, but I don't know the answer yet. I simply applied a proposed patch and tested it and apart from the internal-mic, everything else seemed to work nicely. Whereas before this patch, nothing worked for me. So I admit I did a bit of a "just try it and hope", but I think it is practically at least a step forward.
One point is that we need to implement DSP support (see https://www.sofproject.org/) and may then need specific handling for these devices. As far as I can tell from a quick look at the Linux source there's a device match entry for this, only under #if IS_ENABLED(CONFIG_SND_SOC_SOF_TIGERLAKE). I have no idea on Linux configured w/o CONFIG_SND_SOC_SOF_TIGERLAKE if these devices attach and work based on class (but without a functional DMIC) or do not work at all.