Audiobus: Use your music apps together.
What is Audiobus? — Audiobus is an award-winning music app for iPhone and iPad which lets you use your other music apps together. Chain effects on your favourite synth, run the output of apps or Audio Units into an app like GarageBand or Loopy, or select a different audio interface output for each app. Route MIDI between apps — drive a synth from a MIDI sequencer, or add an arpeggiator to your MIDI keyboard — or sync with your external MIDI gear. And control your entire setup from a MIDI controller.
Download on the App StoreAudiobus is the app that makes the rest of your setup better.
Quantitative comparison of native and AU EQs in different IOS DAW/hosts
Introduction
When ProQ2 AU was announced, i had the idea of doing a test of the AU versus the native plugin in Auria Pro. I wanted to see how the EQs affected performance and how my iPad Pro 10.5 would keep up with a 'big' project and lots of EQs. So I picked out an old multi-track stem with 44 mono audio tracks added panning and 5 subgroups to get the base CPU when playing all these tracks.
Some days later, i decided to widen the project scope and add other hosts and all graphic EQs i have installed... and so measuring everything at took a lot longer. It became obvious that 49 native EQs don't bring the iPad Pro to its knees, in the end i even added multiple EQs to each of the tracks and subgroups to test 100 running native EQs.
Graphic EQ Plugins
I had a look at:
- native PSP Channelstrip EQ and Masterstrip EQ (Auria Pro)
- native ProQ2 (Auria PRo)
- native StudioEQ (Cubasis)
- native Waves Q10 (Cubasis)
- native AUM Parametric EQ node (AUM)
- ZMors EQ AU V1.4 (Auria Pro, Cubasis, AUM)
- FabFilter ProQ2 AU V1.0 (Cubasis, AUM)
- Blue Mangoo Parametric Equalizer AU V1.0.3 (AUM)
The focus of the investigation is on the performance and number of possible EQ plugins in different hosts and not on a comparison of the quality or usability of the individual plugins.
The test hardware/OS
- iPad Pro 10.5
- IOS 11.4
Base layout of the project files
- 44 mono audio tracks of 05:56 length
- 5 subgroups if supported by host
- 18 pannings of the tracks
.
Results
Every measurement was taken at least 5 times. Since each of the hosts does a different calculation of the CPU percentage, one probably can't compare the numbers between hosts.
Due to an memory limit for all instances of AU app, one can only open up a maximum number of instances of each AU. The number of instances that can be reloaded from a project file without problems is somewhat less. If one creates just one instance too much, all instances of the AU crash.
For each of the EQs added, i used a single bell filter between 500Hz and 5Khz, with a Q of up to +/- 5db.
Auria Pro V2.18
The current version does list the ProQ2 AU, so i could not test it.
Setup without EQs : 2-4% CPU
49 native PSP EQs : 20% CPU
49 native ProQ2 : 17% CPU
25 ZMors EQ AU : 69% CPU
100 native ProQ2 : 56% CPU
Cubasis V2.5
Cubasis does not feature sub-groups. I didn't find a numeric CPU percentage in Cubasis, only a bar-graph. Therefore i took 5 screenshots and then measured the active pixel width in relation to the 100% of the full bar.
Setup without EQs : 6-11% CPU
44 native StudioEQ : 15-20% CPU
44 native Waves Q10 : 36-56% CPU
25 ZMors EQ AU : 19-28% CPU
7 ProQ2 AU : 17-37% CPU
100 native StudioEQ : 19-26% CPU
100 native Waves Q10 : 88-98% CPU
AUM V1.2.5
I used 44 file players to play the stems. The panning of 18 tracks was done using the internal AUM stereo pan plugin. The 5 sub-groups were realized with AUM mix-busses.
Setup without EQs : 22-41% CPU
49 native param. EQs : 36-43% CPU
49 ZMors EQ AU : 36-53% CPU
24 Blue Mangoo EQ AU : 28-45% CPU
13 ProQ2 AU : 35-47% CPU
.
Conclusion
The iPad Pro hardware platform is capable of doing heavy studio mixing work - using/playing a large number of audio tracks and adding native, build-in EQ plugins does not stress the CPU at all - so there is enough room for more demanding FX plugins.
The AU plugin format brings some CPU overhead, but i suspect that adding an EQ to each of the 49 tracks/subgroups would not at all reach the CPU limit even for the complex ProQ2 AU. The crux lies in the memory limit imposed from IOS. AU develops really have to care about memory consumption per AU - or discuss with Apple that this limit needs to be raised or removed if Apple wants to bring AU forward onto the level of native plugins.
As an example of AU EQ with low memory profile, the AUM/ 50 ZMors EQs test shows that large number of AU instances are possible. But it should be clear that the more advanced plugins are optimized for speed and quality and therefore need more memory per instance to achieve their high optimization level.
.
Remarks
- I have informed FF about the low number of instances and they want to try to increase the number of possible AU instances.
- I also diskussed with Blue Mangoo about the AU total memory problem and they are looking into it.
- I admit that the formal form of this posting is quite boring compared to the more fun and relaxed postings in the AB forum, but after structuring my various test results it just developed that way...
.
Edits of this posting
21.07.2018/13:37 Added AUM native parametric EQ benchmark
21.07.2018/01:25 Added Auria Pro PSP channelstrip and masterstrip EQ benchmark
21.07.2018/00:45 Initial posting
.
TL;DR:
The use of native EQ plugins is still useful for larger projects since current IOS limits the number of possible AU EQ instances. The iPad Pro is a beast 
Comments
I know, i know - pics or it did‘t happen....
.
(The automatic channel numbering in Cubasis is one off, at first i mistacenly added a file twice...)
Impressed with the low footprint of Auria without FX. One important EQ is missing: Auria’s built-in channel strip EQ, which is in fact a PSP plug-in without a fancy GUI. Would love to know how much it can handle...
Good idea to add the PSP EQ for Auria even though its not a graphics EQ, i'll just did the tapping/setup and udpated my main posting
I think i also have some non graphics AU EQ, but setup allways takes a lot longer than with natives because i need to save the setup more often, restart to the host and reload to be shure that the parameter setup is correctly restored.
Very interesting, I love such comparisons.
Thanks for sharing!
And yes, the AU memory problem is a bad thing, esp. for any larger AU. Very strange idea of Apple. Our resident developers should communicate this more intense to Apple
Really cool stress test, thanks for this feedback !
My hat goes off for anyone willing to do this much legwork and share the results. Big thank you, sir!
Well done! @_ki .. good to see you posted this, after we were speaking about it, (in the Pro-Q 2 thread).
'One' of the main things that stands out (then and now) is users being aware that a project may *load crashed plugins, because they went over the limit (in AUM it’s 14) - for me- ..
Apple needs to remove the limitations, coz, how many users are going to be counting each and every plugin they load, (and we're just taking about eq's in these examples).
Useful info!
King
(* load?)
Good work, interesting reading!
@king777 Counting the plugins does not help, because for each plugin and host and also hardware the maximum number is different. One also can instantiate more plugins than reload them via the project file, as you also worked out in your tests - so it is never clear beforehand how many will work and when the project will break.
The problem is even worse:
Due to the autosave feature of the main DAWs Auria Pro and Cubasis reaching the ‚one too many’ state infact destroys the whole project, because you can‘t simply remove one AU plugin and then continue.
In Cubasis removing the ‚one too many’ plugin results in a broken project, the settings made to all other plugins is gone and Cubasis only shows ‚Audio Unit‘ in the insert slot.
In Auria Pro, trying to reload a project that went over the ‚max reload limit results in an app crash - i found no way load a previous auto project snapshot.
Thats why in my tests i did copies project before adding a new batch of AU plugins - but this is no solution for normal usage.
Yeah, we’re on the same page.
Folks, a lot of users most likely won’t/wouldn’t count, (even if it was possible to know the limit).
Even if the max for their situation was 20, and say 18 for a crashless reload, most are not gonna count to 18. One reason is because the plugin instances would not all be added at the same time, they would be added at various times during the project, (beginning, middle and end). A project can be going for month/years..
All Daws would have to have a built in notepad etc. or users keep track however (pen n paper) not gonna happen.
Anyway we can only inform, and bring about an awareness of the extent of the situation.
Conclusion-ish, we’re fundamentally saying the same thing, and it needs to be addressed (now rather than later).
I have, for example, 50 track projects in Auria Pro, how many plugins I have on each track, or even which plugins, I don’t know, without a lot of digging.
... Funny, as I just wrote that ^ last paragraph, I remember requesting a feature @ Auria forum (years and years ago). It was for some page/map or whatever, where we would be able to see what plugins were being used and where. My reason at the time was to know if I had plugins loaded that I didn’t need, anymore, or if a plugin was switch off but still using resources etc etc.. IIRC my idea was taken on board as a good idea for a future update (or something)
Anyway, at least people know more now!
As we say “prevention better than cure”.
King
—————
Added: there is also the possibility that plugin developers can code-in (if possible) a pop-up, informing the user that their limit is approaching for that particular plugin, (let the computer do the math). This pop-up would automatically adapt/calculate for each Daw/hardware/situation. Nothing’s impossible! (would rather have a pop-up than a crash or semi-crash = 'plugin crash').
This would/could be a workaround until it is fully addressd by Apple.
I know things will work themselves out!
“Who knows who’s reading this”..
@_ki
This is a brilliant post, thank you. My only critique is that it would have also been useful to see a comparison with the native AUM eq nodes in AUMs case.
@KING777 it's close to impossible to determine available resources on a general purpose CPU. Scheduling is the job of the operating system, not an application.
There is no classification of processes and there never will be - this 'flaw' affects less than 0.00001% of all users.
What you describe is standard in systems with dedicated DSP chips for ages, but even in such 'straight' environments efficient resource distribution is a tricky item.
Anyway, imho the real source of the problem is the project saving of DAWs.
A crash isn't convenient, but not that big deal... if at least the fundamental setup is recovered on restart.
If a supplier (in theory) just writes memory state to disk (fast and easy peasey), then this is for shure NOT the appropriate way to deal with it.
But not impossible!
“0.00001% of all users” they count.
I’m just saying what’s in my head and whoever sees it and can utilise any info I/we put forward, fine.
I’m no expert in the ins n outs of it all (coder) but hopefully some of my layman terms etc will help others. Its just highlighting/brainstorming.
“Anyway, imho the real source of the problem is the project saving of DAWs.” see, points/options are being brought forward.
✌🏼
King
—————
You know another funny thing is (thinking logically), I will be counting how many Pro-Q 2 instances I have in AUM.
1, Because they are easy to count in there.. and
2, I know how many is it’s limit.
... plus, AUM has a notepad.
“Sometimes you have to just help yourself”
King
Thanks for the remarks. I already did check the AUM native parametric EQ node this morning, just to be complete with the buildin EQs
I‘ll add the result (36-43%) to the main posting.
To check how Aria Pro behaves on too big numbers of complex AUs, i tried to overload it by Turnado AU... Didn‘t happen, Auria happily plays and reloads 50 Turnado instances
Turnado doesn't oversample...
(but results may vary with more and different processing parameters)
Thanks for carrying out such an extensive test, it's very enlightening. I've been saying that the Auria native versions of the plugins would run a lot more efficiently, and your test seems to show that pretty conclusively - 13 AU Pro Qs in AUM vs 100 native Pro Qs in Auria is a massive difference. And that is considering AUM presumably has a lighter footprint than Auria to start with.
The main issue (as many have already said) is the limit Apple places on memory. It doesn't really make sense, especially compared to the native Auria plugins which are only limited by the device, and you could run comparable numbers of instances of them 6 years ago on an iPad 2! The way Apple have designed this you are limited whatever device you are using, so you don't get the full benefit of using a newer device with more memory. Crazy.
@_ki thanks for doing this. It’s really useful for developers to see this kind of information. Even if our own apps aren’t at the top of the list, it lets us see where we can work on improving.
“Last, but not least!”
King
@Blue_Mangoo I am currently retesting the new, updated version of your EQ under all three hosts, but i am not yet finished.
Under Cubasis i get some kind of flickering when i have about 12 instances. Sometimes it looks as if the eq curve is flickering between instances, on other times the display jumps left to right.
Thanks for doing this and sharing the results. Interesting set of outcomes, for sure. The most standout to me is the number of ProQ2s in Auria vs in (generally wonderfully efficient) AUM.
Think it's fair to assume that the actual equalization parts of the code are the same in Auria as they are in the AU. Does AU really add that much overhead? Crappy apple docs for devs? Everyone catching up? Or, in other words: will it be different in 12 months as AU matures or will faux "native" like Auria always have a 4:1 advantage?
@syrupcore The problem is not the performance of AUs, it is the memory limit that IOS enforces for AUs. If Apple removes this limit, one can about run the same number of instances. The native variant of a plugin will be more CPU efficient, but from the values i messured, we can‘t compute this AU CPU overhead.
The next Auria Pro update will support ProQ AU (as i have read). When the update is available i can setup compareable projects and measure the AU CPU overhead.
It seems that you have to wait a little longer for new test results - the general heat outside (resulting in 28 degree inside my room) seems to influence the iPad performance
I no longer get 2-4 % CPU on the pure ‚no eq’ project in Auria Pro but 12-15% instead... Therefore, i will continue testing when it cools down in evenings and the base project is back to normal cpu usage.
I think you may have hit upon a number of variables which are difficult to take into account and make these experiments more difficult than they first appear. I develop audio apps for iOS and I don't claim to know everything, but I have discovered a number of things along the way:
Despite having discovered all this and attempting to eliminate as many of these variables as possible, I frequently find that successive test runs can result in wildly different performance results, sometimes up to a factor of x4 (although x2 is more typical).
I think most developers (myself included) calculate CPU usage as the ratio of the time taken to perform the DSP against the total time needed to deliver the next audio buffer. eg. if you have to deliver a buffer to Core Audio within 5ms and you only took 2.5ms to do all the processing, then the DSP CPU load is 50%. Ideally, the app should also ask the OS what speed it's currently running its clock at to give a true 'absolute' CPU load. I don't know of a way to do this - if other developers do, I'm all ears.
So here's the paradox:
What's happening in the 3rd case is that the OS has recognized the extra CPU load and has increased the clock speed to the next step.
A better approach might be as follows:
Good luck!
Yeah....my iPhone shut down because of overheat just yesterday when i was jamming in the garden at 35 degrees.
So mobile music is something for winter here
@ardnut I used the same samplerate and buffer size in all three hosts, i also used air plane mode and the ipad was full charged and still powered by the charger. I repeated each of my tests on different occasions, but i did not always hard-reboot the ipad (i did a soft-reset from time to time)
I also sometimes noticed a decrease in reported cpu if more plugins were used.
Your idea to add as many plugins as possible until hitting the cpu limit indicated by dropouts is good, but in my tests i always have hit the app AU memory limit first.
During a test run, you can also add more plugins than you later can reload.
I added 5 plugins, saved to a new name, loaded a simple empty project, quit the app, restarted the app which loads the empty project, and then try to load the last saved project.
.
@Cib Luckily the ipad did not crash yet.
Current ambient temperature is about 29-35 degree celsius - the ipad heats up very fast when i start music apps or even just safari.
I tried to cool down the iPad using an icepack and the iPad housing really cools down, but i still get a minimum of 8% cpu instead of the constant 4% of two weeks before...
Three days ago i bought geekbench to check the iPad performance, but the computed performance numbers are nearly the same if the iPad is cooled or quite hot. They are even a tiny bit higher than the official numbers found on their site.
Not sure about this geekbenchs. The problem i often have with my mac and iOS devices as well is indeed thermal throttle which seems to get much worse with the i9 in the new macbooks.
Let´s hope they don´t put a much more powerful chip into the new iPads which looks great on paper but will burn your legs at a summers day
I am normally not interested in benchmarks like geekbench, but i wondered if the heat might have damaged a core (or whatever) because i could no longer reach the lower cpu percentage with the base project - and it was only one euro.
@_ki Sounds like you're doing everything right.
I've definitely had situations where I've gone to bed pleased with myself that I've optimized some code to hell only to find the next day that it constantly profiles at half the speed to the point where I'm starting to think I might have been a dream if I didn't have the figures written down in front of me. Like your results, the ratio is almost bang on 50% which leads me to believe it is a 'system thing', although it's a black box and one can only guess what's going inside. Maybe Siri detected my previous night's cursing and has decided to punish me.
The 'load it to it breaks' strategy is a good one and normally works for me but I hadn't considered the AU memory limit.
Do any of the hosts you're using report the buffer size they're actually using, rather than the one you've set it to use? If so, might be worth a double check to see that these figures match as apps don't always get their preferred buffer size (although that usually only happens if a previously running audio app is 'in charge' and it sounds like your test procedure makes that unlikely).
Beyond that, I'm out of further suggestions sadly!
The last days are colder now, so some days ago i could redo the benchmarks using the updated Auria Pro V2.19 (this time also with a comparison of FabFilter native vs FabFilter AU) and also add some more tests with updated BlueMangoo EQ.V1.05.
.
Then today i received a fresh FabFilter ProQ2 Beta via Testflight - i can confirm they really did a great job with the update, even better than i suspected possible for an AU version
.
Since i can no longer edit my main posting at the top, i need to repost an updated full version below.