Fixing crackling/skipping/glitching issues with Pipewire and Wireplumber

For the last two NixOS releases, I've been having audio issues with Pipewire, using Wireplumber as the audio server. There was an imperfect correlation to high system load, but particularly starting and quitting games often caused the problem to get worse until the next restart (of Wireplumber and sometimes the whole system). 
 The issues manifested as (variously) crackling, skipping (eg. in music), and sometimes very loud and high-pitched glitched noises. Making it very irritating to listen to music or watch a video. 
 Anyway, turns out that the problem seems to be in pipewire-pulse , which according to some random comments on the internet is notorious for these sorts of issues. I don't know if that's true, but it certainly seemed to be responsible here. Disabling it (in NixOS, setting  services.pipewire.pulse.enable to false instead of true ) seems to have solved the issue, but more testing will be necessary to see if it's a permanent fix. I don't yet know whether it breaks any applications due to PulseAudio support now not being there anymore. So far everything works. 
 And yeah, almost every thread tells you to change the quantum values. And sometimes people claim that the defaults are "bad". But I have my doubts about that, and it sounds an awful lot to me like treating symptoms based on observations and superstitions (with possibly unwanted side-effects like higher audio latency), and it certainly doesn't solve the  cause of the problem. Yep, changing the quantum values made the problem less prominent for me too. But it never solved it and that's probably because it was just masking the symptoms. I'd suggest not changing the quantum values and instead figuring out why the issue is happening in the first place. 
 Also, as a more general note: "the defaults are wrong" is unlikely for just about any problem, especially for widely-used software. The developers are probably aware of the issue you're running into, and there's probably a reason that the defaults haven't been changed, even if you're not personally aware of those reasons. Spend that extra bit of time to understand why the defaults are what they are, and whether maybe you're just misunderstanding the problem. The toxic Linux culture of "constantly bashing on developers based on a half-understanding" is tiring and I want to see less of it. You're not helping anyone with it, all you're doing is making it harder for people to find the solution because they have to wade through a mountain of Bad Opinions first. 
 Like how I ended up spending months trying to track down why my audio was crackling because everyone was just blathering on about quantum values. 
 Update: more issues 
 As I've been testing and debugging these issues more and more, I've been running into weirder and weirder factors that could be contributing to it (and I still have no idea which ones contributed to which degree). A whirlwind tour: 
 
 There's a bug in the fTPM on many Ryzen CPUs. It's fixed with a new firmware from AMD, which your motherboard vendor should have shipped a while ago. Make sure you're updated. If your motherboard vendor hasn't issued an update, consider disabling the fTPM in your BIOS/UEFI (note that this will break anything that uses it, eg. Bitlocker on a Windows install). 
 There's a bug in certain versions of the realtime portal for xdg-desktop-portal, causing Pipewire to fail to acquire realtime privileges. In order, Pipewire tries rlimits (system configuration), the realtime portal, and then RTKit (a separate daemon). You may need to update some stuff or, if unable to, disable the realtime portal usage in Pipewire to force a failover to RTKit, depending on your circumstances. 
 In my case, one certain source of issues was a bizarre one: the "GPU usage" meter in htop. Having it enabled on my (AMD CPU, AMD GPU) system causes the audio stutters to occur whenever htop is running. Disable the meter and it goes away. I have no idea at what layer of the system this is happening, and I'm not sure I want to know. 
 
 By the way, everybody tells you to use pw-top. Consider that its ERR column can be very misleading about where an issue actually occurred. I'd recommend setting log level 3 for Pipewire globally instead (while debugging), and looking at the logs, which are much more informative. 
 I think I've gotten rid of all the sources now. By this point I'm highly skeptical that I've found the actual root cause, and the real problem is probably somewhere deeper in the system that I can't easily debug. But for now, I am free from the tyranny of stuttering music playback!