Is AUM actually "multi-core"?

cdnalsi

So I'm new to AUM and have just found the DSP menu, and inside it, under Node Statistics, on the DSP Load tab, when I scroll all the way down I find the DSP CORE DISTRIBUTION chart.

In one of my mildly demanding projects, AUM reports 59% DSP usage between 4 cores of my M4 iPad Pro (which has 4 performance cores / 6 efficiency cores)

Now am I reading this wrong?

Just for contrast, when I only have one channel playing a loop, this is what I get:

As you can see with only 1% of DSP usage, only my "core no. 7" is actually used.

Wouldn't it then be the case that if AUM was indeed "single-core" it would only use one of these cores, and not 4 like in the first screenshot?

Or am I reading this completely wrong?

wim

All apps are multi-core in the sense that the operating system allocates tasks to available cores based on trying to balance performance, heat and battery use.

AUM isn't multi-core in the sense that you're asking about. That is easier to think of as "Multi-threaded audio processing". AUM doesn't do that.

Prior to multi-threaded audio being introduced to iOS/iPadOS, audio could only be processed on a single thread. A thread is a stream of processing and can only execute on one processor at a time. Multi-threaded audio provided the means to have more than one audio processing thread at a time, so the load can be split up to run on more than one processor at a time.

AUM hasn't implemented multi-thread/multi-core processing. It's audio DSP only happens on one core at a time. Other tasks such as graphics can execute in parallel, but audio is only on that single track.

What AUM is showing you is how often the operating system has decided to execute the single audio thread on each of the processors. It's not indicating any parallel processing. This is the meaning of the note at the bottom of the screen shot. "How often the DSP thread has executed on each CPU core recently."

(The programmer has no control over which cores threads execute on other than being able to request high performance cores. It's all up to the operating system to decide.)

I hope that makes sense.

cdnalsi

Kinda makes sense. I'm not understanding the following:

@wim said:
AUM hasn't implemented multi-thread/multi-core processing. It's audio DSP only happens on one core at a time. Other tasks such as graphics can execute in parallel, but audio is only on that single track.

"Audio DSP only happens on once core at a time" - But then:

@wim said:
What AUM is showing you is how often the operating system has decided to execute the single audio thread on each of the processors. It's not indicating any parallel processing. This is the meaning of the note at the bottom of the screen shot. "How often the DSP thread has executed on each CPU core recently."

So really then it's a single-thread from AUM spread out to multiple cores by the iPadOS?

wim

@cdnalsi said:
Kinda makes sense. I'm not understanding the following:

@wim said:
AUM hasn't implemented multi-thread/multi-core processing. It's audio DSP only happens on one core at a time. Other tasks such as graphics can execute in parallel, but audio is only on that single track.

"Audio DSP only happens on once core at a time" - But then:

Sorry, that was a typo. "once" should be "one".

Think of it like a train of box cars. The engine is the core. With single-threaded audio, the operating system can hook the cars up to a more powerful engine for heavier loads, or a weaker one when the load is light, but it can only ever use one engine at a time.

With multi-threaded audio, the operating system can split the train up and allocate more than one engine as it sees fit. The programmer has to decide which parts of the train can be split up though.

Additionally, for audio processing, the programmer has to re-assemble the "cars" in order before entering the station. But that's another subject.

@wim said:
What AUM is showing you is how often the operating system has decided to execute the single audio thread on each of the processors. It's not indicating any parallel processing. This is the meaning of the note at the bottom of the screen shot. "How often the DSP thread has executed on each CPU core recently."

So really then it's a single-thread from AUM spread out to multiple cores by the iPadOS?

Not spread out. Moved from one to another. The audio thread might execute on a slower core under low load. If that core starts to get overloaded, the operating system might move it to a higher performance core for a time. But the thread only ever executes on one core at a time. AUM is showing you how often each core was used.

cdnalsi

Thank you for your explanation.

So it's not like all the other cores are idling by and not getting used, it's just that they're not being used at the same time?

wim

@cdnalsi said:
Thank you for your explanation.

So it's not like all the other cores are idling by and not getting used, it's just that they're not being used at the same time?

They are being used at the same time. Just not for the audio processing thread. They're free to do other things, such as handling graphics, screen touches, running background tasks such as checking your email and texts, etc.

uncledave

Just to add, the OS will move a thread to different cores for reasons of its own. Maybe temperature rise across the chip, just spreading the load, whatever. And that AUM graphic does not show which cores other processes on the iPad are using, just those which the DSP thread has visited recently.

espiegel123

see Jonatan's words on this topic

https://forum.loopypro.com/discussion/comment/1369610/#Comment_1369610

wim

And to add even more confusion... 😎

When you see DSP % usage, it's a reflection of the percentage of the allocated, not total available CPU. You could be running a low load and see a certain percentage, then you can add a heavy plugin, and actually see the percentage go down because now the thread is running on a faster core.

pedro

Correct me if I’m wrong but my understanding is that a single audio processing chain will run on one core alone, for performance/latency issues. No app does split audio tasks on a single audio thread across cores.
Like @wim said they can’t be performing audio tasks on several cores unless they are separate “needs” of CPU, and that would be by app design, but eventually would boil down to the OS deciding how best to manage the load.
So it is ultimately the OS responsibility, but still one thread of audio per core, no multi of cores on a single thread (like one core for this AU, and another to another, etc on the same audio chain)
So your investigation looks normal…

wim

@pedro said:
Like @wim said they can’t be performing audio tasks on several cores unless they are separate “needs” of CPU, and that would be by app design, but eventually would boil down to the OS deciding how best to manage the load.

Just to be clear, the OS can move an audio thread to any processor it wants to at any time. But only one at a time. AUM only ever has one audio thread, but it hops around between processors. That's what the table is showing.

The so-called Multi-Core DAWs such as Cubasis can split audio processing tasks up into multiple threads. So in that case audio processing can actually be done on more than one core at a time.

The only hitch is no matter how much that speeds up the DSP, before output the audio still has to be assembled in order, so there is a certain amount of waiting around for all tasks to finish, but overall it's a gain in how many plugins can be supported, though apparently sometimes at the cost of a little bit more latency.

** (At least in the case of Cubasis. Some say there is no added latency in other apps such as miRack. I couldn't say myself.)

pedro

Thanks @wim that seems to confirm my perception, which I probably learned from you before

wim

then we're both full of B.S. 😂

pedro

It is what it is. Biggest challenge (not only iOs but any other OS) is getting all audio threads to come together at the end, right now… over me

espiegel123

@pedro said:
It is what it is. Biggest challenge (not only iOs but any other OS) is getting all audio threads to come together at the end, right now… over me

A few posts up I posted a link to AUM’s creator explaining audio threading

yellow_eyez

@wim said:
then we're both full of B.S. 😂

Someone definitely is, that’s for sure

Bwahahahahahhahaahah

Fascinating read @wim, and good catch OP; I also wondered the same thing but I think I asked Wim the same question, and he professed, I mean , he taught me my basic understanding of how the multi core differs from multi threading, essentially the system is multi core but the software must be multi threaded processing enabled to efficiently process things. Or something like that

Thanks for sharing
(And thanks for the details Wim , you’re very good at explanations man)

Edward_Alexander

@yellow_eyez said:

(And thanks for the details @Wim , you’re very good at explaining man)

Now if we could just get him to explain women 🤓

@pedro I see what you did there; monkey finger..

yellow_eyez

lol!

pedro

@Edward_Alexander I bet you’re smooth with the ladies more than what you’re disclosing…
C’mon, give us the down low

Edward_Alexander

@pedro said:
@Edward_Alexander I bet you’re smooth with the ladies more than what you’re disclosing…
C’mon, give us the down low

Oh I just whip out my 12.9 inch 🤭