FabFilter

Hi Chris,

Pro-L 2 doesn't use more than one thread for its processing. The host is responsible for implementing multithreading by distributing plug-ins on multiple tracks across multiple cores. For the 32x oversampling option in Pro-L 2, which you would typically use on the master bus, that means it is currently done by one core only. I just tested on a slightly older Core i7 and got 50% CPU usage with the Modern limiting style.

Cheers,

Cheers Frederick, if you run the test at 44.1 then at 96K you would run out of processing power and at 192K the bouncing would run 2-3 times slower than realtime. That is my problem. We can buy CPUs with loads of cores but the plug ins aren't optimised to use more than 1 core! On the other hand Protools is optimised to spread the load as evenly as possible but every plug in programmer locks the processing in to 1 core! Why? My application is mastering and I use high sampling rates with high upsampling AND I need at the very least real time bouncing not slower. Why is this so difficult?

Audio is sequential data, how would you process that parallel? Limiting is not for example like a synth in which you could give every voice its own core because they're more or less independent. It's applying continuous volume changes. Just my 2 cents.

Yup. The single core performance is what matters in this case. You can't parallel a processing of a single track. All multicore load is about multiple tracks/synth with multivoicing.

P.S. Just wondering, why would anyone use a x32 oversampling within a 192 kHz session? That's a 6+ MHz bandwidth.

You have to listen to it Sergey! Dynamic processing in digital need ridiculous bandwidth.
Kolja, of course it is sequential but not being able to use more cores
for a single process is problematic.

Yes, it is problematic in certain circumstances (this one is an extreme case). But there usually isn't much choice. There are processes that just can't be split into tiny parts and then be given to multiple cores. Audio in general is such a case. Unfortunately samples/envelopes/filters depend on previous samples or results.

There are effects like IR based reverbs that can do this, analyzer can do this, synths can do this in parts, multiband plugins could do this too I think. Though there is always also the cost of synchronization, especially when you want to keep stuff low latency.

BTW true peak limiting with 32x oversampling takes 30% CPU @44.1kHz here, 65% @96kHz and I get dropouts with 192kHz. I barely work with 32x and if I work with higher sample rates, I decrease oversampling though, since it doesn't really decrease audible artefacts anymore.

While it's debatable whether you need 32x oversampling at 44.1 kHz, you definitely don't need it when running at 192 kHz. So I would just recommend using a lower oversampling rate when using 192 kHz as a sample rate.

Cheers,

Hi Frederic,

We don't need opinions of what is debatable or useful in our work.

There is correctly an option in the software and some of us want to use it. If you think that we don't really need it is completely irrelevant and out of topic conversation.
Either you can or willing to optimise it to be able to do X32 upsampling for all sampling rates or not. The rest is just unnecessary.

chrisp

Sorry but "the software allows it so you have to optimize it" is a weak argument I think. If I take any synth, create a patch with 8 layers, modulate the heck out of it and play 64 voices, this will burn my CPU (probably even in 44.1/48khz). But the software allows it, so it's not my fault, right?

Wrong. First it's up to your own machine (buy the most up to date CPU and you'll of course be able to process more stuff than with a 10 year old machine) and then it's up to you how reasonable you use the features.
You decide to run 192khz, so you know the consequence of 4x the CPU consumption compared to 44.1kHz. You decide to oversample 32x, so you know the consequence of additional CPU usage.

I have no issues playing back 32x oversampling in 192khz with a buffer size of 4096 on an Intel i9.

OK Marcus,

Can you share which i9 and which DAW?

I tested today with i9 2.9Khz and I can't do it although the plug in uses less than 10% of the CPU. And that was my original question which system can do it. By the way of course they need to optimise both plug ins and DAW software so they can use the power of the CPUs. There is no reason to get work up about it.

Just my 2 cents.

The CPU utilization is not a correct indication of the load when it comes to the real time audio, here's the video with a detailed explanation: www.youtube.com/watch?v=GUsLLEkswzE

If your usage is mostly about a single track with a bunch of heavy plugins, the single core performance is what matters here, you just can not parallel a sequential processing.

And yeah, the 6+ MHz banwidth requires some SERIOUS horsepower. Also, low DPC latency, which could be introduced with background apps, device drivers etc. See LatencyMon app if you're on Windows.

Thanks Sergey,

My application is indeed single track with heavy plug ins and I am looking for a possible solution especially reducing bouncing time.
I wish they could write the plug in code for the HDX or UAD dsp cards but at the moment is just native single core usage. Absolutely correct that you can't parallel a sequential process but there must be a way to utilise more efficiently the CPU cores or maybe we need even faster core speeds. Anyway if somebody has a system that performs reliably
at 192khz and Pro-L with x32 upsampling I would love to hear from.

Cheers

chrisp

An i9 Intel CPU runs circles around any combination of HDX/UAD DSP chips. These DSP chips are really not that powerful. The main advantage of using them is that DSP cards offer very low latency and are very reliable when doing real-time processing, something that is harder to achieve with native processing on a non-real-time operating system like macOS or Windows.

Cheers,

OK Frederik,

Since you are so knowledgable about the various dsp cards and processors, can you please let us know which i9 and DAW can do x32 upsampling at 192 khz sampling rate with the Pro-L? Mind you professional people are already at even higher sampling rates!

chrisp

Sorry for delay. I switched from an AMD Ryzen Threadripper 3970X (buggy for use in audio production) to an Intel i9 10850k. I work with Pro Tools 2021.10 as well as Studio One 5.4 and also tried it in Reaper 6.4. Audio Interface is from Avid, buffersize 4096 samples. Not sure if the AMD was capable of doing it, never tested.

Also I usually do not 32x oversample 192kHz or 394kHz, this was just for your test. There's no proper reason to do so and for scientific cases there's scientific software.

At that point I'd like to thank FabFilter, because of your test I tried the oversampling with other plugins as well and was astonished how performant Pro-L2 already is. Those plugins are low on CPU in general, but even if they need to process some more, they are amazing.

Wow Marcus,

That's great information, thank you very much.

Would you recommend the i9 10850K over the latest 12900K for

this kind of audio work?

Cheers

Chrisp

M1 Pro :P

Hi Ploki,

Can you share a bit more info?

Which DAW and have you tired the x32 with a 192K sampling rate?

Cheers

Chrisp

Logic Pro.
I'm still on the original M1 (4+4core), i can run 5 instances @32x oversampling before getting an overload. On the M1 Pro it should be around 8-9 then

this is with the largest buffer (1024) and process buffer Large.
Since CPU usage is not at 100% and as it goes with M1, running buffer 64 and Process buffer Medium, it still caps at 5 instances.

Session is at 192khz

Amazing, many thanks Ploki!

I should definitely try it!

This is great.

Cheers

chrisp

Make sure that each of the Pro-L2 instances are actually doing gain reduction. It is possible that the plugin is not using all of the required processing power if just passing the signal through.

Very good point Sergey!

good point, will check it out

Yeah, no. :D
Logic just overloads, and in Studio One it plays but it glitches.
(192k @32x)

96k no issue on either

Tried on Reaper ARM, and for some reason Reaper ARM was able to play it back without glitches.

This is the original M1 13" MacBook Pro . Fan didn't come on

Thanks Ploki,

That's great info.

For what is to worth, on a 2018 MacBook Pro with i9 2.9Ghz
I managed 1 instance of 192K X 16 upsampling.

Hi Chris, I've not had a chance to test the 12900k and I doubt I'll have in the near future, since I updated my PC just last year.

But given the recent news the 12900k being the "best CPU" outperforming even the Apple M1 chips, I think you can't go wrong with it.

Ploki, just remember that he’s talking about single-threaded performance (Eg one insanely demanding plug-in chain). If you can run one instance of a plug-in on six tracks it doesn’t mean that you can run six instances of that plug-in on one track.

Anyway it sounds like what the original poster wants is for Pro-L to disable 32x if the system can’t handle the load. I’m not sure if plugins can really get that much insight in to CPU performance. But I know some plugins have separate, higher-quality offline processing options. So maybe FF could consider adding this at some future time?

Jus for the record Tk,

I love the x32 feature of the Pro-L and I think it is the best feature ever!

I just also want to be able to run it in real time and that will take loads

of optimisation and perhaps more options on how we utilise the cpu cores for the DAW and the plug ins.

Right. But from what I understand multicore performance is more of a DAW engine issue. I don't even know if ProL can handle more than a single thread.

Yes, it can't, every plug in is a single thread affair and that's my problem. If we could assign threads or cores to various plug ins then
processing for mastering or mixing bus for example would have been much more productive and manageable at high resolution. Or if plug ins could utilise more than one core but every programmer says to me that it is too difficult. On the other hand different DAWs exhibit different optimisations and plug in performance.
Digital has some growing up to do!