So a threading question for the threading gurus on here.
For all of my processing/analysis in SP-Tools I’m using @blocking 2 and I always run Max with overdrive on and audio interrupt off and this works well. Super fast, no glitches, all good.
However, in Live, audio interrupt is on (permanently afaik) which means that when using lower vector settings in Live, I hear some glitches since it’s apparently running out of time to do what it needs to do without interrupting the actual audio thread. This is even with CPU usage being like ~3% or so.
A couple (SP-Tools) users have mentioned this but I hadn’t encountered it at all. Until I went to low vector settings and started seeing it.
So what I’m thinking is just chucking a defer between abstractions when making the M4L device versions would move things down to @blocking 1 without me having to build all kinds of am-I-running-inside-Live? conditions everywhere.
My concern, however, is that this would occasionally introduce latency/jitter, or rather, make it more sensitive to processing load.
Is there a(nother) “best practice” for dealing with high-priority threading inside an audio interrupt world?
Not really. It all gets kind of annoying. In principle you could reason that any nrt analysis is the stuff you really don’t want to happen on the audio thread, because it’s not deterministic. But then if you have analysis and querying running on different threads, you need to be super careful in order to avoid beach balls.
In the first instance, try running on the main thread and seeing if it’s liveable with.
1 Like
Hmm, that’s what I feared/imagined.
I suppose that for this kind of thing that I’m doing, the “optimal” threading is high-priority + non-audio-interrupt, which is a combination that is not possible inside Live.
I’ll experiment with defer and see how it goes. Avoiding glitches is the first priority then beyond that having it be as fast as possible is the next ideal.
Re-complex threading, most of the abstractions have a top-level process (general onset-detection) that then propagates down while still in high-priority.
Phew, just had a mini-panic attack as the structure of the patches has the threading set inside the same patch that does the analysis/querying/etc…, so I thought I would have to add environment-aware flags everywhere to avoid that, but a quick test tells me that having a high-priority message going through defer into a fluid.buf process with @blocking 2 spits out its results in the low priority thread (at least as reported by getthread). So that’s comforting.
I’ll probably have to restructure the M4L devices anyways to make sure I can insert defer wherever they need to be, but shouldn’t be the end of the world.