All Things PRO AUDIO

[zipb]

I see that you're on Z170 still. What is macOS version are you running?

No, I'm reporting about a genuine new 2019 iMac i9 8-core. See earlier posts. Mojave 10.14.5.

 

[luckyal]

No, I'm reporting about a genuine new 2019 iMac i9 8-core. See earlier posts. Mojave 10.14.5.

My bad, you had first part of that post in italics so i thought you were quoting someone.

 

[zipb]

I just tested on my Z170x with Metric Halo ULN-8 via USB-c and Ethernet, 44.1 kHz, 32 samples buffer.
MacOS 10.14.5: 6 tracks.
MacOS 10.13.1: 8 tracks.
Rather low score, especially on Mojave.

BTW, I don't know if the resulting audio is glitching with all these tests. I just run in a loop and add tracks until audio stops and I get an overload message.

 

[luckyal]

I can run 16 tracks at 32 buffer at 96k no problem. The biggest issue appears to be the first thread load when working on real projects. If you compare that to the hundreds of tracks that Christian is running in that video I linked to first post, you have to wonder why. There has to be some or several processes that the macOS grabs and doesn't terminate on a hack.

 

[zipb]

I can run tons of tracks too if I use audio or EXS and not too many heavy plug ins, let's concentrate on the demo project from the KGP thread and one samplerate. Otherwise we will be comparing apples and oranges again.
The heavy load on one core used to be caused by all the real time stuff, rec enabled tracks, busses etc. Have they changed that at some point?

 

[zipb]

@luckyal, you have comparable Z390/i9 systems. Can you both test the KGP Logic project with the same buffer & sample rate and see how many tracks you can play without the overload message popping up? Should be about the same.

 

[luckyal]

@luckyal, you have comparable Z390/i9 systems. Can you both test the KGP Logic project with the same buffer & samplerate and see how many tracks you can play without the overload message popping up? Should be about the same.

I can run 16 tracks. However, I don't think that the test is completely valid as all it focuses on is track playback. It goes without saying that the more cores you have the higher the track count will be. I'm less concerned with track count as I am eliminating individual core spikes/load. In my case the first thread of the first core is exhibiting a significantly higher load than the rest of the cores. In fact if you take a closer look, my first core is going crazy while the 3-4 threads right next to it are doing nothing. I get that a lot of this has to do with how efficient the plug-in code is and that's fine. Those issues I can deal with, I can't figure out whether multi-core plug-ins whose companies have rock solid reputation are mis-utilizing the CPU resources or where my hack isn't running as efficiently as I expect it to, especially when you compare it to the video I include.

 

[toleda]

where my hack isn't running as efficiently as I expect it to

Suggestion, install Intel® Power Gadget
Reply with a screen shot showing CPU/idle and running CPU/audio app(s).

 

[zipb]

I've seen the lopsided core load since day 1 of the multicore CPU's. Thread distribution has improved a lot, but I can still get the overload message/crackles by playing chords on just 1 rec enabled mega-heavy VI and a small buffer.
Core load is not entirely repeatable either, enabling rec, inserting another plug in, they all change the distribution.

Mac/PC/Hack. They all have this. The last time I compared(with Cubase) a properly configured Windows 10/PC was best.

 

[zipb]

A Z390/i9 upgrade looks worthwhile, BTW. No way I can afford an i9 iMac.

On the other hand, I can do what I need to do with my current build.