The pci device id 8086:7a50 (aka Intel High Definition Audio Controller) is not supported by snd_hda. It seems to affect Dell G16-7630 and my Razer Blade-16_2023. Thank you,
(In reply to valery from comment #0) Can you run `pciconf -lv` and show me the entry for this device? ID 72a50 is indeed not present in snd_hda (the HDA sound driver).
Thank you for your interest, Could you read this (still under approval): https://bsd-hardware.info/?probe=d81973c8bc&log=pciconf If not, here the output for the HDA device: none7@pci0:0:31:3: class=0x040100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7a50 subvendor=0x1a58 subdevice=0x3006 vendor = 'Intel Corporation' class = multimedia subclass = audio bar [10] = type Memory, range 64, base rx625c140000, size 16384, enabled bar [20] = type Memory, range 64, base rx625c000000, size 1048576, enabled cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 09[80] = vendor (length 20) Intel cap 15 version 0 cap 05[60] = MSI supports 1 message, 64 bit At your disposal for more information, I can apply patches and provide test and debug infos without any trouble, Thanks,
I am trying to figure out the model name (e.g "Kaby Lake", "Wellsburg", ...) of this device but cannot find anything, do you know it?
https://admin.pci-ids.ucw.cz/read/PC/8086/7a50 tells us: "Raptor Lake Intel High Definition Audio Controller" IIRC, most of the main Linux distros are facing some trouble in order to make it works. FYI, this device implement THX Audio (as promoted by Razer), I don't know if this lead to some DRM or could prevent implementation. The laptop is very new (2023), it makes sense our HDA driver do not recognize it yet. Good news, everything but bluetooth work very well with FreeBSD-14, I didn't expected this. It could be so nice to get audio too ... This audio chip features many other recent laptop, like some Dell G series and some Lenovo too.
Created attachment 247745 [details] hdac_devices patch Can you apply and test this patch? I doubt it'll work, but it should at least attach to snd_hda. Hopefully it doesn't crash...
Created attachment 247747 [details] hdac.patch.output result after applying the patch, you will find here : dmesg sndstat mixer /dev I cannot find any pcm device in order to test it.
FYI: 'sox::play somefile.wav' open the dsp0.0 as reported as the default one without error during process, but cannot ear no sound on the speakers (mixer level at max). I tried a 'cat /dev/random > /dev/dsp0.0', same result.
(In reply to valery from comment #7) It attaches to the driver at least, so that's a good thing. Can you post the dmesg output after you run: # sysctl dev.hdac.0.pindump=1 There might be some non-standard pin mappings, as is the case for many other HDA cards.
Also try to see if there's sound coming out from the headphone jack.
Created attachment 247756 [details] dev.hdac0 sysctl pindump=1 The pindump attached as required. The sound WORKS on the headphone jack output, and I have to say it is really great ! I tried the mixer level 'vol' and 'pcm' during the play, both without trouble. That's a great step, thank you so much.
(In reply to valery from comment #10) Seems like a pin-mapping issue. Try adding the following line to /boot/device.hints and rebooting: hint.hdac.0.cad0.nid23.config="as=1 seq=15" If it works we can patch snd_hda to do this automatically.
Alternatively, try (add both of them): hint.hdac.0.cad0.nid23.config="as=1 seq=0" hint.hdac.0.cad0.nid33.config="as=1 seq=15"
Thanks, but unfortunately it doesn't work. After some fight (for some obscure reasons, nvidia hdmi took the hdac0, our guy is now hdac1 ...), applying the hints at boot time, and the pindump match your configuration as well. sndstat report our guy as the default player, sysctl as well, and the headphone jack output is working (with still such a great sound, never ear that on a laptop ! :D) hdaa1: Dumping AFG pins: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 18 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: Caps: IN hdaa1: 19 40000000 0 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa1: Caps: IN hdaa1: 20 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: Caps: OUT EAPD hdaa1: 23 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa1: Caps: OUT HP EAPD Sense: 0x00000000 (disconnected) hdaa1: 24 04a11030 3 0 Mic Jack 1/8 Right Black 0 hdaa1: Caps: IN VREF Sense: 0x00000000 (disconnected) hdaa1: 25 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: Caps: IN VREF Sense: 0x80000000 (connected) hdaa1: 26 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: Caps: IN OUT HP EAPD VREF Sense: 0x00000000 (disconnected) hdaa1: 30 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: Caps: OUT Sense: 0x00000000 (disconnected) hdaa1: 31 411111f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa1: Caps: IN Sense: 0x00000000 (disconnected) hdaa1: 33 0421101f 1 15 Headphones Jack 1/8 Right Black 0 hdaa1: Caps: OUT HP Sense: 0x00000000 (disconnected) hdaa1: NumGPIO=8 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
(In reply to valery from comment #13) ... and I tried both of your fixes, #11 & #12, alternatively.
(In reply to valery from comment #13) Can you try (If the card is on hdac1, replace "hdac.0" with "hdac.1"): hint.hdac.0.cad0.nid33.config="as=2 seq=15" After you apply it, test both the speakers and the headphones.
(In reply to Christos Margiolis from comment #15) Remove the previous hints, of course.
Created attachment 247789 [details] Intel OEM INF File PCI_VEN_8086&DEV_7A50 pnputil.exe /enum-devices /bus PCI /deviceids Instance ID: PCI\VEN_8086&DEV_7A50&SUBSYS_30061A58&REV_11\3&11583659&1&FB Device Description: Intel® Smart Sound Technology BUS Class Name: System Class GUID: {4d36e97d-e325-11ce-bfc1-08002be10318} Manufacturer Name: Intel(R) Corporation Status: Started Driver Name: oem1.inf Extension Driver Names: oem40.inf Hardware IDs: PCI\VEN_8086&DEV_7A50&SUBSYS_30061A58&REV_11 PCI\VEN_8086&DEV_7A50&SUBSYS_30061A58 PCI\VEN_8086&DEV_7A50&CC_040100 PCI\VEN_8086&DEV_7A50&CC_0401
Your last settings didn't work, sorry. After some search, I attached (above comment) the 'oem.inf' file provided by Intel for WIndows arch. From "oem.txt", line #116 seems to provide what you are looking for, but I have no skills on this, I could be wrong. Hope this help, Val.
Created attachment 247800 [details] sysctl output for dev.hdaa.1 If this could help, I provide the output from sysctl for hdaa.1 from which you will find a summary on how the device is implemented by your hda driver.
Christos, are you still looking at this? Would it make sense to at least commit the PCI ID patch?
(In reply to Mark Johnston from comment #20) I haven't had time to look at it the past 2-3 days, but have been exchanging private emails with Valery to figure out a solution, although with not much success yet. I agree it'd be good to at least have the ID patch committed, but we should note that speakers and mic do not work yet.
Still experiencing this issue on FreeBSD 14.2 STABLE. none11@pci0:0:31:3: class=0x040100 rev=0x11 hdr=0x00 vendor=0x8086 device=0x7a50 subvendor=0x103c subdevice=0x8bb3 vendor = 'Intel Corporation' device = 'Raptor Lake High Definition Audio Controller' class = multimedia subclass = audio
(In reply to Dudley Innocent from comment #22) Can you test if the following patch addresses your issue? https://reviews.freebsd.org/D49389
(In reply to Christos Margiolis from comment #23) Already done, see comments/patches above.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=fc40132603f5133037a35e2c14ac1356a0128c50 commit fc40132603f5133037a35e2c14ac1356a0128c50 Author: Christos Margiolis <christos@FreeBSD.org> AuthorDate: 2025-03-19 18:18:37 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2025-03-19 18:18:37 +0000 snd_hda: Support Intel Raptor Lake 0x7a50 PR: 276379 Sponsored by: The FreeBSD Foundation MFC after: 1 week Reviewed by: emaste, markj Differential Revision: https://reviews.freebsd.org/D49389 sys/dev/sound/pci/hda/hdac.c | 1 + sys/dev/sound/pci/hda/hdac.h | 1 + 2 files changed, 2 insertions(+)
(In reply to valery from comment #24) My comment about testing the patch was meant for the other commenter, to see if at least his device at least attaches with it.