This is kind of a late comment, but I noticed something weird happened when I upgraded my Debian system to use Linux kernel 6.0.0 (I had been using a version in the 5.15 series).
I still don't have PulseAudio installed (I don't need it, that's all). But periodically, when I suspend the 6.0.0 system, when I come out of suspend I can't hear any audio (or occasionally it comes out sounding extremely faint).
I haven't found any consistent factor that always causes this problem to happen -- for me too, it's a rare issue -- but I have noticed that the chances of this occuring are elevated if I switch my headphones from the front audio jack on the computer to the back, at least when I do so while the computer's suspended. I don't know why this is the case. I doubt it's terribly similar to your issue with HDMI audio, especially since I doubt you switch HDMI ports while the system is suspended.
For me anyway, when I get into such a jam, the following series of commands works for me. I condensed it into a one-liner for compactness. All it does is unloads the sound-related kernel drivers that are currently loaded, and then reloads each of them one-by-one:
echo; \
SOUND_MODULES=$(lsmod | cut -d\ -f1 | grep -E '^snd_'); \
if [ -z "$SOUND_MODULES" ]; then \
echo -e 'Oddly, you do not seem to have any sound drivers loaded! This might be a problem for playing back sound...\n'; \
else \
echo -e "Unloading all sound card drivers...\n"; \
sudo rmmod ${SOUND_MODULES}; \
echo -e "Pausing for 5 seconds to allow applications to notice that the sound drivers were unloaded...\n"; \
sleep 5; \
echo -e "Reloading all sound card drivers...\n"; \
sudo modprobe -a ${SOUND_MODULES}; \
echo -e 'Done! Does the sound work now?\n'; \
fi
It works for me every time. It seems that the sound drivers sometimes get confused when the computer comes out of suspend. I have a hunch that this could be more of a problem on multi-core machines (how many cores did you say this thing had?). It's common for program bugs to lead to one core doing something with hardware in general while some other core does something else to the same hardware at the same time; this leads to a so-called race condition, and the problem is a concurrency issue.
Try out this loading-and-unloading workaround the next time the problem rears its ugly head. If this command chain works, great -- we're one step closer to tracking down this darned problem and sending it back to where it came from: the deep, dark place where bugs live. 
