CPU % was much lower with my 6 core. This is just idle. Pro Tools is not even running.
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.
Even with Pro Tools blank/idle, and no re-renders (headphone only mode) I am still getting high CPU usage.. not sure why.
Thanks for the feedback! I'll pass along to the team.
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!
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.
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.
Wow, so many topics covered in one thread! And all interesting to read.
Just a few things to note on the limiter: it's not a conventional limiter in terms of having fixed or adjustable characteristics. It works in stages and is signal dependant. It is not designed to be used as a traditional limiter/compressor but instead merely a safety net to avoid hard clipped signals ever being encoded. If you happen to go out of range the limiter will turn the hard clip into a soft clip. Having this option in the renderer means you are hearing exactly what the encoder will "hear". Much like Spacial Coding emulation, it allows you to hear your mixes as they will perceived further down stream.
Hi Michael, Point taken re 5.0, 7.0, 7.0.2
Hi Jon, The Audio Bridge is a single path. If used as both the input and output from the Renderer it will feedback. That is the way it is designed. If used as the playback engine and I/O an intermediary needs to be used for monitoring as you've devised.
The limiter is a soft clip that prevents clipping and matches the processing that happens on the input to our encoders. That is why it is also shared by the loudness measurement and "loudness" re-render. I don't know that it has specific published knee characteristics but I will enquire.
It is not user adjustable. This has been a frequent request so we are aware of it but it doesn't hurt to add your voice to the clamour:)
I use 5.0, 7.0 and 7.0.2 all the time. I'm doing music and really don't feel a need to use LFE in that application.
Understood about the custom re-renders. Is there something technically limiting about the Dolby Audio Bridge from being 2-way I/O? And speaking of limiting, what's the DAPS limiter set to and can I modify it?
Got it. Yes. You should be able to start with the audio to timecode alignment set to 0 samples if using the LTC Generator and tweak as needed using the same method as above to account for Loopback.
We don't have customizable re-renders. The logic is that we only include re-render width that we can encode to Dolby Digital Plus. I'm curious, however, how many people are using 5.0, 7.0, and 7.0.2 for example.
Oh and on my 6-core, it was taking a CPU hit while doing that print workaound, but it was working more or less.
For some reason, Loopback and the .plist files in my preference>audio folder were freaking out when I installed my 12-core making it impossible.
In the end I'd rather record to DAPS/RMU, convert DMAF to ADM BWAV and re-import and/or deliver custom interleaved re-renders.
Great and the reason I print or bring back to PT is I have to deliver discrete PCM wavs in particular track orders and to monitor loudness. The 9.1.6 re-render will make it so I might not need to do that anymore, but I may still need to output 9.1.4 in which case I was printing speaker outputs. (This is usually done via RMU but on DAPS during work from home). There's no way to "customize" re-renders and make a 9.1.4 is there? I'd prefer to make all my stereo down-mix and splits all at once as well, so if I can customize re-renders, it would really solve all this.
Haven't messed with the LTC Generator yet, I will definitely take a look! Noticed some latency in preliminary tests last night. Would I just need to use the new offsets? Or do you think LTC Generator would solve for this?
Hi Guys, Interesting. I don't know that we could or have any interest in preventing this? I'm sure this does save some time vs offline re-renders and importing into your DAW but is a lot of hoops to jump through and an evident CPU hit? Also I see you are using MTC. This works but shouldn't be used for punch-ins. Any reason you aren't using the LTC Generator plugin that comes with the v3.4 installer?
Re: CPU usage in idle. The Renderer is processing even it if isn't receiving input so 15% while idling is expected.
Good tip re: the Avid helper.