Arch Linux

cyberpunkrocker

Member

From: Birckala, Finland

Registered: 2019-09-16

Posts: 24

Website

Pulseaudio weirdness with 5.5 series kernels

Story so far:
When I first upgraded to 5.5 series kernel, pulseaudio stopped working - or at least, HDMI sound output from a Nvidia card stopped working. Seems that adding the snd_hda_intel.dmic_detect=0 kernel parameter was the way to fix this, but regardless, I decided to downgrade to 5.4.x kernel and stay there for a while, 5.5 was too buggy for my tastes.
A few days ago I finally upgraded my kernel to 5.5.11, with the abovementioned kernel parameter added. But still, I have noticed two issues with pulseaudio which weren't present in earlier kernels:

#1: After every boot, pulseaudio does not work i.e. does not show any sinks or sources, until I manually restart pulseaudio

pulseaudio -k
pulseaudio --start

Actually, pulseaudio -k itself seems to be enough, pulseaudio restarts itself after a few seconds. After that, pulseaudio continues to work normally.

#2: Audio is muted for the first 1-2 seconds when it starts to play, both on music files and videos. This is especially annoying if you pause a video mid-sentence, when continuing the play the first seconds of audio is lost. I havent noticed this kind of behaviour earlier.

Any ideas what is behind these issues? Kernel? Nvidia drivers? Pulseaudio itself?
And more importantly, how to fix these? The #1 especially is so annoying that I'm ready to downgrade back to the properly working 5.4 series kernel if I cannot find a fix for these soon...

V1del

Forum Moderator

Registered: 2012-10-16

Posts: 21,616

Re: Pulseaudio weirdness with 5.5 series kernels

Post

dmesg | grep snd
systemctl --user status pulseaudio
journalctl -b --user-unit=pulseaudio
aplay -l
pacmd list-cards
pacmd list-sinks

If all it takes to fix this is a kernel downgrade (you did just downgrade the kernel and no other packages and kept those other packages updated?) then this is a kernel issue (or nvidia kernel module) and pulse has little active relevance. There might be an issue in how the kernel communicates the availability of devices to the rest of the system.

Last edited by V1del (2020-03-25 11:29:58)