Understanding the CPU Meter In Logic

Hi I'm new to the forum and Logic, so any help would be greatly appreciated

 

I'm trying to problem solve a few issues on my system, we have both Logic and Pro Tools Installed and Logic seems to be less stable than PT, we are getting disk to slow errors if recording to the SSD drive and also System midi and audio sync errors, randomly and not all the time.

 

Spec is Mac Mini, i7 2.6, with 16GB RAM, 250GB SSD System Drive, 4TB Thunderbolt RAID drive for Projects. TASCAM DM4800 Mixer/interface

 

So I'm doing some testing of various SR and buffer sizes with multitrack tracking session, up to 32 simultaneous inputs. The attached picture shows the CPU meter, the cores look like they doing very little, but what does the bar on the right-hand side of the CPU meter indicate? Is this some sort of Peak meter?

 

Any help how explaining what I seeing would be great

 

Thanks

 

The audio section represents the 8 cores on your computer, so that means that only one core is working really hard. Something isn't working as it should. Maybe someone else on the forum can explain it better and come up with solutions for it. Maybe that's why you're having problems with Logic

Technically the meter is not actually cores, its "threads". At any one time your system can have many more than 8 threads happening and generally OSX decides which core to put it on. LogicPro has a multi-threading setting which you an adjust from 1 to double your core count, or auto. So that determines how many threads LogicPro will spawn to do whatever it does with your dozens or hundreds of tracks..or few.

 

And yes that is one thread being used by the live record enabled track, by design LogicPro assigns the live record enabled track to its own "thread". If you select a dummy non-instrument track with no plugins on it prior to hitting play, then LPX won't be in live mode and you won't see that one thread off to the right dedicated for a live channel.

Technically the meter is not actually cores, its "threads". At any one time your system can have many more than 8 threads happening and generally OSX decides which core to put it on. LogicPro has a multi-threading setting which you an adjust from 1 to double your core count, or auto. So that determines how many threads LogicPro will spawn to do whatever it does with your dozens or hundreds of tracks..or few.

 

And yes that is one thread being used by the live record enabled track, by design LogicPro assigns the live record enabled track to its own "thread". If you select a dummy non-instrument track with no plugins on it prior to hitting play, then LPX won't be in live mode and you won't see that one thread off to the right dedicated for a live channel.

 

From what I read I always assumed it was the number of cores... always learning

In my case I have 2 and 4 threads. What's the advantage of setting it to Automatic, 2 or 4? The default thought would be: the more threads, the less heavy on each, but since there are options, one can assume that it depends on certain situations...

Can you clarify?

I’ve never set it to anything other then auto myself so I don’t know. It might be, for example, that if you were using vepro where most of the dsp is happening there, you might constrain logicpro to two threads to keep it out of the way of vepro. With low number of cores I don’t think it makes that much difference just use auto

A little more theoretical about threads and cores, now that I'm at my computer. Your computer has a CPU with cores, and each core can handle one main thread at a time. Sometimes if they have hyper-threading enabled, they can handle a second thread at the same time, which basically means the CPU can detect when the main thread is idle for some reason, the secondary hyper-thread can do some work. Its not truly two threads per core in parallel, they are sharing a core so to speak. So 2 core machine, machines at any given instance only two threads can actually be processing anything.

 

Now that truth is while monitoring your overall system through various means you will see the system reporting numerous threads, even though you have only 2 cores. Not only 4 hyper-threading threads, but other threads too. How is that possible with only 2 cores? The operating system mainly gets to decide which thread is using the core at any given moment. A thread typically does not take over a core and own it. Rather threads are switched in and out of context on each core, so that a 2 core machine can have numerous threads taking turns to use core time. In fact, unless your cores read 100% on your system meter, they are sitting there doing nothing at least part of the the time, waiting for some threads to come use them.

 

So why bother multi-threading everything if you only have 2 cores anyway? Multi-threading is a deep topic and there are pros and cons. It does not always make sense to fork a buzzillion threads actually. Multi-threading requires overhead. You have multiple threads all sharing the same resources and they have to be switched in and out of context, which is overhead. Its burning your CPU a bit just to do that. Also if you have multiple threads it should only be used when there are parallel jobs that can be done in parallel without depending on each other for anything. If one thread needs the data from another...then no bueno. In audio we also tend to see that audio processing will be put on its own thread in order to give it a high priority, while GUI related stuff will be handled on a separate low priority thread. That way there can be lags and hiccups with the GUI even while the audio keeps crunching along without being burdened by GUI activity. Etc, etc.. there are many ways to think about and there are good times to use multi threading but also times it should be avoided, particularly if you only have two actual cores to run them on, because in the end, your operating system is sharing time on those cores, not only with the threads of your program, but threads created from other programs too.

 

Also, inside plugins, they are able to fork their own threads also, and its not clear to me that the LogicPro thread meter will even display those threads. Near as I can tell, the LogicPro cpu meter just shows the threads that LogicPro itself has spawned in order to handle your tracks.

 

We know LogicPro says they use one thread per track, ok, but in actuality, if you have 100 tracks it will not be spawning 100 threads. the meter only shows a thread count as being up to 2 times the core count, with hyper threading enabled on your system. So how does logicPro manage 100 tracks then? It has to queue up work units from each track...and multiple tracks are sharing one thread then of course. It only means that the work of one track will not be spread to multiple threads ever, because that track has data dependency...so it can't really be parallelized across multiple threads anyway. So you won't see one track on multiple threads, but you will see multiple tracks on one thread. If that makes sense.

 

I would just leave that setting on auto frankly. LogicPro knows what it is doing inside in terms of thread allocation and balancing, just let it do its thing. But in rare situations it might make sense to set it lower. Like I said, if you have VePro and most of your DSP is happening in VePro and Logic is sitting there hardly using any CPU at all, you might want to constrain VePro to less threads so that it will queue up the work units I mentioned above onto 2 threads, and allow VePro more breathing room to schedule its own work units onto more threads and get higher cpu core utilization that way. But generally I think most people are probably going to get into the weeds with that and should just leave it set to auto.

 

The main thing Logic Users need to know is, Live tracks get their own thread and a smaller buffer and can easily get drop outs if not careful. non live tracks internally get a larger buffer and LPX does whatever mojo it can to use threads and cores as is possible through the operating system.

To add to this, if you do a lot of summing and bussing with fx processing on each bus, that generally decreases your core's ability to call on hyper threading technology, as things need to be processed in serial. Hyper threading requires some different processes (ie tracks) to have independence from each other.

multi-threading in general requires that, not just "hyper" threading. To be clear.

 

Hyper-threading is just a slight optimization that Intel tried to add to their CPU's to slightly improve core utilization. it presents itself to the OS as virtual cores...but its still basically the same number of cores, just a slightly more efficient way of shoveling data from multiple threads into them, and kind of creates the impression like you have more threads happening at once, but you really don't.

Thanks so much for the in depth reply’s

It’s a lot to take in and understand but I think I get it

One thing, when I took that picture I was recording 32 tracks, so is it correct to see just one cpu thread running? Is it “clipping”? It didn’t crash but should I be happy with this performance?

 

Thanks again

If you you have 32 armed tracks being recorded then apparently Logic Pro decides to put them all on one thread. I don’t know if that is normal or desirable.

The thread meter has nothing to do with clipping. If you don’t hear any drop outs and Logic doesn’t report any then you’re probably ok

Sorry my bad terminology, I know it’s not clipping the audio I meant is it maxing out the cpu! Any thoughts ?

If you aren’t getting dropouts then don’t Worry about it

 

You can try to change the multi threading preference to playback & live to see if it makes any difference

It’s set on playback and live at the moment. No drop outs but I just want to guard against any issues. I use pro tools most of the time and we are seeing totally different cpu meter usage in that setup so I was wondering what is going on with the logic setup. We are a shared studio space just starting out and some of the guys love logic for writing in and I just want to make sure it’s stable and running correctly