Hi, I had a problem with the sound, so I reinstalled “alsa,” and since then the sound has been stuttering, like it’s stuck in a loop.
Since reinstalling ALSA is the only change mentioned, could you provide a little more information about the system and the audio setup?
- Desktop environment / session (GNOME/KDE, Wayland/X11)
- Audio hardware (
lspci | grep -i audio) - Whether you’re using PipeWire (
pactl info) - What exactly was reinstalled (which ALSA packages/commands)
- Whether the stuttering happens with all audio sources or only a particular application
- Any relevant errors from
journalctl
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
String do servidor: /run/user/1000/pulse/native
Versão do protocolo da biblioteca: 35
Versão do protocolo do servidor: 35
É local: sim
Índice do cliente: 147
Tamanho de fragmento: 65472
Nome do usuário: sylvestrejacome
Nome da máquina: fedora
Nome do servidor: PulseAudio (on PipeWire 1.6.8)
Versão do servidor: 15.0.0
Especificação padrão de amostragem: float32le 2ch 48000Hz
Mapa de canais padrão: front-left,front-right
Destino padrão: alsa_output.pci-0000_00_1f.3.analog-stereo
Fonte padrão: alsa_input.pci-0000_00_1f.3.analog-stereo
Cookie: 29c0:7b78
dnf install alsa-firmware alsa-sof-firmware
all audio sources
i dont found any relevant erros from “journalctl”
Why did you install alsa-firmware and alsa-sof-firmware specifically?
Your audio device is an Intel Sunrise Point-LP HD Audio controller
Could you share the full output of lspci -k -s 00:1f.3 please?
My audio was glitching—unpredictably, and not intermittently.
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)
Subsystem: Dell Device 078b
Kernel driver in use: snd_hda_intel
Kernel modules: snd_soc_avs, snd_sof_pci_intel_skl, snd_hda_intel
Sometimes the sound would cut out for a few seconds, and then it would come back.
Audio glitches can have many causes and don’t necessarily indicate a driver problem. On older hardware, for example, CPU spikes or scheduling latency can cause audio dropouts. Before changing drivers or reinstalling packages, I’d first establish what the original symptom actually was and what changed immediately before it started.
On your side, I’m not sure that installing alsa-firmware or alsa-sof-firmware is necessary. Your system is currently using the Intel HDA driver:
Kernel driver in use: snd_hda_intel
I’d try to correlate the stuttering with what’s happening on the system. Check journalctl around the exact time the audio cuts out, and also keep an eye on CPU and RAM usage in System Monitor while reproducing the problem. If the system is under load when the audio starts stuttering, that gives us a much better direction than reinstalling audio packages again.
set 16 16:06:39 fedora audit: BPF prog-id=206 op=LOAD
set 16 16:06:39 fedora systemd\[1\]: Starting systemd-hostnamed.service - Hostname Service...
set 16 16:06:39 fedora systemd\[1\]: Started systemd-hostnamed.service - Hostname Service.
set 16 16:06:39 fedora audit\[1\]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 sub>
set 16 16:06:40 fedora chrome-jchckllpcbjclcbihocgmdddllkiohdo-Default.desktop\[12648\]: \[12699>
set 16 16:06:40 fedora chrome-jchckllpcbjclcbihocgmdddllkiohdo-Default.desktop\[12648\]: \[12699>
set 16 16:06:40 fedora chrome-jchckllpcbjclcbihocgmdddllkiohdo-Default.desktop\[12648\]: Fontco>
set 16 16:06:56 fedora systemd\[2463\]: dbus-:1.2-org.gnome.Nautilus@20.service: Unit process 3>
set 16 16:06:56 fedora systemd\[2463\]: dbus-:1.2-org.gnome.Nautilus@20.service: Consumed 2.100>
set 16 16:07:09 fedora systemd\[1\]: systemd-hostnamed.service: Deactivated successfully.
set 16 16:07:09 fedora audit\[1\]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj>
set 16 16:07:09 fedora audit: BPF prog-id=204 op=UNLOAD
set 16 16:09:50 fedora wpa_supplicant\[1257\]: wlp1s0: CTRL-EVENT-BEACON-LOSS
set 16 16:12:21 fedora systemd\[2463\]: Started app-gnome-chrome\\x2dhnpfjngllnobngcgfapefoaidbi>
set 16 16:12:22 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop\[33392\]: Abrind>
set 16 16:12:30 fedora chrome-jchckllpcbjclcbihocgmdddllkiohdo-Default.desktop\[12648\]: \[OpenH>
set 16 16:13:48 fedora clamd\[1297\]: SelfCheck: Database status OK.
set 16 16:15:53 fedora rtkit-daemon\[1088\]: The canary thread is apparently starving. Taking a>
set 16 16:15:53 fedora rtkit-daemon\[1088\]: Demoting known real-time threads.
set 16 16:15:53 fedora rtkit-daemon\[1088\]: Demoted 0 threads.
set 16 16:23:48 fedora clamd\[1297\]: SelfCheck: Database status OK.
set 16 16:26:28 fedora systemd\[2463\]: Started dbus-:1.2-org.gnome.Ptyxis@2.service.
set 16 16:26:28 fedora systemd\[2463\]: Started ptyxis-spawn-5b781403-a9d9-4604-a64b-d58dca2f37>
lines 263654-263676/263676 (END)
In case you are using flatpak apps, it would be good also to check there for updates. I see in my gnome Software the following:
P.S.
Please use pre-formated text </> it looks better and if the block is big it is scroll able. Easier this way to read and navigate thru your topics 
I made it above for you!
I see—there are updates, but not yours specifically. Should I install the updates, restart the laptop, and check?
Just be aware if you use gnome RPM, and install packages from:
rpmfusion-free RPM Fusion for Fedora 44 - Free
rpmfusion-free-updates RPM Fusion for Fedora 44 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 44 - Nonfree
rpmfusion-nonfree-updates
Flatpak will need it separately so they work.
I always do it with dnf first. When this is done I recheck in gnome-software if there are still updates. And install them before I reboot. I not use the terminal to explicit update flatpak.
Let me see if I understood this correctly… will the driver be fixed automatically when I install the updates?
Flatpak only from gnome-software?
Some prefer the gnome software tool, as indicated by @ilikelinux .
I prefer to use the command flatpak update on the command line so I can explicitly see exactly what is being done. It does not require using sudo for flatpak updates.
From that log 2 interesting leads, I’d investigate the ClamAV activity before changing the audio stack again.
The interesting part of the log is the rtkit-daemon warning:
rtkit-daemon: The canary thread is apparently starving.
rtkit-daemon: Demoting known real-time threads.
I’d correlate that with the ClamAV checks and CPU usage. In particular, check whether the audio stuttering happens at the same time as a ClamAV database update/scan and whether clamd is consuming significant CPU.
I’d monitor CPU usage while reproducing the issue and compare the timestamps with (replace time start and end to filter logs to a considerable time frame when the stutter occurs):
journalctl -u clamd --since "time:start" --until "time:end"
The rtkit message doesn’t prove ClamAV is responsible, but it does suggest that something was starving the real-time scheduling environment at that moment, which is worth investigating given the audio symptoms.
Yes, I noticed that too; at first, it seemed like a processor issue, but it happened after I reinstalled ALSA.
My ClamAV wasn’t active when the problem occurred.
The kernel was updated, and solved?
Clamav doesn’t need to be active, it’s Daemon running background checks on the other hand could, but this was a wild guess because it appeared below the scheduling warning. Not conclusive but worth investigating considering is the only clue (other than the firmware package reinstalled)
Last comment not sure if you are asking or confirming that solved the issue (hope it is the later!)
The problem persists: the laptop’s sound keeps stuttering—or rather, the sound keeps stuttering and freezing up—suddenly, then it goes back to normal.
set 17 14:38:52 fedora systemd[11245]: Started app-com.google.Chrome-25640.scope.
set 17 14:38:52 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop[25648]: Created TensorFlow Lite >
set 17 14:38:57 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop[25648]: [25640:25675:0917/143857>
set 17 14:39:02 fedora clamd[10009]: SelfCheck: Database status OK.
set 17 14:39:07 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop[25648]: [OpenH264] this = 0x0x39>
set 17 14:39:22 fedora chrome[25640]: [25640:25668:0917/143922.473666:INFO:chrome/browser/extensions/extension_>
set 17 14:39:24 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop[25648]: [25640:25675:0917/143924>
set 17 14:39:30 fedora chrome-hnpfjngllnobngcgfapefoaidbinmjnm-Default.desktop[25648]: [25640:25675:0917/143930>
set 17 14:39:31 fedora systemd[11245]: app-com.google.Chrome-25640.scope: Consumed 21.036s CPU time over 38.714>
set 17 14:39:31 fedora systemd[11245]: app-gnome-chrome\x2dhnpfjngllnobngcgfapefoaidbinmjnm\x2dDefault-25640.sc>
set 17 14:41:59 fedora rtkit-daemon[9813]: The canary thread is apparently starving. Taking action.
set 17 14:41:59 fedora rtkit-daemon[9813]: Demoting known real-time threads.
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 12598 of process 11774 (/usr/bin/gnome-s>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11800 of process 11779 (/usr/bin/pipewir>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11779 of process 11779 (/usr/bin/pipewir>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11476 of process 11464 (/usr/bin/gnome-s>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11454 of process 11442 (/usr/bin/wireplu>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11442 of process 11442 (/usr/bin/wireplu>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11445 of process 11441 (/usr/bin/pipewir>
set 17 14:41:59 fedora rtkit-daemon[9813]: Successfully demoted thread 11441 of process 11441 (/usr/bin/pipewir>
set 17 14:41:59 fedora rtkit-daemon[9813]: Demoted 8 threads.
set 17 14:42:04 fedora systemd[11245]: Started dbus-:1.2-org.gnome.Ptyxis@1.service.
set 17 14:42:04 fedora systemd[11245]: Started ptyxis-spawn-4d37d00f-3c2b-43c1-a7f8-ab55414cce2f.scope - [syste>
lines 278830-278852/278852 (END)