If I remember correctly, that implementation details of realtime threads/priority management (and the mechanism for changing the priority) was heavily overhauled early in v7 (Thread: Introduce a new Thread backend · juce-framework/JUCE@d3cff37 · GitHub)
and after problems on different system (especially MacOS) got a few rounds of fixes mainly based on this thread: [Bug] Serious Problem with HighResolutionTimer since JUCE 7.0.3
Therefore, the original problem with starting realtime threads described here might have been fixed.
Concerning the task of shuffling samples from one point to another: I also don’t see the point in trying to start two threads, that are essentially doing the same work. If you can pickup samples from Audinate at an “arbitary” time, you can do that directly from your JUCE callback.
If Audinate is actually the one supplying the thread and you merely hook a callback, you run into a similar problem (with a similar solution) as Using different audio devices at the same time?