possible timing issue with alsa-restore.service

[fajabird]

not sure how to title this issue but the following happens in my case:

System is a Dell XPS one (all in one PC) and I'm running latest manjaro gnome. I noticed that I had no sound although GNOME control center would show a audio device and it was not muted and volume was all the way up.

So I tried alsamixer and found the device "Headphones" muted and volume at 0. Changing this did the trick and I had sound. I issued an "alsactl store" and checked that "alsa-restore.service" was not deactivated to make this persistant. Still after reboot I had no sound.

But if I would issue "alsactl restore" manually it would fix the sound issue again. So I suspected that there is an timing issue. Via "systemctl edit --full alsa-restore.service" I added a 30 seconds delay before it would call "alsactl restore" and that fixed the issue permanently. But unfortunately I have no idea how to troubleshoot this properly to find the real root cause of this timing issue.

[perexg]

You should try to disable the sound server at first. If the volume is preserved in the next boot, the sound server sets the different volume than you expect.

[fajabird]

can you provide me some instructions how to disable the soundserver?

Meanwhile I checked with pacmd/pactl some details. It seems that the PC has just one sink (pacmd list-sinks -> index 0) with 2 ports (speaker + headphones). If I use pacmd to change the default port to headphones audio starts to work, changing back to speaker breaks audio.

I was not able to archive the same as with alsamixer, i.e. to just change the volume of the port headphones from 0 to 100%. pacmd/pactl have no options to archive that. But this is all it needs to make audio work. So any idea why default volume of port headphone is always 0%? Is it, because it detects that no headphones are actually plugged in? Can I somehow overwrite this - that would solve my issue possibly via the soundserver and the alsa-hack woud not be required anymore.

Thanks