# AudioPluginHost CPU cores usage **URL:** \ **Category:** MacOSX and iOS\ **Created:** [August 28, 2019, 1:37pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970 "2019-08-28T13:37:45Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 28, 2019, 1:37pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/1 "2019-08-28T13:37:45Z")
Hi, I’m studing around AudioPluginHost code because i’m interested in create my mini little daw. I’d like to understand how to take most of CPU cores, for example I notice that in logic pro every time I instantiate a plugin a core is awakened, while in audioPLuginHost I can see with Monitor activities of osx that only the first 3 cpu are working. What’s about it? there’s a way to optimize it? which the best approach that I should adopt? Really thank you in advice? ---
**Author:** ![xenakios](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/xenakios/32/4047_2.png) [@xenakios](https://forum.juce.com/u/xenakios)\ **Post date:** [August 28, 2019, 1:46pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/2 "2019-08-28T13:46:05Z")
The Juce Audio Plugin Host uses just 1 CPU core (or rather thread) for the audio processing, since it’s based on the Juce AudioProcessorGraph that doesn’t multithread the audio processing. The activity you see in the multiple cores is from the GUI thread, the single audio thread, possibly some hosted plugins using their own threads for internal tasks and the OS migrating threads between the cores. So most likely, if the OS thread migration and the plugins possibly using their own threads wasn’t taken into account, you would see the Juce Plugin Host using about 2 CPU cores at maximum. There is no Juce provided ready-to-use solution for this. ---
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 28, 2019, 3:09pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/3 "2019-08-28T15:09:24Z")
😱 what bad news! Really there’s no way to achieve this?? So I can’t develop my app with juce or there are some hacks in framework that I could do to Archive this? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [August 28, 2019, 3:43pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/4 "2019-08-28T15:43:27Z")
You will have to come up with strategies about: - how to balance the load over the available cores - how to synchronise the results of the threads, and how to deal, if one or several of them doesn’t finish in time - can you distinguish between interactive parts (low latency) and fixed tracks (already recorded, no plugin GUI open, no controller on latch), so you can pre-render them with larger buffers - how to have the necessary recorded audio in memory available, streaming from disk might be too slow To preprocess there is [BufferingAudioSource](https://docs.juce.com/develop/classBufferingAudioSource.html), which you can use. It uses a TimeSliceClient, which effectively uses a thread To have audio in memory, there is [MemoryMappedAudioFormatReader](https://docs.juce.com/develop/classMemoryMappedAudioFormatReader.html) To have a good setup, you need to know more about the routing options. The AudioProcessorGraph is probably too generic to allow a solution, that works in all instances. For a quick win, maybe looking at the Tracktion engine might be a good idea ---
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 28, 2019, 5:03pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/5 "2019-08-28T17:03:03Z")
Really thank you! I’ve just downloaded tracktion engine and started to look around it (unfortunately there’s not documentation to understand things quickly). On base of your experience it is thought to work on multicore processing or also here there’s needing of some tricks? ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [August 28, 2019, 5:32pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/6 "2019-08-28T17:32:29Z")
It really depends, what restrictions you can allow. If many tracks can be individually be switched to record, it can become infinitely difficult, vs. if you have only one track on record at a time, and anything else is streamed from existing material, it can be (almost) a piece of cake… Having sends and side chains add another level of complexity to the problem. Also latency compensation (especially in combination with sends) will probably create headaches The engines I wrote were rather trivial in that regard, so hopefully you get more tangible estimates from people, who wrote full featured DAWs like jules and dave96, or the many other users here, who have done that… ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 28, 2019, 6:00pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/7 "2019-08-28T18:00:50Z")
> [@ayra.productions](#): > > On base of your experience it is thought to work on multicore processing or also here there’s needing of some tricks? If you mean “does the tracktion engine do multi-threaded rendering” then yes, it does. Certainly if you’re a beginner then it’d take you years to write a decent multi-threaded renderer, so letting the engine handle all that for you is probably your best bet. ---
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 29, 2019, 11:35am UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/8 "2019-08-29T11:35:16Z")
Thank you again for your replies! I think I need to learn more about Tracktion engine potentiality to understand how much has already been implemented and how much is to be implemented for my purposes 🙂 ---
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 29, 2019, 11:48am UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/9 "2019-08-29T11:48:34Z")
Thank you for your reply, my question was about real time processing. To let you understand: I’m studying to develop an audio unit mixer for live performances, a little version of main stage or a desktop (and mobile version) of AUM, so: some Audio/instrument/midi channel strips, some busses to route signal to fx tracks and to route channels to outputs of audio devices. I have 18 core fisical cpus for example and I’d like to know how much my program, using tracktion engine, should exploit them. Thank you again in advice ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [August 29, 2019, 11:55am UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/10 "2019-08-29T11:55:06Z")
The tracktion engine currently uses a thread pool to parallelise on a track-by-track basis. But really, the easy way to find out how the engine performs is just to run Waveform and set up a project with the kind of plugins and bussing you want. ---
**Author:** ![Ayra](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ayra/32/5775_2.png) [@Ayra](https://forum.juce.com/u/Ayra)\ **Post date:** [August 29, 2019, 12:16pm UTC](https://forum.juce.com/t/audiopluginhost-cpu-cores-usage/34970/11 "2019-08-29T12:16:05Z")
Of course! My gripe now is to get a first beta in relatively little time to test it (using some time to undestand trivially which should be the corret gesture to use on mobile for example), but to do this I must test it in real world project, using a lot of tracks and plug-ins, obviously in release time I’ll need of course to spend a lot of time to optimize it, but for now, also if not totaly optimized, usage of all fisical cores in a pc or mobile is important! Really thank you again!! 🙂