AUM update Submitted

[Deleted User]

@wim said:

@Carnbot said:
Has anyone else noticed high cpu and lots of spikes since this update? Certain apps which I used all the time seem to be doing this and don't remember the issue before the update. Sometimes I see it jumping into the 1000s and then back down again. I remember there was a similar issue just after it it was released so wondering whether that bug has crept back in...

So I'll often have some apps loaded and the DSP will be rising and lowering all the time when nothing is happening in the apps etc.

@j_liljedahl

Could be this:

What's New in Version 1.2 said:
* DSP meter: display peak instead of average.
NOTE: This will show higher (but more accurate) readings than before for the same DSP usage!

Maybe it's not an actual consumption issue, just better reporting of what was happening before.

I just booted up a load of apps via AUM, including the normally troublesome ElasticDrums, and managed a full recording without any hiccups. Usage did look a bit high on the display, and graphics performance was a bit juddery when switching apps, but the recording came out ok.

Audiojunkie

@wim said:

@Carnbot said:
Has anyone else noticed high cpu and lots of spikes since this update? Certain apps which I used all the time seem to be doing this and don't remember the issue before the update. Sometimes I see it jumping into the 1000s and then back down again. I remember there was a similar issue just after it it was released so wondering whether that bug has crept back in...

So I'll often have some apps loaded and the DSP will be rising and lowering all the time when nothing is happening in the apps etc.

@j_liljedahl

Could be this:

What's New in Version 1.2 said:
* DSP meter: display peak instead of average.
NOTE: This will show higher (but more accurate) readings than before for the same DSP usage!

Maybe it's not an actual consumption issue, just better reporting of what was happening before.

This ^^ Nothing has changed but the way things are reported--better accuracy.

Carnbot

@Audiojunkie said:

@wim said:

@Carnbot said:
Has anyone else noticed high cpu and lots of spikes since this update? Certain apps which I used all the time seem to be doing this and don't remember the issue before the update. Sometimes I see it jumping into the 1000s and then back down again. I remember there was a similar issue just after it it was released so wondering whether that bug has crept back in...

So I'll often have some apps loaded and the DSP will be rising and lowering all the time when nothing is happening in the apps etc.

@j_liljedahl

Could be this:

What's New in Version 1.2 said:
* DSP meter: display peak instead of average.
NOTE: This will show higher (but more accurate) readings than before for the same DSP usage!

Maybe it's not an actual consumption issue, just better reporting of what was happening before.

This ^^ Nothing has changed but the way things are reported--better accuracy.

Ok that's probably it, but should it ever go into the 1000s?

My default template mixbus of just AUs Virsyn reverb, Amazing Noises reverb and limiter and Tap delay seems a lot higher than before even on average and if i add TC-11 to that not long before I get crackles. Will have to play around a bit more with it.

Not sure if I preferred the ignorant bliss of average DSP

wim

The 1000's??
How can % go over 100? Are we all talking about the same thing here?

Carnbot

Audiojunkie

Interesting! A bug possibly?

wim

Ya think?

Either that or @Carnbot has his amp turned up to 11,000 again.

Carnbot

It looks as though it's Tap delay which is causing a lot of spikeyness in AUM for me when idle. I was hoping @Virsyn would update this as an AUv3 to keep it up to date as It's my favourite delay but it's getting in real need of an update....

I think this new DSP accuracy is a good thing for narrowing down rogue apps it seems

j_liljedahl

@theartwebreathe said:
I'm very curious if anyone else is experiencing the same thing as @Carnbot.

I use AUM live weekly and haven't updated to the new version yet - i might hold off if this is an issue

I changed the DSP metering to show peak levels instead of average, which of course means it displays larger but more meaningful values. I haven't changed any code in the DSP signal path, and no additional processing. The update is built with a newer iOS SDK, so you never know what changed under the hood. However I'd be very surprised if it actually uses more CPU, but let me know if you find any actual change in performance and not only the visually displayed DSP% number.

j_liljedahl

@Carnbot said:

This is only possible if a hosted plugin/app blocks the audio thread. Most probably one or more of the plugins you use are doing naughty forbidden things in the audio code, which destroys the party for everyone.

brambos

@j_liljedahl said:

This is only possible if a hosted plugin/app blocks the audio thread. Most probably one or more of the plugins you use are doing naughty forbidden things in the audio code, which destroys the party for everyone.

People using Objective-C or Swift calls in their realtime thread should be hung, quartered and drawn

Carnbot

@j_liljedahl said:

@Carnbot said:> >

This is only possible if a hosted plugin/app blocks the audio thread. Most probably one or more of the plugins you use are doing naughty forbidden things in the audio code, which destroys the party for everyone.

I think the new readings are good for tracking down naughty apps

j_liljedahl

@brambos said:

@j_liljedahl said:

This is only possible if a hosted plugin/app blocks the audio thread. Most probably one or more of the plugins you use are doing naughty forbidden things in the audio code, which destroys the party for everyone.

People using Objective-C or Swift calls in their realtime thread should be hung, quartered and drawn

Exactly!
PS. Any potential blocking C calls are also forbidden.