CPU % was much lower with my 6 core. This is just idle. Pro Tools is not even running.
Had a similar CPU spike after upgrading to 3.4. Turning the re-render processing off did the trick for me. Using the Dolby Audio Bridge all re-renders are done offline, so don't see a downside here. Also turned off the headphone rendering as only listen over speakers. LOVE the addition of the LTC plugin + Loudness section. I know I am late to the party, but really digging this upgrade. Thanks all!
Thanks for the feedback! I'll pass along to the team.
Even with Pro Tools blank/idle, and no re-renders (headphone only mode) I am still getting high CPU usage.. not sure why.
The CPU usage percentage measurement is a little misleading compared to the CPU meter in the Renderer. If you're sitting around 15-20% in the Renderer (a little more if doing binaural) then all is fine. The Renderer is never really idle as it is always ready to process incoming signals - think of it as a tape machine, but one that you don't have to wait till the reels spin up to speed before you can monitor off tape. Therefore, if left in "idle" that value will continue to increase.
Good info on the limiter. Understood!
How does Dolby suggest I handle True Peaks specs when mixing stereo downmixes of multiple beds and objects? Limiters on beds and objects? What about in the "mix" that is happening in the RMU/DAPS? I used to use limiters on the Speaker Output returns back into PT, but if I am using re-renders, is there a best practice?
Also, LTC Generator performed much better than MTC via IAC bus regarding latency, not perfect, but within a few samples when I checked re-render exports. Didn't checked ADM BWF, but assume it would be the same sync-wise.
In your session you can put limiters on bed/object tracks but hitting dBTP specs on 5.1 or Stereo re-renders is hit or miss. DBTP being an interpolated value and rendering involving some summing in the process. For delivery of channel-based assets, post re-render dynamics processing in PT is best practice.
Hitting dBTP specs on a 5.1 re-render as part of Atmos delivery spec is likewise hit or miss. We encourage Atmos delivery specs to call for target dBTP limits of -2 on a 5.1 re-render in specs and not to reject content unless there are actual overs. The soft clip limiter in Dolby Digital Plus JOC encoder (mimiced in the renderer) will address occasional peaks in excess of -2dBTP.
I don't know what the issue is offhand. Just to confirm this is a 2013 MacPro with an upgrade to Xeon
E5-2697v2 processor correct? What Ram upgrades were part of this?
I will ask if any of the team has any experience with this. I know this isn't a configuration we have tested.
I'm not seeing quite the same thing on my 16-core Mac Pro 7,1. But I still see 13% on the CPU meter when PT isn't running. That's when source is Input. When I change source over to Master, it does a few periodic jumps to 22%. Either of those numbers does sound high when there's nothing at all passing through the renderer.
FWIW, it appears that the renderer is only using the first 8 physical cores of my machine. That means that a busy PT session can hit overload on those cores where there are still quite a few cycles available on cores 9-16.
With core audio out of the picture (set DAPS to Send/Rtn plug), CPU drops to normal. Seems it is a coreaudio issue..
That makes sense. I had a session that was running fine (almost--but not quite out of CPU) on my 2013 Trashcan. I was running Send/Return on that one. Same session is pretty strained on my 16-core, using the bridge.
Hmm, I am actually unsure now -- with some re-defining what's in /Library/Preferences/Audio, I was able to make CoreAudio chill out, but DAPS is still acting stressed for no reason.