I think this is mostly due to a) the pipeline from VMs through pulseaudio/pipewire allowing config changes to dom0 hardware based on source material sample rate/width changes (even from VMs) plus b) recent kernel/sound driver work creating defects that can be triggered by these types of hardware/driver changes.
I’ve found that playing any audio file in dom0 at (software) volume 0 in an infinite loop prevent the dom0 kernel/driver bug from triggering and allows audio to work, probably as this forces software blending of sources instead of hardware/driver config changes to match a single source. Of course this annoyingly uses processing power to block a defect trigger.
Apparently the kernel/driver bug doesn’t seem to trigger in bare metal Linux but only in Xen hosted Linux. It appears to be related to dma buffer creation/handling.
B