Try reloading the kernel module after wake from sleep …
modprobe -r {module} then modprobe
Seems like the output is the same
before sleep:
~$ pactl list short sinks
55 alsa_output.pci-0000_00_1f.3.analog-stereo PipeWire s32le 2ch 48000Hz SUSPENDED
after sleep:
~$ pactl list short sinks
55 alsa_output.pci-0000_00_1f.3.analog-stereo PipeWire s32le 2ch 48000Hz SUSPENDED
i have disabled bluetooth from device settings… it isnt bluetoothspeakers im talking about
s2idle on this system shortly turns off the screen and resumes automatically, sound does work after this tho.
i tried to reload snd_hda_intel, it has some dependencies on pipewire… but managed to reload and didnt work again after sleep… let me know if i need to reload another module
you’d have to repeat thist after each wake-up. It’s a workaround with the admin hammer.
Here is a copr repo providing current 6.12.x LTS kernel builds for f43. Kernel does not boot with secure boot enabled.
but reloading snd_hda_intel didnt resolve the issue… the speakers still didnt output sound when i reloaded it…
Then I misinterpreted that.
You can try other older and newer kernel versions to find one that’s working on your system.
I guess some additional quirk may be required here.
It is also possible that it never worked properly because no one reported this.
Nethertheless open a bug report https://bugzilla.redhat.com/ for product fedora component kernel and provide logs and as much info as possible ( HW etc ).
@dstkdstk:
Your chances of getting the issue fixed will be much better if you can find details in the journal. It does take some effort to find the right “filters” and compare before and after sleep entries. If you find a USB audio dongle that works, that would be useful to devs trying to understand the problem.
i tried with ubuntu 20TLS, it uses kernel 5 and issue was still present.
As for reloading snd_hda_intel, i was helped by LLMs but im not very confident on its walkthroughts… I’d appreciate if youd take the time to explain how to properly unload wireplumber, pipewire, alsa… and check if the modprobe was successful to unload/load and also unload snd_hda_codec, then load everything properly…
For bugreport sure id do it, but i find this machine rather old and not very relevant, i love to keep it out of garbage field and i like its features, otherwise not a big deal if it cant be fixed. If you think otherwise id ask what are relevant data to fill on the bugreport.
Can you please walk me through how to find the filters and what should i expect? Thank you for suggestion!
I am not surprised at this point. Have you looked for a newer bios version?
Also check with alsamixer -c0 if speakers are muted etc.
stop pipewire systemctl --user stop pipewire.socket pipewire-pulse.socket
lsof /dev/snd/* must not show a device in use
modprobe -r but I’d say this will be blocked by other modules
read man rmmod and look at output of lsmod |grep snd
start pipewire : systemctl --user start pipewire.socket pipewire-pulse.socket
followed by systemctl --user start pipewire-pulse.service for some reason this one will not be triggered correctly by the socket.
probably impossible w/o snd_hda* verbose debugging enabled . It’s not a user land issue (pipewire and friends). Headphones work. And plain dmesg did not reveal anything useful. So it can be only the part codec ↔ amp. Maybe it’s still muted or powered off or bios does something wrong at wake time.
this may be useful trying to obtain more verbose kernel messages and options to debug further. More Notes on HD-Audio Driver — The Linux Kernel documentation
1 Like
i spent some time trying to unload snd_ things and there are just too intertwined to unload properly… or im just not very familiar with the rest of the things…
anyways… what im seeing in dmesg is:
[ 645.886943] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [i915])
[ 645.887221] snd_hda_intel 0000:00:1f.3: Applying patch firmware 'hda-jack-retask.fw'
[ 645.903860] snd_hda_codec_conexant hdaudioC0D0: CX20753/4: BIOS auto-probing.
[ 645.904481] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20753/4: line_outs=1 (0x1d/0x0/0x0/0x0/0x0) type:speaker
[ 645.904486] snd_hda_codec_conexant hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 645.904489] snd_hda_codec_conexant hdaudioC0D0: hp_outs=1 (0x16/0x0/0x0/0x0/0x0)
[ 645.904491] snd_hda_codec_conexant hdaudioC0D0: mono: mono_out=0x0
[ 645.904493] snd_hda_codec_conexant hdaudioC0D0: inputs:
[ 645.904494] snd_hda_codec_conexant hdaudioC0D0: Mic=0x19
[ 645.904496] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x1a
[ 645.908519] input: HDA Intel PCH Mic as /devices/pci0000:00/0000:00:1f.3/sound/card0/input22
[ 645.908633] input: HDA Intel PCH Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input23
can i disable the hda-jack-retask.fw patch somehow?
found a way to disable it and it didnt change anything. At this point, I want to thank everyone for helping me here! I will proceed with bugreport. Thank you everyone for your time!
I think hda-jack-retask.fw patch is used to manipulate the association between channels and jacks when using more than 2 channels he.g., surround sound) with speakers that the default mapping gets wrong. I think your model claims “3D Enhancementł”. A web search shows your issue has been seen by others on your model. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1612916 has a long history. Looks like alsa.org is responsible for hda-jack-retask.fw. Look for an outstanding bug report there.