Audio jack stopped working

I am getting close to ordering a DAC, but I don’t think this is the problem with the audio output because it was working fine on Fedora for a few weeks. Now I have moved to Silverblue, the audio still is not working.

00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)

systemctl status --user pipewire pipewire-pulse wireplumber

I have the UEFI BIOS onboard audio set to HD, as it was when it worked previously.

There is a new post that is quite similar mhayden/python-opentelemetry but I did not want to break into it, so I am creating a new thread.

Thanks in advance.

If the sound device suddenly stopped working on Fedora Linux, I would suspect that a kernel upgrade caused the problem and would suggest just sticking with the older kernel until the problem is resolved. Unfortunately, if you’ve already reformatted with Silverblue, that probably isn’t an option.

I’m not familiar with Silverblue, so you’ll have to wait until someone more familiar with that system jumps in. But if it “used to work” on Fedora Linux, I’d still try going back to an older kernel before trying anything else (but again, I don’t know the commands to do that under Silverblue).

1 Like

I appreciate your answer, and prefer to stay with Silverblue. What did my lspci output tell you? Can you some suggest different parameters that could be parsed based on that output?

I have had luck in the past getting the audio jacks on one of my Lenovo systems working by passing an extra model=... option to the snd_hda_intel driver. It’s not always the solution. But, based on the documentation, there do appear to be a lot of quirky sound devices out there that may require special parameters to work properly. If you want to try those options, you certainly can. But first you need to verify that your hardware uses that sound driver. lspci -v should provide more details about what sound devices your system has and what driver they are using.

Edit: I just noticed that there is a really good write up about debugging audio problems here: notes.rst - Documentation/sound/hd-audio/notes.rst - Linux source code (v6.1) - Bootlin

1 Like

I really appreciate the link. It is so pedagogically written, even I can understand it.

here is lspci -v

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, fast devsel, latency 0
	Capabilities: <access denied>
	Kernel driver in use: ivb_uncore
	Kernel modules: ie31200_edac

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 26
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: [disabled] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
	DeviceName:  Onboard IGD
	Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 30
	Memory at f7800000 (64-bit, non-prefetchable) [size=4M]
	Memory at e0000000 (64-bit, prefetchable) [size=256M]
	I/O ports at f000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: <access denied>
	Kernel driver in use: i915
	Kernel modules: i915

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, medium devsel, latency 0, IRQ 29
	Memory at f7d00000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd

00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 32
	Memory at f7d1a000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
	Kernel modules: mei_me

00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f7d18000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04)
	Subsystem: ASUSTeK Computer Inc. Device 841b
	Flags: bus master, fast devsel, latency 0, IRQ 33
	Memory at f7d10000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: [disabled] [16-bit]
	Memory behind bridge: [disabled] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: e000-efff [size=4K] [16-bit]
	Memory behind bridge: [disabled] [32-bit]
	Prefetchable memory behind bridge: f0000000-f00fffff [size=1M] [32-bit]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4) (prog-if 00 [Normal decode])
	Subsystem: ASUSTeK Computer Inc. Device 84ca
	Flags: bus master, fast devsel, latency 0, IRQ 18
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: d000-dfff [size=4K] [16-bit]
	Memory behind bridge: f7c00000-f7cfffff [size=1M] [32-bit]
	Prefetchable memory behind bridge: [disabled] [64-bit]
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #1 (rev 04) (prog-if 20 [EHCI])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, medium devsel, latency 0, IRQ 23
	Memory at f7d17000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8H77-I Motherboard
	Flags: bus master, medium devsel, latency 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich
	Kernel modules: lpc_ich

00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 27
	I/O ports at f0b0 [size=8]
	I/O ports at f0a0 [size=4]
	I/O ports at f090 [size=8]
	I/O ports at f080 [size=4]
	I/O ports at f060 [size=32]
	Memory at f7d16000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci

00:1f.3 SMBus: Intel Corporation 7 Series/C216 Chipset Family SMBus Controller (rev 04)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: medium devsel, IRQ 18
	Memory at f7d15000 (64-bit, non-prefetchable) [size=256]
	I/O ports at f040 [size=32]
	Kernel driver in use: i801_smbus
	Kernel modules: i2c_i801

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
	Subsystem: ASUSTeK Computer Inc. P8 series motherboard
	Flags: bus master, fast devsel, latency 0, IRQ 16
	I/O ports at e000 [size=256]
	Memory at f0004000 (64-bit, prefetchable) [size=4K]
	Memory at f0000000 (64-bit, prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: r8169
	Kernel modules: r8169

04:00.0 IDE interface: Marvell Technology Group Ltd. 88SE9172 SATA III 6Gb/s RAID Controller (rev 11) (prog-if 8f [PCI native mode controller, supports both channels switched to ISA compatibility mode, supports bus mastering])
	Subsystem: ASUSTeK Computer Inc. Device 8477
	Flags: bus master, fast devsel, latency 0, IRQ 28
	I/O ports at d040 [size=8]
	I/O ports at d030 [size=4]
	I/O ports at d020 [size=8]
	I/O ports at d010 [size=4]
	I/O ports at d000 [size=16]
	Memory at f7c10000 (32-bit, non-prefetchable) [size=512]
	Expansion ROM at f7c00000 [disabled] [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: ahci
	Kernel modules: pata_acpi, ata_generic

So yeah, your sound card is using the snd_hda_intel driver and creating a conf file under /etc/modprobe.d containing options snd-hda-intel model=<something> might workaround known glitches.

I learned a bit from reading that document just now as well.

What does the following command show?

sudo head -n 5 /proc/asound/card*/codec#*

I think it should give the codec that you can use to lookup applicable quirk modes on this page: models.rst - Documentation/sound/hd-audio/models.rst - Linux source code (v6.1) - Bootlin

==> /proc/asound/card0/codec#0 <==
Codec: Realtek ALC892
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0892
Subsystem Id: 0x1043841b

==> /proc/asound/card0/codec#3 <==
Codec: Intel PantherPoint HDMI
Address: 3
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x80862806
Subsystem Id: 0x80860101

The audio stopped shortly after the 6.1 point releases when I first installed Fedora WS. I had nothing to lose by formatting it with Silverblue and still no audio, but I was hooked on Silverblue and its advantages over mutable systems. I know its going to be more difficult to debug in Silverblue. Thanks for your help @glb

So you are the second person to report problems with the ALC892 codec on this forum this week. It looks like there is some recent activity on the kernel.org bugzilla that matches that identifier. You might find some hints about what is going on there.

https://bugzilla.kernel.org/show_bug.cgi?id=205045

Edit: There is also an older (but also unresolved) bug report where someone commented that they were able to get this chip to work on older kernels if they disabled jack detection using a udev rule.

From 208061 – snd_hda_intel: regression on ALC892 - no sound

ACTION=="add", SUBSYSTEM=="sound", ATTRS{chip_name}=="ALC892", ATTR{hints}="jack_detect=false"

It’s way beyond my pay grade to troubleshoot.
I am thinking of buying a USB to audio jack sound adapter
Is there anything else, as an end user I can do to fix this?

Above mine too really. It looks like even the kernel hackers are struggling to get this thing working. Were I you, I’d probably spend the €12 on a USB adapter and be done with it.

If you want to create a /etc/udev/rules.d/10-alc892.rules file containing the line I mentioned in the previous post, there is a small chance that that might actually work, but I wouldn’t hold my breath.

I’m game, since I can always rollback.
Which contents in “previous post” aare you referring to?
I looked at the notes.rst you posted, but could not see it in there.

I think this line in a udev rule might do it.

ACTION=="add", SUBSYSTEM=="sound", ATTRS{chip_name}=="ALC892", ATTR{hints}="jack_detect=false"

Then you would need to reboot to be sure it is activated. (Running udevadm trigger should activate it without rebooting if you want to try that.)

I’m just going by what was stated in one of the bug reports. Someone said that that rule caused a ALC892 device to work on a system once upon a time.

Also, this link was recently shared in a similar thread about ALC892 woes. You could try the suggestions there if you feel up to it.

https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#:~:text=This%20will%20typically%20work%20for%20speakers%20and%20headphones/headsets%2C%20but%20will%20not%20allow%20DMIC%20capture

Thanks for the udev rule. It did bring the test option back on the sound setiings, but still did not give any output in either the front or back audio output jacks. Nice try though, it looked hopeful, but guess these ALC892 are a real problem across Linux from what I am reading.

I will give the last link a try tomorrow and post the results here.

I’m getting that impression as well. I don’t have one though, so I don’t know for sure.

BTW, if that udev rule seems to have improved the situation, I’d leave it in place while trying other workarounds. (Yes, it is quite possible that some convoluted combination of multiple simultaneous workarounds might be required to get the device to work. :confused:)

The strange thing I find is how it was working before without a udev rule. Still, I have left the file there.

That a bit beyond me, but thanks for your suggestions.

I see these were updated:

pipewire 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-alsa 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-gstreamer 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-jack-audio-connection-kit 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-libs 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-pulseaudio 0.3.65-1.fc37 → 0.3.66-1.fc37
pipewire-utils 0.3.65-1.fc37 → 0.3.66-1.fc37