Check if on audio thread

Is there a simple call to check if we’re on the audio thread?
I’d like to use it for some jasserts to avoid developer stupidity.

What I’m using to check if we’re currently on the message thread:
jassert(juce::MessageManager::getInstance()->isThisTheMessageThread());

jassert(!juce::MessageManager::getInstance()->isThisTheMessageThread());

Doing anything more fancy is going to be complicated. There might not necessarily be just one audio thread due to the host’s multithreading. There’s no reason to assume the host will be calling the same plugin’s audio processing always from the same thread. (For example Reaper uses a multithreading model where whatever worker thread happens to have the chance to process the track and its plugins, gets to do the work.)

4 Likes

Thanks, that makes sense. It’s just an assertion to make sure I don’t accidentally screw up coding anyway, so it’s perfectly fine for my use case.

I have to report that this line sometimes falsely asserts, even when being called directly from processBlock. I’m on Logic Pro X.

The isThisTheMessageThread() is usually used, because many operations on the message thread are not designed to be thread safe. The intention is, to make sure some operations, that access data, that the message thread accesses as well, cannot come from another thread.

Maybe the opposite assumption is not always true. I don’t know, if the host is not allowed to call processBlock from the message thread? (Maybe to flush parameters or whatever…)

Logic does surprising things sometimes…

2 Likes

Yeah, I came to the same conclusion.
Just wanted to share it here to make people aware that this does not seem to be a catch-all solution :slight_smile:

1 Like

I think in non realtime mode some hosts use the message thread for processBlock(). It’s feasible anyway.

2 Likes

You may check this other topic: Class for detecting unsafe operations in realtime contexts