FR: Thread-Priority vs Efficiency/Performance Cores

General JUCE discussion
41

@t0m @oli1 and other admins. I would be willing to sponsor a prioritized fast-forward on this feature. That is, in some shape or form; Get the current workgroup from AudioDeviceManager (or AudioDevice) and have Juce::Threads join this group.
Same topic here: MacOS Audio Thread Workgroups - #3 by blackhawkbravo1

42

I’d wait for a proper response from the juce team. but I believe the latest version now does support this, if you use the Juce::Thread construct with the correct priority settings, assuming you are a host (not a plugin), and running on macOS X. Having said that my app still uses my own code which I posted as I am using openMP under the hood, which creates and manages its own threads, as it made the multi threading much simpler.

43

It’s still in review. Apologies for the delay - we have been waiting for a response from Apple about AUv3, but if we don’t hear anything by the start of next week then we will continue without AUv3 support.

2 Likes
44

You guys can probably release a version without AUv3 and add it later :wink:

1 Like
45

Bump :slight_smile:

1 Like
46

Hi @t0m

What is happening ?

Thanks !

47

We’re currently blocked by this issue that’s been taking up much more time than anticipated: [Bug] Serious Problem with HighResolutionTimer since JUCE 7.0.3

1 Like
48

oki doki. Thanks !

49

Bumpity bump :slight_smile:

50

Apologies for the delay.

4 Likes
51

Awesome!!! Thank you very much! Just to make sure I understand this correctly here: the docs from AudioWorkgroup specify that we are adding an already created and running thread. Is this thread supposed to be started with startRealTimeThread? And should the priority of that thread should be set to 10 by the RealtimeOptions? How about the other parameters of RealtimeOptions?

52

Hey!

You can use Thread with RealtimeThread::withApproximateAudioProcessingTime; This will allow you to create a suitable thread using the ‘samplesPerBlock’ and ‘sampleRate’ parameters in your prepare method. You shouldn’t need to worry about priority.

Here’s an example of how you might configure the thread:

class AudioWorkerThread : public Thread
{
public:
	AudioWorkerThread(const AudioWorkgroup& audioWorkgroup, int samplesPerFrame, double sampleRate) :
		Thread("AudioWorkerThread"),
		workgroup(audioWorkgroup)
	{
		const auto options = RealtimeThreadOptions{}.withApproximateAudioProcessingTime (samplesPerFrame, sampleRate);
		startRealtimeThread (options);
	}
	
	// stop as normal
	
private:
	void run() override
	{
		WorkgroupToken token;
		
		workgroup.join (token);
		
		while (! threadShouldExit())
		{
			// do work here
		}
	}

private:
	AudioWorkgroup workgroup;
};
1 Like
53

Is this also the recommended approach if your thread’s deadline is “asap”, but not directly related to the blocksize from the callback? Like when you need to process much more samples, but spaced in time, in short bursts?

I have not yet found this use case (pattern) in documentation.

Measurements have led me to use the regular “highest” priority, not the RT one, which works well for me. The workgroup and RT feature may be overkill for this use case. Just curious about recommendations for and the advantages of the workgroup feature.

54

Great!

Maybe provide a small code snippet showing how we can take advantage of this feature?

55

In Oli1’s comment right above my question

56

We implement the parallel worker pattern that shares a common deadline (that being the deadline of the audio thread workgroup).

I think you’re referring to the ‘asynchronous multi-deadline’ pattern that requires creating your own workgroup hierarchies, which we don’t support.

1 Like
57

Okay, just getting this straight. So the example you gave is how we make sure that on Apple (and M1) that the threads we create have equivalent priority to the main audio thread but can be on different cores? That is, P-Cores, not E-Cores?

What happens for other platforms?

58

This essentially lets the scheduler know to wake your threads around the same time as the audio thread. It doesn’t give any gaurantees (that I’m aware of) what core it will be executed on.

This is an Apple only feature.

1 Like
59

It is not possible to garantutee a P-Core only thread. MacOS will always demote you, when you overstep you boundaries of your deadline etc

60

Thanks for the explanations gentlemen.