Using Multiple Threads In Audio Thread

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

mystran wrote: Tue Dec 14, 2021 3:29 pm ...and almost any method will give you access to the native handle you'll need to set an RT policy too.
So plugins can be kind-of malicious with the host's thread pool. I guess that getting the thread info before running a task and restoring it afterwards might be necessary for hosts. This provided that the non-modified thread properties case is very cheap (info on thread local storage, no syscall made if no changes) and only plugins doing wrong pay for it.

Post

rafa1981 wrote: Tue Dec 14, 2021 3:55 pm
mystran wrote: Tue Dec 14, 2021 3:29 pm ...and almost any method will give you access to the native handle you'll need to set an RT policy too.
So plugins can be kind-of malicious with the host's thread pool. I guess that getting the thread info before running a task and restoring it afterwards might be necessary for hosts.
Why would you possibly want to mess with the host threads from the plugin though? You can already do this kind of stuff with the regular host threads in any plugin if you absolutely want to, but it just doesn't make any sense whatsoever.

edit: My point wasn't that plugins can mess with the host threads, but rather that the actual thread creation method doesn't make a whole lot of difference in practice.

Post

Urs wrote: Tue Dec 14, 2021 2:54 pm
otristan wrote: Tue Dec 14, 2021 2:27 pm Do you guys use pthread API to create those worker thread on OSX or use custom OSX stuff ?

Thanks !
For the thread pool? - I have no idea, this comes from the host developers we work with.

In our plug-ins we use boost::thread afaik.
So you don't set any realtime thread flag ?
Olivier Tristan
Developer - UVI Team
http://www.uvi.net

Post

otristan wrote: Tue Dec 14, 2021 4:37 pm
Urs wrote: Tue Dec 14, 2021 2:54 pm
otristan wrote: Tue Dec 14, 2021 2:27 pm Do you guys use pthread API to create those worker thread on OSX or use custom OSX stuff ?

Thanks !
For the thread pool? - I have no idea, this comes from the host developers we work with.

In our plug-ins we use boost::thread afaik.
So you don't set any realtime thread flag ?
Yes we do, something about Quality of Service, but that's beyond my knowledge of the topic.

Post

Alright. Because it probably plays a bit in the benchmark as well.
Olivier Tristan
Developer - UVI Team
http://www.uvi.net

Post

mystran wrote: Tue Dec 14, 2021 4:03 pm Why would you possibly want to mess with the host threads from the plugin though? You can already do this kind of stuff with the regular host threads in any plugin if you absolutely want to, but it just doesn't make any sense whatsoever.

edit: My point wasn't that plugins can mess with the host threads, but rather that the actual thread creation method doesn't make a whole lot of difference in practice.
I wouldn't either. But who knows what people might be able to come with, which bugs can happen, etc. Probably I'm too paranoid.

My point was unrelated to the thread creation method. Your comment just reminded me that fact.

Post

mystran wrote: Sat Oct 16, 2021 5:10 pm Launching new threads in audio code is not a good idea, but you can use a threadpool just fine (eg. I do all the time). Basically when the plugin DLL is loaded, I fire up one thread per CPU and bump them up to real-time priority. Then they wait on a queue. Then when I have something that can be done by a worker thread, I put that work (eg. one job for each voice) into the queue. Then wait for all the jobs to finish. Multiple instances of the same plugin can share the same threadpool.

It's a good idea to check the blocksize and process very short blocks directly (eg. some hosts sometimes pass the occasional single-sample block even if the average is much longer) to avoid threading when the sync overhead would be higher than the processing cost, but other than that it "just works" except for the slightly unfortunate situation of not being able to share the same worker threads between multiple plugins and the host.
How can sharing threads across multiple plugin instances be done? Wouldn’t there be security measures to prevent that?

Post

SNFK wrote: Mon May 16, 2022 12:38 pm How can sharing threads across multiple plugin instances be done? Wouldn’t there be security measures to prevent that?
What I wrote above assumes all the instances run in the same process. Usually this is the case. When they are in the same process, it's a matter of sharing a pointer and there are no security measures against passing around pointers within a single process. The canonical solution is to make the pool itself a singleton (eg. created first time it's requested).

Post Reply

Return to “DSP and Plugin Development”