DP variable CPU utilization

[johannes2510]

I’m in testing my new hackintosh i7 8700K High Sierra 10.3.3 DP 9.51.

My test template is an 40+ instances of Kontakt (many with keyswitches) with Berlin woodwinds/brass/percussions, piano C7 Production Voices and LASS for strings (KS+divisi patches).

I have load MIDI files of 4th mouvement of Beethoven’s symphony 7 and first mouvement of piano concerto emperor.

48 khz, 24 bit.

At 256 buffer size no problems at all, all is played without problem and in the busy passages the cpu meter (processing bar) it’s at 40-50%

At 128 buffer size I have 70-100% with some warnings and few audio artefacts.

At 64 buffer size I have 90-100% (the processing meter is almost all time red) with a lot of warnings and a lot of audio artefacts.

Ok, that’s normal I think, but I have see that often the cpu utilization it’s variable with the same buffer in differents reboots of the system and in differents days of test.
For example right now I have played at 128 buffer with no warnings or artefacts (but the cpu meter processing become red in moments).

And, a very surprising thing, yesterday evening after a reboot I can play at 64 buffer with very little cpu utilization, like 45-50% max, no warning at all and no problems with artefacts!

So I go to sleep very happy… this morning the situation has returned like before.

Ok, I am testing overclock too with differents setups in BIOS: 4.7, 4.8 and 4.9 ghz and in general I have some improvements but nothing amazing, so yestrday I think it’s for this the 64 buffer miracle. But no, because yesterday I have try the cpu at stock clock too and the miracle of 64 buffer was still there…

This morning the “magic moment” was passed and all it’s return to “normality”.
It’s all day that I search to reproduce the miracle with no luck.

I have think that was because in a moment yesterday I have open all the strings instances and set to work in realtime (no pre-gen mode), but with no gain in performance so I set up again in pre-gen mode.
So today I have do the same but nothing relevant has change.

1) I’ts normal that the cpu utilization change a little at the same buffer in different moments,system reboots and days?

2) What happen yesterday with the “64 buffer miracle”?

[mikehalloran]

Are you connected to the internet while you are testing? Do you have a tool that can test the amount of available RAM at any point in time?

[toodamnhip]

This reminds me of a variety of technical issues over the years. I think we have all experienced a form of this in one way or another. Many times, when having a technical problem, it seems to “solve” SLOWLY. Meaning, not 1 “fix” handles the problem, but the “problem” slowly subsides over a period of a day or two, after a variety of “fixes". I do believe there are variables to any computer that are hard to trace down for sure. This is why there are beta testers. Even exact duplicate computer systems can act different at different times and with different users. Meta physical? One would think not, but it’s possible. I have heard stories of certain producers/ engineers that walk into a room and systems start crashing. Sounds incredible. But there are far too many stories like these to just ignore. People here at the forum have accused me of having a screwed up system worshippers than other members. Is is all just proper formatting of one’s computer? Well, real world series tell us otherwise.

[johannes2510]

Are you connected to the internet while you are testing?

I have try with and without internet connection No relevable differences. ("relevable" exist in english?)

Do you have a tool that can test the amount of available RAM at any point in time?

Yes, "Activity Monitor" in Mac OS and the ram is fine I have in this project 15 gb free.

EDIT:

Today with CPU overclocked at 4.7 ghz on all cores and at 128 buffer no warnings. Not bad

[johannes2510]

I have try deleting all the v-racks not in use (or disable it in v-rack window) so remain 18 that play and with buffer at 64 very little warnings and at buffer 128 only 50-60% of cpu in use, so it runs better.

It appears clear that v-racks give work to the cpu even if they are not in use and even if they are sampled purged.

Maybe MOTU can in the future optimize this?

[johannes2510]

Today I have try more tests and the wired thing happen again and this time on "same boot".

First I try my Beethoven test at CPU stock (3.7 / turbo 4.3) and at 64 buffer size was very bad, lot of warnings and audio artefacts.
I reboot with cpu overclocked at 4.7 ghz and give a try to at 64 buffer size and still very bad.
So I try with Logic Pro X and was a little better, but some artefacts was there.
So I try again with Digital Performer without reboot and suddenly all runs very well, no warnings at all and no artefacts and the CPU meter was very low

So I try with 32 buffer size and still play very well and also with 16 buffer size was very good!!!
All is playing perfect, like I have another machine

I have made a screenshot that show that DP was playing at 16 buffer size and the CPU meter show that the CPU have no problems at all (with also Intel Power Gadget that I use for monitor CPU speed and temperatures):



How this can be happen?

EDIT:

I have rebooted the machine at CPU stock speed again and… play quite well at buffer 16, no warnings only a few artefacts.
At buffer 32 all is very good and the CPU meter is similar with the screenshot.

So it appears that this very strange behavior of very different cpu performance (128/64 to 16 buffer size it’s VERY different) it’s not related to CPU speed but is done by something else that I really cannot understand what can be.

Any ideas?
I will like, obviously understand the thing for maybe optimize and have control of better performances that now is sure this machine can do.

EDIT 2:

When the 32 buffer was playing well, I have made some little changes in MIDI tracks like record keyswitches and suddenly the situation as returned than usual, even if I set at 64 buffer size. That's real mystery for me...

[HCMarkus]

I'd suggest it may well be DP's pre-rendering audio engine at work.

Whenever you make a change, DP has to recalculate what the end audio result is, and with as many tracks as your sequence has, this could take awhile. Do things improve after a while when the sequence is played without changes?

[johannes2510]

I'd suggest it may well be DP's pre-rendering audio engine at work.

Whenever you make a change, DP has to recalculate what the end audio result is, and with as many tracks as your sequence has, this could take awhile.

Have you an idea of what can be this time that DP need for recalculate?

Do things improve after a while when the sequence is played without changes?

No. I have think too that is because DP need time for "learn" what must play, but if a session start with poor performance still poor and if start with good performance still good.

The only change that I have see in a session was just before with the change of some data in MIDI tracks that has lower the performance.

[johannes2510]

Today is "the 64 buffer day"

All day doing tests and every time at 64 works fine. Is not like the "miracle day" when also at 16 was good, today no 16, but 64 is ok.

Still investigating...

[johannes2510]

I think that I have found the explanation.
Honestly I don't remember if when I have take the screenshot with 16 buffer was as follow but it is possible.

Testing different settings yesterday I have disable the MIDI track record function (MIDI track with output to a v-rack) and the cpu processor bar has suddenly going down a lot.
So I have try "on-off" several times and always the change happen. Same thing at no matter what buffer size.
At 16 without any MIDI track record enabled I have cpu meter at 40-70%.

So I have done more test.
Creating a new MIDI track with no output to a v-rack and enabling the record change nothing, with or without MIDI items in.
Creating a new MIDI track with output to a v-rack but without MIDI data the difference rec enabled-disabled is there.
Creating an instrument track+MIDI track (no v-rack) give the same result.

So it appears that is the "default comunication" between MIDI track and v-rack/instrument track that rise the cpu work.

Honestly I found this difference very big for "only" record enabling a MIDI track and I'm wondering if is due by a non optimization of DP in some way the cpu work is handle.

I have try with the same template in Logic and I can't see that difference enabling or not enabling an instrument track. The cpu meter seems the same.

There is some preference that can change this behavior? I have change some "event chasing" preferences but no luck.

[HCMarkus]

I think this is the explanation: When a VI is record-enabled, it no longer functions in Pre-Gen mode; hence the CPU utilization.

[johannes2510]

I think this is the explanation: When a VI is record-enabled, it no longer functions in Pre-Gen mode; hence the CPU utilization.

Ah!
Because is impossible for the program to "read the future" that is not write in a MIDI track.
The program must follow in real time what you write on a track.