I tried to debug it myself and had some success, but still need some advice in order to solve the problem properly.
The Problem: After I put my computer to hibernation I have no sound (suspend works fine).
My system: HP spectre X360 4100 - Broadwell
The error message: dmesg shows The partial solution:
I can get the sound back if I go to pavucontrol, switch to headset and then back to built-in speakers. But it's too loud, I have to open alsamixer, choose the card and lower the volume on master. That will bring the sound back to normal.

The questions:

1. Does anyone have an idea why this is happening based on the error message or the "solution"?
2. Does anyone have a way to automate the "solution"?
3. Any other insights?

I'd be happy to supply any additional necessary info...


Bonus:
If I set on grub, the sound works, and keep working even after hibernation but then there is a problem with the accelerometer, and `monitor-sensor` reports it as "undefined".
When I do that aplay gives different output for the card:
might be a different approach to solving the problem, but I don't know enough about ACPI...
normal output from `aplay -l`:

which distribution and version are you running? does pavucontrol not let you adjust the volume?

And more: Do you use systemd or SysVinit?
(Nevertheless, I consider your question really nicely formulated and I honor your debugging.)

Do you need to Hibernate or could you get away with Sleep instead? (I personally very much prefer sleep mode and see hibernate as "obsolete" with modern hardware)

Regarding Hibernate, various hardware (also soundcards) have various power saving modes etc, it seems that when you hibernate, these do not return from their hibernation power mode (off/idle) when you boot up your hibernation image. When you "do something" it wakes it up from power mode X to normal power mode.

It should be a fairly simple solution in the end, but getting there correctly could be fairly complicated.

I'm not an expert, but I bet the I2C interface is the one used to "wake" your soundcard from the idle state and report the result to motherboard. Judging by this error, I would think it would succeed in "waking" your sound card from "idle" if you try the same thing with suspend mode (as you stated you did).

It could perhaps have something to do with the order of the hardware returning from idle, and some still idle hardware which is required to wake the sound card after hibernation could cause this issue. Waking hardware from hibernation is more complicated than doing it from sleep, sine hardware info/states is stored on a static image.

+1 to that.

Hibernate is indeed being left behind. Hibernate reboots on the kernel, restores an image, and expects everything to be as it was. In my case, it restores THE HIBERNATE SIGNAL, so the first thing it does when it is restored is to hibernate again. In runlevel 5 (under X) you not only have acpid monitoring power management, but your window manager's power manager as well. I can probably solve things here by configuring the XFCE power manager to go and play in the traffic, but I'm not bothered. With today's cpus, gpus & displays eating battery life, hibernating isn't worth it except in special circumstances. And a good battery lasts well on suspend, although you want a psu at the other end.

I wouldn't say it's impossible.
I once had hibernation working reliably.
I don't use laptops that much, but counting all distros I ever tried that with the success rate is definitely less than 50%. More like 10%.

I have had it too. But you're asking a new instance of each daemon to pick up the config & state of play of the previous instance, which I think is always going to be trouble prone.

What I meant:
I had it working reliably on one distro on one laptop - for a long time. It wasn't error prone.

This box I have now used hibernate error free. But I'm not putting in the few hours of reading, farting about, and (probably) point & click configuring to get it right; On a list like this I'd have to test it a number of times to avoid looking like a twit anyhow. I can simply dispense with the option. Battery times here disappointing to put it mildly. And It's impractical for me to move it anyhow.

Your soundcard might have changed index # and stuff.

$ cat /proc/asound/cards

Before and After the hibernate. See if it's different. It might be as simple as running pavucontrol and disable/enable the soundcard (which you sometimes have to do without doing anything related to hibernate). Or more complex like changing configurations to adapt. Or worse, logging out and back in to have sound again.

I've just had a morning of farting with my sound system and given myself a lesson on the interdependent unreality that sound is these days. As a simple shot to nothing try this: Can't do any harm but returned reality here, because my system was only restoring.