IRC 5 is unusable in realtime on Mac OS 15.6.1 M4 Max 64GB RAM

I've tried lodging a support request, but never received a case email to my Native ID address to provide the detail, so posting here in the hope of either some coroboration and / or technical support.

Maximiser / IRC 5 is poorly optimised and largely unusable even on the fastest CPU money can buy. I do understand that largest buffer sizes are not necessarily the most optimal on Mx CPUs. 512 seems to be the sweet spot. I also appreciate that IRC may be algorithmic advancements that can leverage higher CPU availability with modern processors, however this is largely unusbale for me, so interested to see what others are seeing and if it can be further optimised.

Tested in Bitwit 5.3.13, and Live 12.2.5 VST3 on real projects, but presented below is a simple test case:

Load Ozone 12 onto the Master with IRC 5 enabled results in extremely high CPU usage. No other devices or plugins other than Ozone 12 on the master and the transport is not even running.

So far, I'm finding it's largely unusable.

Buffer settings and CPU load, with Ableton Live CPU meter:

256 (droputs when transport playing) / 512 / 2048:

20 - 24% CPU on MacBook Pro speakers

20% - 35% CPU on external interface (Can flunctuate significantly)

Bitwig I suspect reports the issue differently, results below at different buffer sizes, no transport playing. Doesn't seem to be any different between the Macbook Pro speakers and the external interface with these results. Load Avg across full window / Deadline = CPU load.

256 - External Interface - 26% (but the DSP meter shows ~100% and dropouts when transport playing)

256 - Macbook Speakers - 26% (but the DSP meter shows ~100% and dropouts when transport playing)

512 - External Interface - 24% (but the DSP meter shows ~50%)

512 - Macbook Speakers - 24% (but the DSP meter shows ~50%)

2048 - External Interface - 22%

2048 - Macbook Speakers - 22%

So, in a real project, with a modest amount of other devices at even 2048 buffer size results in significant audio dropouts.

Is IRC 5 designed for offline bounce only?!

Can / will Izotope do anything to improve the performance?

See attached, pictures below presented in same order as above.

Ozone 12 Balanced Master With IRC 5 and Transient Emphasis.png

Find more posts tagged with

Comments

Kymeia

Interesting article with the developer

https://www.izotope.com/en/learn/inside-ozone-12?srsltid=AfmBOopXERFWVAJtJq8l56X6NJuyrY8C5wLR2ZlHVX0GUYB0NDVSg_ae

Personally I see Ozone as a mastering rather than track mixing tool and largely use it for offline rather than realtime rendering, especially given the huge latency I see little point in realtime - I have Neutron and many other more mix focused tools for that

Vocalpoint

Agreed.

Ozone was never designed to be used in an actual mix. I see many folks trying to wedge it into this scenario and it never ends well.

Sek0ps

thanks @kyand33 for that article, that’s fascinating to read what is going on under the hood with IRC 5, thanks for sharing.

The articles discusses “At some point we considered dropping the Transient Emphasis feature for IRC 5 in order to reduce the CPU load and latency, but after receiving reassuring beta team feedback we decided to keep the option,” which aligns to what I’m seeing (the part about CPU load, not the reassuring feedback!) - when Transient control is enabled CPU consumption skyrockets and even on a completely blank project (not in a mix scenarios) it maxes out the M4 Max CPU at lower buffer sizes, to the point it’s largely unusable.

To me, it doesn’t make much sense to have something that is only possible for offline bounce, as you need to listen to the results and right now that’s almost impossible. But curious to see how others and able to use this in an offline bounced only scenario?

Its 3am for me when the Sep 11th QA is on, so hoping someone else can ask if NI / Izotope can do anything further to optimize this to make this usable? I’m hopeful that further improvements can be made, particularly as CPU performance is so high even when it’s the only plugin on a project and the transport is stopped. Or perhaps there’s a bug on the M4 Max / Mac OS variant that can be addressed? I’d be grateful if this could be asked in the QA and the answer posted here.

Vocalpoint

"But curious to see how others and able to use this in an offline bounced only scenario?"

I use several of the high overhead iZotope IRC algos in RX 11 ADV and my process is always:

Bounce
Listen
Either like or don't like.
If Don't like - bounce again.

There is no concept of listening "thru" some of these - as you have now found out.

Sek0ps

yeah, ok, understand that approach, but when the article linked explains how it they “optimize the design for real time performance” (Alexey Lukin), it’s a shame that doesn’t seem to have been achieved with the initial public release.

Vocalpoint

https://community.native-instruments.com/discussion/comment/240260#Comment_240260

For me - I am not concerned with real time performance. Can't really see how others would be either. If you are using these IRC tools as a pro - offline bounce/render is the way.

Kinda like James Cameron rendering a new Avatar movie - he doesn't watch the screen as it's rendering.

Sek0ps

I expct others are concerned about real time performance as that's how it's marketed.

Sunborn

https://community.native-instruments.com/discussion/comment/240278#Comment_240278

Audio Basics:

Mastering tools are not meant to use in real time performance. Period.

Even if you have the necessary power to run them, is pointless. They are made for post processing, which means after your track is finished. 😉

Sunborn

https://community.native-instruments.com/discussion/comment/240278#Comment_240278

…by the way, "real time performance" does not mean "play with while mixing".

Real time audio performance refers to the ability of an audio system to process sound with a minimal, unnoticeable delay, or latency. This is crucial in applications where immediate feedback is necessary, such as live performance, music production, or telecommunications. The goal is to make the system's processing delay so short that a user perceives the sound as instantaneous.

So, Ozone, can do real time performance of course. But it has to work alone. Your finished track and Ozone. No other FX, no other Instruments. Mastering is not mixing. It is a much-much heavier work that needs all possible available power.

Sek0ps

Perhap there is room for optimisation when Ozone if consuming so much CPU when it's not processing any audio? i.e. in all the images above, the transport is stopped.

Russellmus

This post helped me a bit. I was getting 'Error while trying to synchronize Audio and MIDI.' when using Ozone 12 in Logic. Tested a little bit after seeing this thread and it turns out its only with IRC 5.

Unfortunate but a workaround I guess.

Quick links

Unanswered questions