Massive CPU problems with crackling on iPad Pro 9.7 with iOS 11.3.1 (Edit: Fixed!)

I see massive problems with CPU usage on my iPad Pro 9.7 with iOS 11.3.1

I tested 2 Audulus files that showed this effect and will try up upload screenshots

An upload button for attachments would be much more conventient, compared to being forced to first open the Photos app in the sidebar

And i just cannot use an Emoji, it seems :wink:
Not with the popup, that is.

Anyway, did other people also experience such CPU problems?

I have the same effect with this patch: https://aws1.discourse-cdn.com/standard10/uploads/audulus1/original/1X/b07d0dd839b340f87108322b2da11a728a5ae5be.audulus

I already hard-rebooted the iPad to make sure that no background process was the cause.
Also I have no such problems with other Apps.

I see a dangling question with maybe the same issue on an older Audiobus thread

Interesting, going to read this.

I started Audulus in AUM with buffer size 1024 and the above FM patch stopped crackling, while still having quite some CPU usage.

But the big synthesizer patch from the old forum still crackles heavily.

I read https://forum.audiob.us/discussion/15621/audulus-3-update

And need to say:

When I put Audulus to the background, or just make a screenshot and edit this screenshot (so that Audulus) is not visible at this moment, the crackling stops and the CPU usage goes down!

The problems with the audio crackling have to do with the heavy graphics demands of the (2nd gen.) iPad Pro’s. One way around this is to open Audulus in split screen for complicated patches that have high CPU demands. The smaller the Audulus window, the smaller the graphics demands on the CPU and the larger the patch that can be run without crackling. (The size of the screen also means that one can run less on a 12.9" iPad Pro than a 10.5" for example. See this thread on the old forum.)

2 Likes

Thanks, I read this.

Did not understand the statements about 48 kHz, as far as I can tell, mine is running at 44.1 kHz

Anyway, could this problem not be solved by disabling all animations in Audulus? A static graphical display that can be used would sure be better than Audulus requiring to run in the background or in Split View (going to test this).

It’s strange, that newer, bigger and faster iPad have such problems, while older iPads don’t.

Does that mean in general, that Audulus cannot be used normally on any iPad Pro? Or is there an Pro that does not have such problems?

massively frustrated

And thanks for the information!

Yes, split view helps!

And it helps more, the less screensize Audulus has!

1 Like

I tried the big Nebuchatnezzar patch in the smallest split screen - but no chance, it crackles like he’ll.

To be honest, that makes Audulus pretty unusable on all affected devices.

Time to get an older iPad Mini Retina or 4 with IOS 10, yes?

1 Like

“It’s strange, that newer, bigger and faster iPad have such problems, while older iPads don’t.”

I am surprised about this. I can understand the idea that an iPad pro itself runs a little slower than it ought to but how can an A9X Dual-core 2260 MHz device be slower than a A8 Dual-core 1500 MHz?

Is this a problem with how the graphics processing in the pro was designed? Is it a problem between the pro and iOS 11? Is this app-wide or something Audulus and other apps are struggling with?

It has to do with the fact that Audulus’ beautiful interface uses a lot of resources to continuously render the graphics. That’s the price to pay for the instantaneous detailed visual feedback that makes Audulus a joy to use.

(One also doesn’t have to think of ‘load bangs’ and the like when creating patches – that means that modules are constantly running as soon as they have an output (light) connected to them. This is also the case with the Moog Model 15 App, for example, but in that case they’ve resorted to the using the Metal graphics framework to somewhat relieve the CPU of the visuals. The Model 15 is a fixed set of modules though – the Audulus context is quite different.)

On the new iPad Pro’s the ‘pro motion’ high speed refresh rate has increased the demands placed on the resources available. @Taylor has been working on optimisations to help with these issues.

I was very frustrated by the crackling issues in the beginning, but as time goes by have’t really found it to be an issue. The spilt screen trick helps a lot, and otherwise it’s a good motivation for focussed and efficient patching. @stschoen has made good progress in this regard with a lot of his modules and demos.

Re. the Pro/Mini models – I find myself using the Apple Pencil a lot when patching, and would recommend the iPad Pro (or latest 9.7 model) for that reason alone. The iOS 11 file system is also a huge improvement in conjunction with Audulus 3.5 so I would definitely recommend using a device that supports iOS 11 if possible – especially if your’e doing a lot of patching on it.

I am running an iPad Mini 4 because I wanted a small device. The reason I am surprised is I have created a patch that, for me, runs as 60%. The person above has an iPad pro and was experiencing crackling when running the same patch. That seems like it could be a separate problem, unless in the current situation the statement “an iPad Mini 4 runs Audulus 3 better than an iPad Pro,” is true.

@RudigerMeyer I think I made that mistake again and wrote 10.3.1 while I meant 11.3.1
Sorry, fixed that above.

But I think, that I never had this effect on iOS 10!
Therefor my question about a “new” iPad Mini with iOS 10.

Something worsened and I keep reading about 48 instead of 44.1 kHz and also about something Apple did with the priority of audio and graphic threads.

Maybe it would help if developers could communicate such problems to Apple.

I have the mini 4 running iOS 11 well. Maybe it is an issue b/w the pro and 11.

I think it’s an issue with how the 2nd generation iPad Pros handle graphics due to a combination of their higher refresh rates and larger hi-res screens. Hopefully @taylor will be able to figure out a work around for this.

As an aside, I won’t be upgrading my iPad without testing how its replacement functions with my existing music apps.

This was the first generation of iPads where the performance on the newer iPads for music apps was worse than on the previous ones because Apple didn’t provide enough resources to compensate for the increased resource usage of the larger hi-res screens with a faster refresh rate. I feel bad for Taylor and the users who are having to deal with this shortcoming.

Apple seems to have changed the relative priority of audio processing and graphics in iOS 11.

I’ll be addressing this by further optimizing both the audio engine and the graphics. Unfortunately, I don’t have any quick work-arounds.

I have a first gen 12.9 iPad Pro and Audulus works well. The big Nebuchadnezzar does push it, hitting 75% cpu, but if I two-finger shrink it down some there are no crackles. Curvature works great, and the Scaled FM patch does too, no crackles (tested in AUM).

Linking to this thread for workaround:

1 Like