Comment 2 for bug 1928996

As a quick update, I managed to kill all of the spurious pulseaudio processes that had been lying around as a result of `pulseaudio -k && pulseaudio --start` and got the systemd pulseaudio process back on its feet. Then I confirmed that the audio worked, suspended my system, and woke it up again and the audio still works!

Therefore I suspect that pulseaudio processes started by the user in terminal sessions (daemonized) do not survive the suspend/resume cycle for some reason(?). How the systemd pulseaudio process failed to begin with remains the larger issue, however.