Rocky Linux 9.1 sound issues

I’m hoping wiser minds than mine can help with my issue of getting sound working on RL9.1.

After the initial install and patching, sound wasn’t working at all. This was not an issue at the time (as I was more concerned about 3D printing issues which necessitated moving from RL8.6 to RL9.1).

It took some research but I found this CentOS forum post:

https://forums.centos.org/viewtopic.php?f=55&t=79067

and I tried the commands suggested:

11 colin@kuu> systemctl --user enable pipewire
Created symlink /home/colin/.config/systemd/user/default.target.wants/pipewire.service → /usr/lib/systemd/user/pipewire.service.
Created symlink /home/colin/.config/systemd/user/sockets.target.wants/pipewire.socket → /usr/lib/systemd/user/pipewire.socket.
12 colin@kuu> systemctl --user enable pipewire-pulse
Created symlink /home/colin/.config/systemd/user/default.target.wants/pipewire-pulse.service → /usr/lib/systemd/user/pipewire-pulse.service.
Created symlink /home/colin/.config/systemd/user/sockets.target.wants/pipewire-pulse.socket → /usr/lib/systemd/user/pipewire-pulse.socket.
13 colin@kuu> systemctl --user enable wireplumber
Created symlink /home/colin/.config/systemd/user/pipewire-session-manager.service → /usr/lib/systemd/user/wireplumber.service.
Created symlink /home/colin/.config/systemd/user/pipewire.service.wants/wireplumber.service → /usr/lib/systemd/user/wireplumber.service.
14 colin@kuu> systemctl --user enable pipewire.socket
15 colin@kuu> systemctl --user enable pipewire-pulse.socket

Then I rebooted the machine. After this, I can at least get successful sound tests through the KDE and Gnome control panels. I have not tried anything more complex. WAV files play through aplay but I can’t get mp3’s to play.

My main concern is that my headphones, which worked under RL8, are no longer being detected. It’s like the headphone jack isn’t switched on.

Here are the packages installed:

69 root@kuu# rpm -qa | grep pulseaudio
pulseaudio-libs-15.0-2.el9.x86_64
pulseaudio-libs-glib2-15.0-2.el9.x86_64
pulseaudio-utils-15.0-2.el9.x86_64
pipewire-pulseaudio-0.3.47-2.el9.x86_64
kde-settings-pulseaudio-35.0-2.el9.1.noarch
70 root@kuu# rpm -qa | grep pipewire
pipewire-0.3.47-2.el9.x86_64
pipewire-libs-0.3.47-2.el9.x86_64
pipewire-pulseaudio-0.3.47-2.el9.x86_64
pipewire-gstreamer-0.3.47-2.el9.x86_64
pipewire-utils-0.3.47-2.el9.x86_64
pipewire-jack-audio-connection-kit-0.3.47-2.el9.x86_64
pipewire-alsa-0.3.47-2.el9.x86_64
71 root@kuu#

What gets me wondering is that PipeWire and PulseAudio are clashing in some way?

So, I ask the Community: is there a simple fix for this? Or do you need more debugging information to dig deeper?

Best Regards,
Colin

I’ve tried more research and testing. Here’s what I have so far:

systemctl lists running services. But root can’t see anything:

86 root@kuu# systemctl list-units --type=service | grep -i pipewire
87 root@kuu# systemctl list-units --type=service | grep -i pulseaudio
88 root@kuu#

As a normal user:

55 colin@kuu> systemctl --user | grep pipewire
  pipewire-pulse.service                                                                   loaded active running PipeWire PulseAudio
  pipewire.service                                                                         loaded active running PipeWire Multimedia Service
  pipewire-pulse.socket                                                                    loaded active running PipeWire PulseAudio
  pipewire.socket                                                                          loaded active running PipeWire Multimedia System Socket
56 colin@kuu> systemctl --user | grep pulseaudio
57 colin@kuu>

So pipewire is running as colin but pulseaudio isn’t.

According to

https://www.reddit.com/r/archlinux/comments/m7yc6j/pipewire_0324_no_audio_devices_found/

"I similarly had no devices found after updating Pipewire, this morning. Logs provided some snippets to search-upon, and eventually I learned that pipewire-media-session recently was extracted from the original pipewire service, necessitating some configuration changes in the packages’ default configurations. Pacman apparently doesn’t overwrite what’s already there, so it was expedient to clear out the extant configurations, and let the package manager install new defaults.

The advice I followed was to:

Remove all the configuration files in /etc/pipewire (sudo mv /etc/pipewire /tmp)

Reinstall pipewire, pipewire-pulse, and pipewire-media-session (sudo pacman -S pipewire pipewire-pulse pipewire-media-session)

Enable and start the relevant services (systemctl --user enable pipewire pipewire-pulse pipewire-media-session) and (systemctl --user restart pipewire pipewire-pulse pipewire-media-session). After that, my devices appeared as usual and I was back in business.

Perhaps someone else has a better write-up, but I just wanted to share what I did to return to status quo."

This is from an ArchLinux forum, so I haven’t progressed beyond the next couple of steps:

12 root@kuu# rpm -qa | grep pipewire
pipewire-0.3.47-2.el9.x86_64
pipewire-libs-0.3.47-2.el9.x86_64
pipewire-pulseaudio-0.3.47-2.el9.x86_64
pipewire-gstreamer-0.3.47-2.el9.x86_64
pipewire-utils-0.3.47-2.el9.x86_64
pipewire-jack-audio-connection-kit-0.3.47-2.el9.x86_64
pipewire-alsa-0.3.47-2.el9.x86_64
13 root@kuu#
13 root@kuu# dnf list available | grep pipewire-media-session
14 root@kuu#

So pipewire-media-session isn’t available in the Rocky repos. It is available in the CentOS 9 AppStream at:

https://centos.pkgs.org/9-stream/centos-appstream-x86_64/pipewire-media-session-0.3.32-3.el9.x86_64.rpm.html

Is this worth trying?

I’ve also looked at the kernel modules:

2 root@kuu# lsmod | grep -E "snd|audio"
snd_seq_dummy          16384  0
snd_hrtimer            16384  1
snd_soc_skl_hda_dsp    24576  5
snd_soc_intel_hda_dsp_common    20480  1 snd_soc_skl_hda_dsp
snd_sof_probes         24576  0
snd_soc_hdac_hdmi      45056  1 snd_soc_skl_hda_dsp
snd_hda_codec_hdmi     81920  1
snd_hda_codec_realtek   167936  1
snd_hda_codec_generic    98304  1 snd_hda_codec_realtek
snd_soc_dmic           16384  1
snd_sof_pci_intel_cnl    16384  0
snd_sof_intel_hda_common   114688  1 snd_sof_pci_intel_cnl
soundwire_intel        45056  1 snd_sof_intel_hda_common
snd_sof_intel_hda      20480  1 snd_sof_intel_hda_common
snd_sof_pci            24576  2 snd_sof_intel_hda_common,snd_sof_pci_intel_cnl
snd_sof_xtensa_dsp     16384  1 snd_sof_intel_hda_common
snd_sof               196608  3 snd_sof_pci,snd_sof_intel_hda_common,snd_sof_probes
snd_sof_utils          20480  1 snd_sof
ledtrig_audio          16384  2 snd_hda_codec_generic,snd_sof
snd_soc_skl           188416  0
snd_soc_hdac_hda       24576  2 snd_sof_intel_hda_common,snd_soc_skl
snd_hda_ext_core       36864  5 snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_soc_skl,snd_sof_intel_hda
snd_soc_sst_ipc        20480  1 snd_soc_skl
snd_soc_sst_dsp        40960  1 snd_soc_skl
snd_soc_acpi_intel_match    65536  3 snd_sof_intel_hda_common,snd_soc_skl,snd_sof_pci_intel_cnl
snd_soc_acpi           16384  3 snd_soc_acpi_intel_match,snd_sof_intel_hda_common,snd_soc_skl
snd_soc_core          344064  9 soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_soc_skl,snd_sof_probes,snd_soc_dmic,snd_soc_skl_hda_dsp
snd_compress           28672  2 snd_soc_core,snd_sof_probes
snd_hda_intel          57344  0
snd_intel_dspcfg       32768  3 snd_hda_intel,snd_sof_intel_hda_common,snd_soc_skl
snd_intel_sdw_acpi     20480  2 snd_sof_intel_hda_common,snd_intel_dspcfg
snd_hda_codec         176128  7 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_soc_hdac_hda,snd_soc_skl_hda_dsp
snd_hda_core          110592  12 snd_hda_codec_generic,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_ext_core,snd_hda_codec,snd_hda_codec_realtek,snd_soc_intel_hda_dsp_common,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_soc_hdac_hda,snd_soc_skl,snd_sof_intel_hda
snd_hwdep              16384  1 snd_hda_codec
snd_seq                94208  7 snd_seq_dummy
snd_seq_device         16384  1 snd_seq
snd_pcm               151552  12 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,soundwire_intel,snd_sof,snd_sof_intel_hda_common,snd_soc_hdac_hdmi,snd_compress,snd_soc_core,snd_sof_utils,snd_soc_skl,snd_hda_core
snd_timer              49152  3 snd_seq,snd_hrtimer,snd_pcm
snd                   118784  27 snd_hda_codec_generic,snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_hda_codec_realtek,snd_sof,snd_timer,snd_soc_hdac_hdmi,snd_compress,snd_soc_core,snd_pcm,snd_soc_skl_hda_dsp
soundcore              16384  1 snd
3 root@kuu#

And the output of a couple of Alsa commands:

 3 root@kuu# arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
4 root@kuu# arecord -L
null
    Discard all samples (playback) or generate zero samples (capture)
pipewire
    PipeWire Sound Server
default
    Default ALSA Output (currently PipeWire Media Server)
sysdefault:CARD=sofhdadsp
    sof-hda-dsp, 
    Default Audio Device
5 root@kuu# 

5 root@kuu# aplay --list-devices
**** List of PLAYBACK Hardware Devices ****
card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 1: HDA Digital (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 3: HDMI1 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 4: HDMI2 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: sofhdadsp [sof-hda-dsp], device 5: HDMI3 (*) []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
6 root@kuu# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pipewire
    PipeWire Sound Server
default
    Default ALSA Output (currently PipeWire Media Server)
sysdefault:CARD=sofhdadsp
    sof-hda-dsp, 
    Default Audio Device
7 root@kuu#

And on the hardware side:

 9 root@kuu# lspci -vv | grep -i audio
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS (prog-if 80)
	Kernel driver in use: sof-audio-pci-intel-cnl
10 root@kuu#

And:

13 root@kuu# lspci | grep -i audio
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS
14 root@kuu# 

14 root@kuu# lspci -s 00:1f.3 -v
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS (prog-if 80)
	DeviceName: Onboard - Sound
	Subsystem: Realtek Semiconductor Co., Ltd. Device 119e
	Flags: bus master, fast devsel, latency 32, IRQ 131
	Memory at b1110000 (64-bit, non-prefetchable) [size=16K]
	Memory at b1000000 (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-intel-cnl
	Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_cnl

I’m at a loss now. Any suggestions would be gratefully received.

Regards,
Colin

Sound should work out-of-the-box on Rocky 9.1, you should not need to create any symlinks (and may have broken something by doing so).

I didn’t create any symlinks. These were made by the “systemctl --user” commands in the first post. I think I’ll try reversing these commands.

Cheers,
Colin

OK, some progress has been made!

First, I reversed the earlier systemctl --user commands:

26 colin@kuu> systemctl --user disable pipewire
27 colin@kuu> systemctl --user disable pipewire-pulse
28 colin@kuu> systemctl --user disable wireplumber
29 colin@kuu> systemctl --user disable pipewire.socket
30 colin@kuu> systemctl --user disable pipewire-pulse.socket
31 colin@kuu>

All symlinks were removed:

31 colin@kuu> pwd
/home/colin/.config/systemd/user
32 colin@kuu> ls -al
total 0
drwxr-xr-x. 2 colin colin  6 Jan  9 20:08 .
drwxr-xr-x. 3 colin colin 18 Jan  6 00:08 ..
33 colin@kuu>

And systemctl --user reported that the services were still running.

I tested with aplay but got no sound from the speakers or headphones. Then rebooted and tested again. This is where it gets a bit odd:

No sound over speakers or headphones.

Some experimentation with KDE Control Panel Audio. Works OK.

aplay doesn’t play sound:

5 colin@kuu> aplay /usr/share/sounds/alsa/Front_Left.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Left.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
6 colin@kuu>

Video clips on Twitter and YouTube do work and play sound over the speakers, even with the headphones plugged in.

MP3 files also work when started through Dolphin but NOT with aplay on the command line.

pw-play does play .wav files over the speakers. e.g:

`

14 colin@kuu> pw-play /usr/share/sounds/alsa/Front_Left.wav

`

Plays OK. But pw-play does not play MP3s on the commandline:

16 colin@kuu> pw-play ~/MEDIA/sounds/CTU_Ringtone_from_24.mp3
error: failed to open audio file "/home/colin/MEDIA/sounds/CTU_Ringtone_from_24.mp3": Format not recognised.
error: open failed: Input/output error
17 colin@kuu>
15 colin@kuu> pw-play --list-targets
Available targets ("*" denotes default): alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink
        66: sink description="Comet Lake PCH-LP cAVS HDMI / DisplayPort 3 Output" prio=664
        46: sink description="Comet Lake PCH-LP cAVS HDMI / DisplayPort 2 Output" prio=680
        55: sink description="Comet Lake PCH-LP cAVS HDMI / DisplayPort 1 Output" prio=696
*       49: sink description="Comet Lake PCH-LP cAVS Speaker + Headphones" prio=1000
16 colin@kuu>

23 colin@kuu> pipewire --version
pipewire
Compiled with libpipewire 0.3.47
Linked with libpipewire 0.3.47
24 colin@kuu>

It’s quite obvious that ALSA commands don’t work and that I should have been using the equivalent PipeWire commands (pw-play etc) instead. I think that leaves two questions:

  • How do I get the headphones working?
  • Is pw-play capable of playing mp3’s on the command line if the appropriate codecs are installed?

Any suggestions, please?

Thanks,
Colin

I think there’s two unrelated things happening. The issue with mp3 not working is probably to do with some player not knowing how to play it. The issue with ‘aplay’ is unclear, but could be that it’s not routing the input to the output, or it’s muted (or something else).

From the above, it sounds like this is not a pure Rocky 9.1 installation, e.g. KDE was mentioned and “dolphin” (no idea what that is), so something could have been messed up by non-standard installation.

Hi @gerry666uk

Please define “pure Rocky 9.1 installation.”

Dolphin is the default file manager on KDE. I installed RL9.1 from the install media, installed the EPEL repo, enabled CRB (formerly PowerTools repo), then installed rpm-fusion-free and rpm-fusion-nonfree, and finally KDE with

[root@kuu ~]# dnf grouplist --hidden
[root@kuu ~]# dnf -y groupinstall “KDE Plasma Workspaces”

This downloaded 558 packages from a mixture of EPEL, appstream, rpmfusion-free-updates and crb. The install was fine, then, after a reboot, I logged in with KDE Plasma and X11 and it was all good.

(BTW: I’ve been a KDE user since I first installed Red Hat Linux 6 with the DVD from the front of Linux Format magazine all those years ago. This is a throwback to CDE on Sun Solaris systems back in the 1990’s. Maybe I need to run to catch up but I really don’t like Gnome as it is now. MATE is OK but not as good as KDE.)

I can install a load of codecs to make sound of all types play. There’s a thread on this forum describing how to do so. I just need to sort out the headphones. They were fine under 8.6 but now, nothing.

Any ideas from the Community?

Colin

Well, that was disappointing. The laptop I’m relying on is a cheap(ish) machine from Kuu, which I believe is a Chinese company:

It looks very much like the battery is failing and and the machine keeps crashing with 0% charge.

What does all this have to do with the sound problems? Well, after the most recent crash, I ran dmesg looking for sound-system info and got this:

2 root@kuu# dmesg | grep -i sound
[    7.500192] input: sof-hda-dsp Mic as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input18
[    7.500541] input: sof-hda-dsp Front Headphone as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input19
[    7.500813] input: sof-hda-dsp HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input20
[    7.501111] input: sof-hda-dsp HDMI/DP,pcm=4 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input21
[    7.501489] input: sof-hda-dsp HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input22
3 root@kuu# dmesg | grep -i snd
[    6.932077] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[    6.932175] snd_hda_intel 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[    7.110147] snd_soc_skl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040380
[    7.110248] snd_soc_skl 0000:00:1f.3: Digital mics found on Skylake+ platform, using SOF driver
[    7.440569] snd_hda_codec_realtek ehdaudio0D0: autoconfig for ALC256: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[    7.440577] snd_hda_codec_realtek ehdaudio0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    7.440580] snd_hda_codec_realtek ehdaudio0D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
[    7.440582] snd_hda_codec_realtek ehdaudio0D0:    mono: mono_out=0x0
[    7.440583] snd_hda_codec_realtek ehdaudio0D0:    inputs:
[    7.440585] snd_hda_codec_realtek ehdaudio0D0:      Internal Mic=0x1a
[    7.440587] snd_hda_codec_realtek ehdaudio0D0:      Mic=0x19
[    7.484531] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX overwritten
[    7.484540] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX overwritten
4 root@kuu#

I don’t know if these devices and drivers have any bearing on the sound issues, so I thought I’d add this info to the post to see if it rings any bells in the Community,

Thanks,
Colin

Could you share with us, which kernel you are running on ?

Because there were some other users who had the same problem ( different distribution ) but as soon as they changed to a previous kernel the problem disappeared.

https://forums.debian.net/viewtopic.php?p=765901

@Tas-sos

Thanks for your response and I apologise for my delay in replying. I think this is what you’re looking for:

5 root@kuu# uname -a
Linux kuu 5.14.0-162.6.1.el9_1.0.1.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Nov 28 18:44:09 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
6 root@kuu#

Please let me know if you need any more information.

Colin

Hello @colinabrett ,
Yes, exactly, thanks for sharing your kernel version with us.
Fortunately or unfortunately the problematic version of the kernel was the linux-image-5.10.0-20. But you have a greater version of that 5.14.0-162.6.1.el9_1.0.1.x86_64 which means that most likely the problem from the kernel has already been fixed.

Since I unfortunately don’t have anything else to recommend at the moment, I would suggest the following ( if you haven’t tried it already ).
Another thing that other users report that worked for them was restarting pulseaudio and pipewire services.

systemctl --user restart pulseaudio.service -l
systemctl --user restart pipewire -l

To recap:

  • Kernel : 5.14.0-162.6.1.el9_1.0.1.x86_6
  • Linux Distribution : Rocky Linux 9.1 which is based on RHEL 9.1, which is based on Fedora 34 ?
  • Desktop environment : Gnome ? Which version ?

Possible useful references:

Hello @Tas-sos.

I’ve done some more research and testing and followed the Fedora links you provided. In summary, sound works over the speakers but not over the headphones. (I tested the headphones on a different - much older - laptop also running RL9.1 and they work fine.)

I’ve attached some screenshots of the KDE System Settings. You’ll see in the kde_inactive_[12].png files, there are several devices greyed out, with names like “Comet Lake PCH-LP cAVS HDMI / DisplayPort 3 Output”, which also appear in the pw-cli output. (I can’t upload a text file of the work I did but can always refer back to it if needed.)

I’m beginning to wonder if the correct drivers for the “Comet Lake PCH-LP cAVS Speaker + Headphones” are being loaded (or if they exist at all).

Regards,
Colin



I’ve been doing some more research into this and I’m beginning to think a Kernel upgrade might be necessary. For example:

8 colin@kuu> lspci | grep -i audio
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS
9 colin@kuu> lspci -s 00:1f.3 -v
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS (prog-if 80)
        DeviceName: Onboard - Sound
        Subsystem: Realtek Semiconductor Co., Ltd. Device 119e
        Flags: bus master, fast devsel, latency 32, IRQ 131
        Memory at b1110000 (64-bit, non-prefetchable) [size=16K]
        Memory at b1000000 (64-bit, non-prefetchable) [size=1M]
        Capabilities: <access denied>
        Kernel driver in use: sof-audio-pci-intel-cnl
        Kernel modules: snd_hda_intel, snd_soc_skl, snd_sof_pci_intel_cnl

If I then use lsmod to look for the “Kernel driver in use”, I get no output:

10 colin@kuu> lsmod | grep sof-audio-pci-intel-cnl
10 colin@kuu>

Googling for “intel corporation comet lake pch-lp cavs linux” leads to:

“The device is supported by kernel versions 5.2 and newer according to the LKDDb”

But:

2 root@kuu# uname -a
Linux kuu 5.14.0-162.6.1.el9_1.0.1.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Nov 28 18:44:09 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
3 root@kuu#

It seems the machine in question uses kernel 5.14 which might not support the sound card fully. So the question to the Community (@Tas-sos and @gerry666uk) would be:

Is there a “Kernel Upgrades for Dummies” you might recommend for Rocky Linux 9.1?

Regards,
Colin

Premise:
Red Hat backports features and fixes into RHEL. Therefore, version numbers of of RHEL packages are not version numbers of upstream. See What is backporting and how does it affect Red Hat Enterprise Linux (RHEL)? - Red Hat Customer Portal
Therefore, third-party content (replacements) may not be compatible and do shift responsibility from Red Hat to user.

That said:

dnf install elrepo-release
dnf install kernel-ml

Well, that’s been an experience, which was not exactly fruitful.

I followed this document:

https://docs.rockylinux.org/guides/custom-linux-kernel/

and added in the suggestion from @jlehtone to

dnf install elrepo-release
dnf install kernel-ml

A build of version 5.4.228 refused to boot, so I managed to recover to the machine’s previous state. What surprised me was there was a /boot/config-6.1.7-1.el9.elrepo.x86_64 file, which was presumably installed via elrepo-release.

I uninstalled elrepo-release, kernel-ml, 6.1.7 from elrepo and the failed 5.4.228 build. I started again with a clean(ish) system and this time downloaded version 6.1.7 from kernel.org.

The new 6.1.7 install worked but the sound issue (headphones not working) was still not fixed. Similarly, the vmlinuz-6.1.7-1.el9.elrepo.x86_64 (this is the version I’m running at the moment) also booted cleanly but the headphone problem persisted.

Frankly, I’m at a loss now. I think it may be a kernel configuration option I missed when building my own version 6.1.7. I just have no idea where to look or how to switch it “on” to get the headphones working.

I’m about to try using Bluetooth headphones. If these work, I’ll update this thread.

Regards,
Colin

Bluetooth earbuds seem to work. Before pairing the laptop and earbuds, these commands worked:

12 colin@kuu> pw-play /usr/share/sounds/alsa/Front_Right.wav
13 colin@kuu> pw-play /usr/share/sounds/alsa/Front_Left.wav

and played sound over the speakers.

I then enabled Bluetooth and paired the earbuds. The above commands also worked through the earbuds.

However, I noticed that the first couple of times I tried to play Front_Right.wav, there was a slight delay between pressing and the sound coming through the buds. The delay was for less than a second but was noticeable, as I missed all or part of the the word “front”. After a couple of re-runs of the command, the whole sound file played correctly.

After a couple of minutes (spent typing this) I played the sounds again and the delay happened again. Is this some Bluetooth latency problem? I’m really not familiar with this area.

I understand this is a Bluetooth issue and probably needs a separate thread (which I may raise in the future). It’s a workaround for the original sound problem but I thought I should include the findings here in case someone else finds it useful.

Regards,
Colin