If you have CLAP thread pool available, I don't really see the point of using your own pool... but if you don't have a host pool, then it obviously makes more sense.the spikes/jittter is about the same, though.. i don't do much (yet) to configure the threads, so, maybe a few things to tweak there.. i just start 12 of them (as many as my cpu have), and hope the best.. not sure how much it is worth fighting with the host's threads?
Spikes/jitter can happen if your threads are running at interactive priority, 'cos the system might schedule any random thread from any application at any time. The details vary, but the basic idea is that with interactive priority class, the system tries to be somewhat "fair" such that if high priority tasks hog all the CPU, the low priority tasks still get some anyway, but also there tends to be heuristics to improve interactive with things like extra priority for window under mouse, or thread that just finished IO or whatever stuff that's... probably not very important when you're trying to hit a strict audio deadline.
If you are doing realtime processing (ie. audio processing), you want your threads at some realtime priority, typically the same priority as the host threads (which.. most of the time is the highest you can get). Realtime priorities are treated more strictly: the highest priority task runs. There are safe guards on modern systems against completely locking the system (eg. on Windows MMCSS reserves at least 10% and by default I guess 20% of the CPU time for interactive threads), but essentially as long as your CPU usage doesn't exceed such a safety limit, your thread is always scheduled first if it's the highest priority thread.
Statistics: Posted by mystran — Sat Aug 17, 2024 9:22 pm