@mattiasnyc, thanks for the additional info.
Re: unrecoverable situations observed with Ryzen and Threadripper: It's certainly not the CPU that gets stuck; rather the software stack doesn't recover properly from the under-/overrun. As you indicated, there is a big matrix of parameters (audio device driver, buffer size : sample rate, channel count, plugin count), whose combinations just cannot be entirely tested by the developers of the software stack's x-run recovery routines.
I asked for buffer sizes earlier because it makes a difference if live manipulation of an audio stream is the goal (with humanly imperceptible delay between live recorded input and live played back output - which needs very small buffers, such that system latencies can become an issue, e.g. from badly behaving drivers, regardless of CPU power) --- or if merely manipulation of a prerecorded stream is the goal (such that moderately large audio buffers can be set).
All in all, I believe that this sort of testing requires a basic experience with the setup of an audio workstation, otherwise you are bound to get confusing results. At the very least, the rather large parameter space needs to be narrowed down.
Edit: And the software better detects and reports x-runs itself, because having to rely on the user to perceive x-runs as clicks or pops is not really objective testing.