Using Multiple Threads In Audio Thread

[Urs]

• 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.

[rafa1981]

• 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.

[S0lo]

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.

[quikquak]

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

[camsr]

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.

[mystran]

I personally find the trick to threads is not to think they are ALL MINE( !). 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.

[quikquak]

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

[mystran]

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.

[umd]

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 )

[quikquak]

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...
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...

[rafa1981]

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...

[mystran]

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.

[rafa1981]

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]

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...
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.

[quikquak]

Probably our concept of "simple" is different, so I will simply give up now in an efficient manner.

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.