The new problem that happens in the same circumstances is that whenever MOC starts playing something (including a new track), the playback point slides forward by a few seconds at maybe 50x rate (including the garbled/staticy noise generated by this) before continuing normally. [Edit to clarify: this problem showed up in place of the other when I disabled timer-based scheduling.] If I let it sit for a few minutes after pausing, it probably won't do this, but if it hasn't been more than ~15 seconds, it will slide almost every time. Average slides might be 5 seconds, but some are barely perceptible and some are by as much as a minute. If something else is playing at the same time, the slide will be much slower, like 10x rate, but distances seem to be the same. I haven't tested every use case I've got, but VLC and Youtube both seem to be flawless now.
The only other thing that seems odd or wrong about this audio config is that the card shows up as "HD-Audio Generic" in some places. Alsamixer shows both HD-Audio Generic and Realtek ALC1220 (card and chip, respectively). The right kernel modules seem to be loaded and kernel logs show nothing amiss. MOC won't give me any useful info at all. Without -v, the only unexpected text pulse ever throws out is this:
E: [alsa-sink-ALC1220 Analog] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
E: [alsa-sink-ALC1220 Analog] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
E: [alsa-sink-ALC1220 Analog] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
This only happens once per boot of pulse, generally within a few minutes of startup, and doesn't seem immediately correlated with the start of the glitch (but it's possible it is). With -v, pulse mostly spams stdout with ridiculous amounts of redundant info on mundane activity, and I can't find anything amiss throughout that. That spamming does slow down the slide rate a bit though, and the amount of spam when sliding is as if the skipped audio had actually been played.
[Edit again: Cutting pulseaudio out of the loop and just using ALSA fixed the other problem with all programs that worked. MOC was not among those, throwing a "ALSA lib pcm_dmix.c:1099:(snd_pcm_dmix_open) unable to open slave". Doesn't look relevant, but it seems worth mentioning and is a slight hole in my debugging efforts.]
I really have no idea how to proceed in debugging this further. Does anyone else have any thoughts?