Using Multiple Threads In Audio Thread

DSP, Plug-in and Host development discussion.
User avatar
Urs
u-he
26013 posts since 8 Aug, 2002 from Berlin

Post Mon Oct 18, 2021 5:19 am

rafa1981 wrote:
Mon Oct 18, 2021 3:42 am
  • Same with extremely small block sizes. The DAW would make the decision, not every plugin.
If plug-ins break up process calls into smaller units e.g. to react to note, automation or timing events, they will call the thread pool several times. So there will be *some* responsibility left with the plug-in to decide whether or not it is a good idea to parallelise.

KVRian
569 posts since 4 Jan, 2007

Post Mon Oct 18, 2021 5:36 am

Urs wrote:
Mon Oct 18, 2021 5:19 am
rafa1981 wrote:
Mon Oct 18, 2021 3:42 am
  • Same with extremely small block sizes. The DAW would make the decision, not every plugin.
If plug-ins break up process calls into smaller units e.g. to react to note, automation or timing events, they will call the thread pool several times. So there will be *some* responsibility left with the plug-in to decide whether or not it is a good idea to parallelise.
I could argue that every voice could have its monophonic list of events and process the whole block anyways.

Having each task definition passing some weighting (e.g. the number of samples) could also be possible.

The point of my previous message was for the API to enable the DAW implementor dispatching to a specific CPU, do things depending on the processor, platform, etc. Maybe it's possible with the current API already.

User avatar
KVRian
939 posts since 31 Dec, 2008

Post Mon Oct 18, 2021 10:04 am

I just feel the need to clarify here that plugins that internally use very small sample blocks (or sample by sample). Don't necessarily need small blocks between themselves and the DAW. Unless the DAW it self is modular (like Plogue Bidule) where you can create feedback loops in between plugins. Since the main purpose of very small block sizes in this case is to have minimum (or small) delay feedback loops.
Last edited by S0lo on Mon Oct 18, 2021 10:45 am, edited 1 time in total.

User avatar
KVRian
786 posts since 6 Aug, 2005 from England

Post Mon Oct 18, 2021 10:38 am

I personally find the trick to threads is not to think they are ALL MINE( :evil: !). A voice channel can be filled pretty quickly, and yield/wait/sleep (whatever your API) allows others to share the process.

KVRAF
7111 posts since 17 Feb, 2005

Post Mon Oct 18, 2021 12:22 pm

Urs wrote:
Mon Oct 18, 2021 5:19 am
If plug-ins break up process calls into smaller units e.g. to react to note, automation or timing events, they will call the thread pool several times. So there will be *some* responsibility left with the plug-in to decide whether or not it is a good idea to parallelise.
Also, the particular algorithm in use inside the plugin may or may not be parallelizable. I think there is responsibility for the plugin to report when a task should be run on another core, if it's available.

KVRAF
6574 posts since 12 Feb, 2006 from Helsinki, Finland

Post Tue Oct 19, 2021 2:59 am

quikquak wrote:
Mon Oct 18, 2021 10:38 am
I personally find the trick to threads is not to think they are ALL MINE( :evil: !). A voice channel can be filled pretty quickly, and yield/wait/sleep (whatever your API) allows others to share the process.
Don't yield. Don't sleep. Either is bad, 'cos either leads to unnecessary wakeups. Just wait on a sync object, which should be a classic Dijkstra's counting semaphore guarding a message queue about 99% of the time.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

User avatar
KVRian
786 posts since 6 Aug, 2005 from England

Post Tue Oct 19, 2021 5:20 am

Yeah. I'm currently trying Juce's notify() & wait() to trigger and suspend threads, which apparently doesn't use semaphores. I have a user option to turn off and on multithreading, just in case.
https://forum.juce.com/t/semaphore/8602

KVRAF
6574 posts since 12 Feb, 2006 from Helsinki, Finland

Post Tue Oct 19, 2021 3:56 pm

quikquak wrote:
Tue Oct 19, 2021 5:20 am
Yeah. I'm currently trying Juce's notify() & wait() to trigger and suspend threads, which apparently doesn't use semaphores. I have a user option to turn off and on multithreading, just in case.
https://forum.juce.com/t/semaphore/8602
Well, I guess they use condition variables (or "events" which are the same thing). Those are probably the next-best thing if you insist on not using semaphores because they are unpopular. You'll still more or less necessarily end up with an algorithm that wakes up threads too often, but it's not that bad I guess. See... Dijkstra's semaphores were the original sync object and all these fancy things are solutions to the "problems" that come when people can't understand the concept of counting.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

umd
KVRian
1071 posts since 26 Feb, 2006 from Fartland

Post Tue Oct 19, 2021 4:35 pm

I think it's a great idea for simple polyphonic synths, for example. But don't think too much about it!

Remember, even if it is not according to Moore's law, chips will always get faster anyway.

( 40 years later CMI is now running in a phone probably faster than ever )
Free midi plugins and other stuff:
http://jstuff.wordpress.com/

User avatar
KVRian
786 posts since 6 Aug, 2005 from England

Post Wed Oct 20, 2021 10:28 am

umd wrote:
Tue Oct 19, 2021 4:35 pm
I think it's a great idea for simple polyphonic synths, for example. But don't think too much about it!

Remember, even if it is not according to Moore's law, chips will always get faster anyway.

( 40 years later CMI is now running in a phone probably faster than ever )
Why just 'simple' synths? If you can't plan and code threads efficiently then just give up now... :hihi: :P
If you cripple a system's resources by grinding threads, someone will come along and reduce your thread allowance, and ruin it for the rest of us! Haha.. oh...

KVRian
569 posts since 4 Jan, 2007

Post Wed Oct 20, 2021 12:43 pm

mystran wrote:
Tue Oct 19, 2021 3:56 pm
Those are probably the next-best thing if you insist on not using semaphores because they are unpopular...
And introduce unfairness, as locking on semaphores is FIFO for a given thread priority but for a condition variable order is not guaranteed.

So as you say, either the implementation is thread priority and enqueue-order aware and wakes up each thread on each notification or uses notify_one and becomes unfair.

Depending on the usage, fairness might not be important though.

My main problem with semaphores is that they only time out on the wall clock on POSIX (so it was 2-3 years ago). I don't remember if they were able to avoid syscalls when positive, I guess they should...

KVRAF
6574 posts since 12 Feb, 2006 from Helsinki, Finland

Post Wed Oct 20, 2021 1:48 pm

rafa1981 wrote:
Wed Oct 20, 2021 12:43 pm
mystran wrote:
Tue Oct 19, 2021 3:56 pm
Those are probably the next-best thing if you insist on not using semaphores because they are unpopular...
And introduce unfairness, as locking on semaphores is FIFO for a given thread priority but for a condition variable order is not guaranteed.
Sure, that's true (well, with the caveat that a practical semaphore might not be strictly FIFO, but in general at some point the thread gets put into a FIFO queue, so really it's just nitpicking). For worker threads extracting jobs from a queue that hardly matters though, since it doesn't really matter which thread wakes up.
Preferred pronouns would be "it/it" because according to this country, I'm a piece of human trash.

KVRian
569 posts since 4 Jan, 2007

Post Thu Oct 21, 2021 12:24 am

A bit off-topic, al least glibc has a recent extension (sem_clockwait) to use monotonic clocks on semaphores.
https://www.gnu.org/software/libc/manua ... locks.html

umd
KVRian
1071 posts since 26 Feb, 2006 from Fartland

Post Thu Oct 21, 2021 6:25 am

quikquak wrote:
Wed Oct 20, 2021 10:28 am
umd wrote:
Tue Oct 19, 2021 4:35 pm
I think it's a great idea for simple polyphonic synths, for example. But don't think too much about it!

Remember, even if it is not according to Moore's law, chips will always get faster anyway.

( 40 years later CMI is now running in a phone probably faster than ever )
Why just 'simple' synths? If you can't plan and code threads efficiently then just give up now... :hihi: :P
If you cripple a system's resources by grinding threads, someone will come along and reduce your thread allowance, and ruin it for the rest of us! Haha.. oh...
Probably our concept of "simple" is different, so I will simply give up now in an efficient manner. :ud:
Free midi plugins and other stuff:
http://jstuff.wordpress.com/

User avatar
KVRian
786 posts since 6 Aug, 2005 from England

Post Thu Oct 21, 2021 9:15 am

umd wrote:
Thu Oct 21, 2021 6:25 am
Probably our concept of "simple" is different, so I will simply give up now in an efficient manner. :ud:
If you mean each voice is so massively CPU intensive, and you can't divide up the task, then yeah, you probably should just slip out the door when no-one is looking... - I'm just kidding! 😁
Yes, chips are going slightly faster, but because of the limits of silicon, my guess is, the trend is more parallel processing.

Return to “DSP and Plug-in Development”