[SOLVED] Temporarily disabling the sound card on suspend

arx1i · 2026-05-04 10:44:22

Hello,

I am facing the disappearance of the internal sound after waking my Thinkpad Z16 from suspend: this is a long-known and chronically ignored issue (e.g., 1, 2).

As a possible work-around, I want to try disabling the sound card before suspending and re-enabling it after resuming.

I have two questions.

What commands shall I use? I am thinking of

pactl set-card-profile alsa_card.pci-0000_c7_00.6 off

and

pactl set-card-profile alsa_card.pci-0000_c7_00.6 "HiFi (Mic1, Mic2, Speaker)"

— does that make sense?

When I try to use
```
sudo -u … XDG_RUNTIME_DIR=/run/user/1000 pactl …
```
in "/lib/systemd/system-sleep/my.sh", I am getting Connection failure: Timeout in the log (the suspend process "hangs" but repeated short push of the power button helps it). What am I doing wrong?

Last edited by arx1i (2026-05-05 16:28:19)

seth · 2026-05-04 14:59:59

https://wiki.archlinux.org/title/Lenovo … _Z13#Audio says restarting pipewire is sufficient - is it not?
Have you tried those actions manually (both, manual "pactl set-card-profile" before and after the sleep as well as "sudo -u arx1i XDG_RUNTIME_DIR=/run/user/1000 pactl" from a root shell)?

arx1i · 2026-05-04 15:25:16

Restarting pipewire in my case does nothing: nothing short of rebooting brings back the normal sound (by the way, in my case only the left speaker is muted).
There are some reports that hibernation helps (which intuitively makes sense), but I do not have hibernation enabled and would rather not waste GBs on SSD just for a fishy remedy for this speaker issue.

To your second question: Of course, I've tried that earlier as a regular user – worked fine.
I've just tried that from `sudo sh`, it works fine too.

By the way, if I omit "XDG_RUNTIME_DIR=/run/user/1000", then the error becomes

Connection failure: Connection refused
pa_context_connect() failed: Connection refused

So, something is going on here: I'd guess, it requires some additional environment settings…

arx1i · 2026-05-04 15:46:57

Above I missed another question, sorry.

Do you mean, have I tried manual `pactl set-card-profile` as a remedy for my speaker issue?

I thought about it, but not tried yet: this issue is "non-deterministic", maybe happens with some 10% probability (i.e., some 9 out of 10 suspend-resume cycles do not ruin the sound).
So, I felt that playing with "/lib/systemd/system-sleep/my.sh" right away would be a simpler way to test my solution – then this "Connection failure: Timeout" issue came up…

seth · 2026-05-04 20:24:29

I've just tried that from `sudo sh`, it works fine too.

https://man.archlinux.org/man/sudo.8#i

By the way, if I omit "XDG_RUNTIME_DIR=/run/user/1000", then the error becomes

Yes, that's expectable.

The timout likely happens because the user session if frozen when the script runs, https://bbs.archlinux.org/viewtopic.php?id=296954

some 9 out of 10 suspend-resume cycles do not ruin the sound

Do you happen to have a system journal for an affected boot?
Sanity check:is there a parallel windows installation?

arx1i · 2026-05-05 16:27:04

seth, thanks a lot!

Indeed, freezing was the reason for the timeout:

[Service]
Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"

in "/etc/systemd/system/systemd-suspend.service.d/disable_freeze_user_session.conf" has allowed me to start my work-around experiment!

To your other questions: I don't have a journal for those events – I rarely notice this thing happening right away (it took me some time to realise that this was related to sleeping cycles). Naturally, the internal speakers on the laptop are not the most frequently used piece of hardware – but still, their chronically half-muted state can be quite annoying.

---

As my question has been answered, I'll mark it "[SOLVED]". Though I am not sure at all that my trick will work…

seth · 2026-05-16 19:53:00

Though I am not sure at all that my trick will work…

Apparently not

You should open a new thread about that (because it's a distinct problem) - whether anyone can help you with that (the benefit of the forum is that there're other very competent users, I ranted about that when changing the comment under my avatar ) is to be seen but at least we can take a look at it.

arx1i · 2026-05-17 02:07:42

seth wrote:

Though I am not sure at all that my trick will work…
Apparently not
You should open a new thread about that (because it's a distinct problem) - whether anyone can help you with that (the benefit of the forum is that there're other very competent users, I ranted about that when changing the comment under my avatar ) is to be seen but at least we can take a look at it.

Right, that was precisely my intention, the only reservation was the "abandoned" status of the problem and, clearly, its not being specific to arch. I will open a new thread soon!

———

Edit: Here it is.

Last edited by arx1i (2026-05-17 03:21:55)

seth · 2026-05-17 17:29:41

The mods enforce the rules you subscribed to - it's kinda their whole job.
arch derivates are not supported because typically neither the user nor anyone here will know what is configured how.

If you struggle to fix this and experience it on archlinux-archlinux, you won't have to prove nothing special because it will be necessary to see the journal - notably because of the unruly pci node and because neither the erroneous module nor the chip you claim is there shows up in the lspci…

arx1i · 2026-05-17 18:21:52

seth, thanks a lot for your help!

I'll see how things go... Again, after all the left internal speaker is not the most crucial piece of hardware and rebooting a laptop once in a while is not a disaster

As for that situation, I completely understand that each community has its own written and unwritten rules, and the fact that this forum is one of the most helpful sources overall shows that its rules are "sustainable". Honestly, in my subjective opinion, imposing rules to a degree that clearly makes no practical sense is pointless in a community like this one – one that consists of enthusiasts, who would not "descend into anarchy" just because the rule-enforcement got lighter. But then again, who am I to judge?

Arch Linux

#1 2026-05-04 10:44:22

[SOLVED] Temporarily disabling the sound card on suspend

#2 2026-05-04 14:59:59

Re: [SOLVED] Temporarily disabling the sound card on suspend

#3 2026-05-04 15:25:16

Re: [SOLVED] Temporarily disabling the sound card on suspend

#4 2026-05-04 15:46:57

Re: [SOLVED] Temporarily disabling the sound card on suspend

#5 2026-05-04 20:24:29

Re: [SOLVED] Temporarily disabling the sound card on suspend

#6 2026-05-05 16:27:04

Re: [SOLVED] Temporarily disabling the sound card on suspend

#7 2026-05-16 19:53:00

Re: [SOLVED] Temporarily disabling the sound card on suspend

#8 2026-05-17 02:07:42

Re: [SOLVED] Temporarily disabling the sound card on suspend

#9 2026-05-17 17:29:41

Re: [SOLVED] Temporarily disabling the sound card on suspend

#10 2026-05-17 18:21:52

Re: [SOLVED] Temporarily disabling the sound card on suspend

Board footer