Since a few updates, I noticed that whenever I wake up my system from sleep, the audio is muted for some reason.
This was not the case before and I think this is pretty annoying.
Anybody noticed the same? Is this a new “feature” or a regression?
I am on Manjaro Unstable and here are my system details:
Operating System: Manjaro Linux
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.12.28-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-8600K CPU @ 3.60GHz
Memory: 31.2 GiB of RAM
Graphics Processor 1: AMD Radeon RX 6800
Graphics Processor 2: Intel® UHD Graphics 630
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B46
System Version: 1.0
Hi - I’m no expert on audio issues, but just to clarify the issue for folks - are you able to unmute as normal afterwards, or is the audio “stuck” muted until a reboot?
alsamixer is supposed to save your audio settings and restore them at reboot using the info in /var/lib/alsa/asound.state
check that this file is being updated when you change settings and that they are being restored when you reboot.
you can force it to save the state by running sudo alsactl store
i had issues on plasma 6.1 where it would not remember my sound state so i ended up adding sudo alsactl restore to my autostart
1 Like
Ah right, I can always unmute it using the dedicated keys on my keyboard.
Okay thank you for the idea.
I have saved my current state with working/ unmuted sound, and will compare the file contents when this issue occurs again.
Strangely, it doesn’t seem to happen for every standby-wakeup cycle.
how are you controlling sleep states, thru the power management settings ( or energy savings, depending on how you access it)?
does this difference have anything to do with how long the system is in sleep state, as in less than 2hrs it remembers, but greater than 2hrs it forgets?
I had no issues.
I have some automated behaviour - suspend at 11pm after setting volume to 10%, then wake up at 5.58am, and at 6.05 set volume to 50%… no problems with that.
Normal sleep/wake has zero effect on volume.
NicGnomic is the Audio expert in the Manjaro forum, but as always, see if you can replicate this with a fresh USER - as it seems likely a USER data problem than a bug.
1 Like
I usually just press the standby button in the start menu, but in the power management settings I have the standby-mode (?) set to “Standby, then hibernate”.
However, I just tested going to hibernate, and noticed that it doesn’t really work in general.
It seems like my PC is just shut down completely, because all my apps were closed when i turned it on again and i also had to log in through SDDM normally.
Anyway, it seems like some of the recent Manjaro updates fixed the problem automagically again.
After the last reboots/ standby cycles, the volume was on the correct level.
So i guess this is fixed already. If it pops up again, I will report it here.
If it appears again, I contact him, thanks for the hint.
1 Like
hibernate is save to disk… so if you are not reloading from disk when you power back up after to goes into hibernate then you need to set up your swap partition so it has someplace to store the ram contents before the power goes off.
otherwise you are just sleeping and the power is still going to the ram to keep everything the way you left it.
this is why i asked, because if you are rebooting from scratch after hibernation, then that could explain why you came back to a muted audio instead of where you left it.
Hmm in theory, I have a swap partition:
swapon --show ✔
NAME TYPE SIZE USED PRIO
/dev/nvme0n1p3 partition 8,8G 0B -2
No idea, why hibernation still doesn’t work.
If i enter hibernation, it takes quite a while until the PC turns off, so I thought it must be saving the RAM’s content to the disk in that time, but seems like something is going wrong then.
I would have assumed that the system just stays active if it doesn’t work, or goes into standby instead, but that doesn’t seem to be the case.
do a blkid on that partition and put it into your grub file like so
# also important that the kernel knows where to find the stored image on disk so add this to grub
GRUB_CMDLINE_LINUX="resume=UUID=xxxx-xx-xxxxx-xxxx-xxxx-xxxxxxx"
don’t forget to run sudo update-grub
1 Like
Actually, I’ve just discovered, that there already is a resume entry in the /etc/default/grub file:
GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=1 security=apparmor resume=UUID=5ee1d153-9e4d-4840-9b3c-ff5fb8a50026 udev.log_priority=3 intel_iommu=on preempt=voluntary"
I don’t get any output when I execute blkid or blkid /dev/nvme0n1p3, but lsblk shows something:
lsblk --output NAME,SIZE,FSTYPE,UUID ✔
NAME SIZE FSTYPE UUID
sda 223,6G
├─sda1 16M
├─sda2 222,9G ntfs 00461D84461D7B9A
└─sda3 675M ntfs F83E78FE3E78B6EA
sdb 931,5G
└─sdb1 931,5G ext4 8d2954fc-ff7f-41e1-9784-945a947b25b0
sdc 238,5G
└─sdc1 238,5G exfat EFE7-FC62
sdd 29,3G
└─sdd1 29,3G vfat A315-96A0
sde 0B
sdf 0B
sdg 0B
sr0 1024M
nvme0n1 931,5G
├─nvme0n1p1 300M vfat 8C6B-9D91
├─nvme0n1p2 922,4G ext4 d308b8a4-924c-4601-b983-c34485cd1d3a
└─nvme0n1p3 8,8G swap 5ee1d153-9e4d-4840-9b3c-ff5fb8a50026
The UUID is the one that is also in the Grub parameters, but something still doesn’t seem to be working.
Found the issue on my own (can’t edit the post above for some reason…).
The file /etc/mkinitcpio.conf was missing the resume hook.
With the following line, hibernation works:
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block filesystems fsck resume)
Thanks for your help 
2 Likes