Hi, when creating an engine this is defaulted to 512 and can’t see any easy way to change this.
Anyone know how to do this? Thx
Return false from your EngineBehaviour::autoInitialiseDeviceManager function and then manually call DeviceManager::initialise (numIns, numOuts).
1 Like
thx for the fast answer - another Q - is Tracktion engine actually supported on Android - only asking as there’s no exporter setup for the DemoRunner app.
I’ve created a simple fileplayer with 2 fx which is running on Mac and Android and it’s sitting at 60% CPU on Adroid even when idle. Is this a platform that can handle the engine?
Thx
Android should be supported, we have customers using it on that, it’s just not really widely used and the toolchain is so poor (at least it was the last time I looked at it) it’s not economical for us to continually test with it.
Is that performance in debug? I think you’d need to profile to see where the CPU use is.
We’re constantly improving performance but having a profile from Android would be useful.
debug and relase and about the same CPU - I’ll have a look into it - thx
have to say, AS have improved over the last couple of years - it’s only a mild pain to use these days rather than a complete pain 
Just for refererence, Mac is idling at 0% and iPhone13 about 10%
Wonder if this might be related to reported CPU usage on Android - app is showing 60% but CPU monitor in AS showing 20-30% with occasional spikes.
That said there’s clearly something I need to investigate - I have a comparison app where the audio is coded myself and when there’s no audio playing and the 2 fx are off there’s no CPU being used.
In Tracktion when no audio is playing and the 2 fx a lot of CPU is being used.
@dave96 not really that familiar with the android audio system - can I send you the test app I have for you to have a gander at and see if you can spot anything from the profile?
An Android app? I’m afraid I don’t have a device to test with at the moment.
If you can send me a profile trace that would be better.
Regarding comparisons to your own app, remember that in Tracktion Engine, the audio is always playing (and hence plugins being processed). This is the only way you get to monitor what you’re playing and allow for things like reverb tails. So you may not be comparing apples to apples.
1 Like
ok, that’s good to know. even with that, I’m getting about 50% more CPU on the tracktion version it would seem, with spikes every now and then.
I’ll do some more looking into it - the profile traces are pretty useless - they don’t seem to go into any tracktion user code - it’s just a big black hole.
e.g.
Maybe there’s some options I’m missing - will keep exploring.
FYI, the situation is easily visible in an emulator so physical device isn’t needed.
Can you also try briefly using a single thread for audio? EngineBehaviour::getNumberOfCPUsToUseForAudio()
I’m wondering if the thread scheduling or use of efficiency cores is stalling the processing.
I also know there’s some code to use the audio thread for as long as the buffer is. That used to be recommended behaviour for Android. Not sure if its still necessary. If not, maybe comment out the JUCE_ANDROID code in tracktion_DeviceManager.cpp?
1 Like
That’s useful to know. I don’t actually know what I need to do to get that far though.
Are there some simple steps to follow? Ideally, how do I clone the tracktion_engine repo and get our Benchmarks target running in the simulator?
1 Like
great - will give that go.
I’ll take a look at that.
Hi - the number of CPUs didn’t make any difference, but commenting out the code in DeviceManager definitely reduced the amount of CPU usage.
To what kind of level?
1 Like
The CPU usage reported by deviceManager.getCpuUsage() has dropped by about 40% - the CPU usage on the profiler has dropped about 20%. There’s still quite a lot of spikes, but overral CPU usage has dropped quite significantly. More importantly occasional audio dropouts have stopped - this is quite an old device i’m testing on (maybe 5 years old) so it’s not got a monster CPU in it.