One of the UA team had also mentioned that it could be related to how Rosetta is handling it - maybe once it's native M1, 48kHz will take a big jump up in performance with UADx. Speculation at this point.
Thanks for the video Matt - I don't have enough time to try this out today, but will do sometime this week. I'm wondering how the performance is with LUNA and the UADx plugins and if there's a big difference while using the M1 chips.
Thanks! That would be awesome. M1s are certainly powerful. The experience is better than it is with the Trashcan we have. It's smooth even though neither are yet M1 optimized.
Worth noting that both PT and the UAD-plugins still run under Rosetta. So this is very much still a moving targeting and we won't have the real numbers until both of them go fully M1-native. Either way, what all these tests with the UADx-plugins show is how ancient and SLOW the SHARC-chip in the Apollos are compared to new CPUs. They still do the job as far as zero-latency and Unison goes, but beyond that it's pretty limited what they can do at this point.
I agree with much of this. However, I think it shows how surprisingly powerful SHARCs really are when compared fairly (like I feel I did in these tests). An M1 is as powerful as 1.5 - 2 OCTOs.
@@MattHepworth Yeah, it’s a matter of perspective I guess. Considering their age, the SHARC-chip dont do too bad. But, when you start calculating how much you pay for each instance of a plugin in a Satelite vs a modern M1, it gets kinda silly. Personally, I wouldnt recommend anyone buying Satelites at their current price. That’s money out the window. I almost bought a Satelite last year, but I’m SO glad I saved those money and got my Mac Studio instead. Way better investment.
Hey all, just got confirmation from UA that UADx still upsamples to 192kHz. I'm stumped by what I'm seeing. Can others test in a similar fashion and comment what your results are?
Not all up/down sampling is created equally.... There probably is something amiss and they probably worked it out to just copy paste the sampling code from plug-in to plug-in. But it's not a good sign that they would miss something that big before release.
Also latency is lower at 96 than 48, Perhaps the small 32 buffer impacts 48 more than 96. That is, I wonder if you would see the same difference in CPU utilization with a high buffer setting
Steve, I have had both those thoughts as well. Prevailing theory is Rosetta is not as effecient at 48kHz in this particular instance. I'll run the same test on Intel Mac and see what I see.
@@MattHepworth That definitely makes sense. Apple Silicon retains the memory order of Intel but still has to emulate instructions. The additional math here combined with that overhead might explain the difference.
One thing to keep in mind, these tests apply only to playback/mixing. For real-time, near-zero latency recording the DSP versions need to be instantiated in a Unison slot in Console or Luna.
I think it's worth pointing out, that the CPU usage in DAWs isn't 1:1 correlated with the actual CPU usage. Instead, it shows the "cpu time headroom" in relation to when the current buffer has to be completed and sent to the audio card. As an example, lets say you have a quad-core cpu, each core being able to process 100 "cpu-units" of work pr. buffer, ending up with 400 units in total. Now - imagine two audio channels routed to a bus! First channel takes up 70 cpu units, second channel takes 10. Yet - from the bus and forward in the mixer-chain you only have 30 cpu units available (despite using just 80 of the 400 total units), since you need the first audio channel to finish processing, before you can process the bus. However - you'd be able to add a lot of channels / processing *before* the bus, without affecting the "total cpu usage". So - in regards to native plugin-count - "it all depends". 4 plugins one after another on a channel is different from 4 plugins on different channels. And on top of this, many DAWs (Cubase, Logic, quite possibly ProTools as well) employ differentiated latency, allowing the DAW to process "non-realtime" channels out of order at a much higher latency, for significantly better utilization across cpu-cores. Which means that plugin count during playback is different from when you're input-monitoring! On top of this, there is also buffer-size, which adds yet another variable to the mix (pun intended!). Shuffling audio between plugins takes a little bit of cpu-time, and it makes a major difference if you are doing this 44100 / 1024 samples = 43~ times a second, or 44100 / 32 samples = 1378~ times a second .. for each plugin!! So - yeah, its not simple! UAD DSP capacity are not really affected by buffer-size, having a fixed latency of 2 x buffer + plugin latency (upsampling, actual processing, ect). But, native plugins can yield all different kinds of numbers depending on routing-layout of your session, buffersize, DAW - as well as real-time or non-realtime scenarios! Food for thought - as well as insight into why you had non-intuitive numbers in your benchmark. /Rune/
At 44.1 and 48k sampling rates UAD is 4x oversampling. At 88.2 and 96k it's 2x oversampling. What isn't clear is why the low pass filtering (for anti-aliasing) needs to be anything lower than 48k (1/2 Fs) for high sample rate sessions. Should still have a good 40kHz of audio bandwidth and thus gentler filtering.
Oversampling is when you're working at a particular sample rate (44.1kHz, for example), but processing is is done at a higher sample rate for a specific reason. Many UAD plugins upsample to 192kHz while processing the audio. They then down sample back to the project sample rate after that processing is complete. It's done pretty seamlessly.
In the end to get better Quality... Oversampling and Stereo Summing in exports through analog outboard gear as a hardware effect...is gona get you more Analog Quality
Something to keep in mind: unlike DSP, which allocates all the resources it could EVER use, the Native versions are able to only use resources for what's CURRENTLY in use. For apples to apples comparisons you'll need to make sure you've enabled every single module and element in the plugin. You'll also need to do so at your lowest buffer setting. That said, I don't think apples to apples comparisons are the way we should really use UADx. We should use it for its strengths.
im looking forward to trying spark when they have a pc version of it.im not too happy with slates 1176 and la2a compressors. i might end up buying hardware versions of those in the end but heard that uads versions actually behaved like the hardware does so i'm a bit curious.
I think you'll find the UAD/UADx versions are very comparable to the hardware. The only hardware I ever shot out directly was my vintage dbx 160VU against the UA and the Waves. Very close. If I still have that I'll post it as a video. I even went so far as to ensure the plugins passed through DA and AD just like the hardware...
@@MattHepworth Theres just that control where the compression becomes invisible when controlling a high dynamic range like vocals and stuff that im after with the 1176. and there's something about the attack and release , especially the release that plugins doesn't do well. the best one for this so far to me have been fabfilter pro c. but still, side by side with hardware it just doesn't quite get there.
See windows ASIO will let you export out 88hrtz....but an outside interface is going to bump it right back to 48hrtz and then mp3 conversion back to 44.1 hrtz
There is a glaring issue with this though, internally the plugins are only running at 48K internally and the oversampling is doing incorrect internal oversampling multiplication math with linear phase filters. This is why all of the Unison plugins and many of the newer UAD plugins have their anti-aliasing filter stop at 24K. Its an old trick used in low powered DSP. Just use any EQ analyzer on a 96K session and you'll notice the UAD plugins have an incorrect anti-aliasing filter that is cramping the EQ curves. An API 550B is linear from around 25HZ to around 49Khz yet the UAD API DSP and Native has a cut off at 24. I understood this on the DSP platform since it was a 22 year old SHARC DSP but there is NO logical reason to use those same filter schemes on the Native plugins other than fear of sounding different without it or just lazy cross compiling. But UAD is the same company that refused to fix the Harrison SE EQ 15 years ago when it was discovered that the low shelf button didn't work. I own UAD hardware and plugins but the deeper I dive into there tools the sketcher it gets.
They upsample to 192kHz. UA does not hide the fact that they filter at 24kHz, though. The native versions are identical on purpose, though I don't disagree that it would be nice to toggle that filtering on the native versions. You did bring up something I wasn't aware of with the Harrison SE. I'll have to take a peek at that. The only fault I have with the oversampling and filtering is that the LA-2x does it slightly differently and adds 56 samples of latency instead of the 55 that everything else adds. This was tasked to be fixed some time ago, but I believe it has not been addressed. The API 560 was, though, since part of that code was part of the update to the API Vision Channel.
@@MattHepworth The reason is because of the amount of oversampling, at 96K its called a 2x FIR oversampling at 48 it would be 4X. You also have a small amount of division going on in the C+ compiler so that the internal processing is actually done at 48K and is agnostic to the actual sampling rate of the project or DAW. Jerrone from Toneboosters implemented the same style of oversampling in the Toneboosters EQ 4, he told me that he suspected they did it this way to combat DSP overload as well as a stricter antialiasing filter to combat the distortion aliasing that would impact the overall character of the plugins like the unison plugins. But he was speculating and that was the same conclusion other developers came too as well. So the plugin is agnostic to the DAW sampling rate but the oversampling is not that is why it is more efficient at 96K. Cheers!
I guess I'd expect the same behavior with the DSP in that situation. Perhaps that's a native-only phenomenon? With DSP, 96kHz uses about 25% more DSP on most the UA mkII plugins.
@@MattHepworth Well the difference is that the DSP isn't actually multicore so no the behavior would be very different. See the SHARC DSP cores are independent, 1 core per chip, so they can not share the load of a single plugin. So the Sharc chips can't run say an SSL channel strip EQ on one chip's core and the compressor on another from the same plugin. The entire plugin has to fit on a single DSP chip. But ARM and X86 are multicore designs on a single die where as the Sharc DSPs are single chips connected by a tracers on a PCB that then connect to the Thunderbolt/PCI bus. As well as the compiler and scheduler for a CPU/GPU is fundamentally different than dedicated DSP hardware. So even though they are the same code the architecture they are running on is fundamentally very different. This is why I hope they move to FPGA based interfaces when NAMM comes around this year, FPGAs don't have this issue with sampling rate and the amount of plugins you can use stays the same if you are at 48 or 192. Most of the major live mixers are moving to FPGAs for this reason and they have far less latency compared to traditional DSP. Again I like UAD and I own some of the hardware but there are things they should address since their catalog of effects is getting pretty long in the tooth and i think they will make a leap forward at NAMM in a couple weeks!! Cheers!!
96 is probably what the manufacturers use for their 'target' figure for comparing each other. "Industry Standard". So 96 is is going to be the preferred quoted figure (because humans ALWAYS want "the most"...."Any _real professional studio_ is assumed to use...")
UADx aren't M1 Native yet, but I did test with Studio One M1 Native here - Pro Tools *is* more efficient at 96kHz than 48kHz with UADx/UA Spark! ruclips.net/video/4OlWQm_TNbs/видео.html
It's possible. I didn't test against this. I have reached out to Will Shanks at UA for the answer and I'll post in these comments once I have that info.
I doubt about that, because I've seen A/B comparison of Native version (UADx) and SHARC version and when they did null test it nulled perfectly no difference what so ever and also those SHARC processors are so old and slow that I mean literally modern smartphone is more powerful than those SHARC cpus and I'm mot even kidding, so to use less oversampling on native version where modern CPUs like M1 are way more powerful than those SHARC ones makes absolutely no sense. But at 96KHz probably something about that oversampling mechanism changes I've seen this with Softube plugins that if they use 2x internal oversampling if you use 96KHz sample rate they turn oversampling off completely, but I haven't noticed better CPU performance at 96KHz from them tbh. So I'm interested what will be the reply from UAD to this phenomenon.
@@danielkisel5661 I'll post as soon as I have definitive info. I've also done null tests (which nulled), but since UA filters the ultra-HF content, I suppose there's a possibility it wouldn't show as a difference in a null.
Since they upsample to 192kHz anyway there's no sound difference between the versions, so you're good to go at whatever samplerate. It's so strange that you can run even more instances at 96kHz than 48kHz, though!
Thanks for the video Matt!
Can't wait to run some similar tests on our brand new M1 Max Mac Studio. Very impressive results on a M1 Mini!
Yeah, post your results!
Great “Hitchhikers” reference. Thanks! Also great information.
Thank you!
Thanks for the Vid Matt, great stuff as usual.
Thanks so much!
One thing to keep in mind is M1 does some crazy clock scaling and CPU juggling making it hard to predict how some things will act.
One of the UA team had also mentioned that it could be related to how Rosetta is handling it - maybe once it's native M1, 48kHz will take a big jump up in performance with UADx. Speculation at this point.
Thanks for the video Matt - I don't have enough time to try this out today, but will do sometime this week. I'm wondering how the performance is with LUNA and the UADx plugins and if there's a big difference while using the M1 chips.
Thanks! That would be awesome. M1s are certainly powerful. The experience is better than it is with the Trashcan we have. It's smooth even though neither are yet M1 optimized.
Worth noting that both PT and the UAD-plugins still run under Rosetta. So this is very much still a moving targeting and we won't have the real numbers until both of them go fully M1-native. Either way, what all these tests with the UADx-plugins show is how ancient and SLOW the SHARC-chip in the Apollos are compared to new CPUs. They still do the job as far as zero-latency and Unison goes, but beyond that it's pretty limited what they can do at this point.
I agree with much of this. However, I think it shows how surprisingly powerful SHARCs really are when compared fairly (like I feel I did in these tests). An M1 is as powerful as 1.5 - 2 OCTOs.
@@MattHepworth Yeah, it’s a matter of perspective I guess. Considering their age, the SHARC-chip dont do too bad. But, when you start calculating how much you pay for each instance of a plugin in a Satelite vs a modern M1, it gets kinda silly. Personally, I wouldnt recommend anyone buying Satelites at their current price. That’s money out the window. I almost bought a Satelite last year, but I’m SO glad I saved those money and got my Mac Studio instead. Way better investment.
Hey all, just got confirmation from UA that UADx still upsamples to 192kHz. I'm stumped by what I'm seeing. Can others test in a similar fashion and comment what your results are?
Not all up/down sampling is created equally.... There probably is something amiss and they probably worked it out to just copy paste the sampling code from plug-in to plug-in. But it's not a good sign that they would miss something that big before release.
Perhaps the math to upsample from 96 to 196 happens to be considerably less intensive than from 48
Also latency is lower at 96 than 48, Perhaps the small 32 buffer impacts 48 more than 96. That is, I wonder if you would see the same difference in CPU utilization with a high buffer setting
Steve, I have had both those thoughts as well. Prevailing theory is Rosetta is not as effecient at 48kHz in this particular instance. I'll run the same test on Intel Mac and see what I see.
@@MattHepworth That definitely makes sense. Apple Silicon retains the memory order of Intel but still has to emulate instructions. The additional math here combined with that overhead might explain the difference.
Cool video
Thank you!
👍Everything sounds better at higher sample rates...more resolution, less aliasing, more frequency separation.
Sorry, but that's not necessarily true. Not at all.
ruclips.net/video/-jCwIsT0X8M/видео.html
and gentler (less ring-y) low pass filters.
One thing to keep in mind, these tests apply only to playback/mixing. For real-time, near-zero latency recording the DSP versions need to be instantiated in a Unison slot in Console or Luna.
They're usable for real-time in limited quantity. With the right interface you can get a comparable experience, but not reliably like with Apollo.
I think it's worth pointing out, that the CPU usage in DAWs isn't 1:1 correlated with the actual CPU usage. Instead, it shows the "cpu time headroom" in relation to when the current buffer has to be completed and sent to the audio card.
As an example, lets say you have a quad-core cpu, each core being able to process 100 "cpu-units" of work pr. buffer, ending up with 400 units in total.
Now - imagine two audio channels routed to a bus! First channel takes up 70 cpu units, second channel takes 10. Yet - from the bus and forward in the mixer-chain you only have 30 cpu units available (despite using just 80 of the 400 total units), since you need the first audio channel to finish processing, before you can process the bus. However - you'd be able to add a lot of channels / processing *before* the bus, without affecting the "total cpu usage".
So - in regards to native plugin-count - "it all depends". 4 plugins one after another on a channel is different from 4 plugins on different channels. And on top of this, many DAWs (Cubase, Logic, quite possibly ProTools as well) employ differentiated latency, allowing the DAW to process "non-realtime" channels out of order at a much higher latency, for significantly better utilization across cpu-cores. Which means that plugin count during playback is different from when you're input-monitoring!
On top of this, there is also buffer-size, which adds yet another variable to the mix (pun intended!). Shuffling audio between plugins takes a little bit of cpu-time, and it makes a major difference if you are doing this 44100 / 1024 samples = 43~ times a second, or 44100 / 32 samples = 1378~ times a second .. for each plugin!!
So - yeah, its not simple! UAD DSP capacity are not really affected by buffer-size, having a fixed latency of 2 x buffer + plugin latency (upsampling, actual processing, ect). But, native plugins can yield all different kinds of numbers depending on routing-layout of your session, buffersize, DAW - as well as real-time or non-realtime scenarios!
Food for thought - as well as insight into why you had non-intuitive numbers in your benchmark.
/Rune/
Good info, yes. The non-intuitive number, though, is that 96kHz allows *more* instances than 48kHz, relative to buffer.
Matt.. thought you had your cap on backwards. Thank 😊 God it was a cymbal in the background. Ha!
Hahaha!
At 44.1 and 48k sampling rates UAD is 4x oversampling. At 88.2 and 96k it's 2x oversampling.
What isn't clear is why the low pass filtering (for anti-aliasing) needs to be anything lower than 48k (1/2 Fs) for high sample rate sessions. Should still have a good 40kHz of audio bandwidth and thus gentler filtering.
UA has some info about this in their plugin manual about upsampling plugins, actually.
what's mean "oversampling" or "downsampling" especially with UAD plugins and interface ? ( sorry for the noob question but I just started lol... )
Oversampling is when you're working at a particular sample rate (44.1kHz, for example), but processing is is done at a higher sample rate for a specific reason. Many UAD plugins upsample to 192kHz while processing the audio. They then down sample back to the project sample rate after that processing is complete. It's done pretty seamlessly.
In the end to get better Quality...
Oversampling and Stereo Summing in exports through analog outboard gear as a hardware effect...is gona get you more Analog Quality
Whatver interface your using is going to put that right bsck to 48hrtz...
Just so I’m clear, did your test show the UAD plugins using less CPU when at 96k as opposed to 48k?
Hi Mike. UADx did, yes. About 10% less, in a situation where it would normally use substantially more.
@@MattHepworth
Thanks Matt. That’s surprising, but I guess could be a good thing.
I'll be working with UA to better understand it. We have a couple theories. I'll post more if/when I know more.
I've noticed on my PC the uadx plugins are super light on cpu. While on my 3 x series apollo units each instance of the api uses quite some cpu
Something to keep in mind: unlike DSP, which allocates all the resources it could EVER use, the Native versions are able to only use resources for what's CURRENTLY in use. For apples to apples comparisons you'll need to make sure you've enabled every single module and element in the plugin. You'll also need to do so at your lowest buffer setting. That said, I don't think apples to apples comparisons are the way we should really use UADx. We should use it for its strengths.
How do I pull up that System Usage window? I had one just like it on Windows OS, but I can't find it in MacOS.
Activity Monitor is what it's called. You can find it using Spotlight search or browse to Applications\Utilities, I think.
im looking forward to trying spark when they have a pc version of it.im not too happy with slates 1176 and la2a compressors. i might end up buying hardware versions of those in the end but heard that uads versions actually behaved like the hardware does so i'm a bit curious.
I think you'll find the UAD/UADx versions are very comparable to the hardware. The only hardware I ever shot out directly was my vintage dbx 160VU against the UA and the Waves. Very close. If I still have that I'll post it as a video. I even went so far as to ensure the plugins passed through DA and AD just like the hardware...
@@MattHepworth Theres just that control where the compression becomes invisible when controlling a high dynamic range like vocals and stuff that im after with the 1176. and there's something about the attack and release , especially the release that plugins doesn't do well. the best one for this so far to me have been fabfilter pro c. but still, side by side with hardware it just doesn't quite get there.
closest i can get to that kind of control is the free "fircomp" compressor plugin
See windows
ASIO will let you export out 88hrtz....but an outside interface is going to bump it right back to 48hrtz and then mp3 conversion back to 44.1 hrtz
Im studio one you can always export in windows at 88hrtz
There is a glaring issue with this though, internally the plugins are only running at 48K internally and the oversampling is doing incorrect internal oversampling multiplication math with linear phase filters. This is why all of the Unison plugins and many of the newer UAD plugins have their anti-aliasing filter stop at 24K. Its an old trick used in low powered DSP. Just use any EQ analyzer on a 96K session and you'll notice the UAD plugins have an incorrect anti-aliasing filter that is cramping the EQ curves. An API 550B is linear from around 25HZ to around 49Khz yet the UAD API DSP and Native has a cut off at 24. I understood this on the DSP platform since it was a 22 year old SHARC DSP but there is NO logical reason to use those same filter schemes on the Native plugins other than fear of sounding different without it or just lazy cross compiling. But UAD is the same company that refused to fix the Harrison SE EQ 15 years ago when it was discovered that the low shelf button didn't work. I own UAD hardware and plugins but the deeper I dive into there tools the sketcher it gets.
They upsample to 192kHz. UA does not hide the fact that they filter at 24kHz, though. The native versions are identical on purpose, though I don't disagree that it would be nice to toggle that filtering on the native versions. You did bring up something I wasn't aware of with the Harrison SE. I'll have to take a peek at that. The only fault I have with the oversampling and filtering is that the LA-2x does it slightly differently and adds 56 samples of latency instead of the 55 that everything else adds. This was tasked to be fixed some time ago, but I believe it has not been addressed. The API 560 was, though, since part of that code was part of the update to the API Vision Channel.
This also doesn't explain the strange scenario that UADx is MUCH more CPU efficient at 96kHz in PT than at 48kHz.
@@MattHepworth The reason is because of the amount of oversampling, at 96K its called a 2x FIR oversampling at 48 it would be 4X. You also have a small amount of division going on in the C+ compiler so that the internal processing is actually done at 48K and is agnostic to the actual sampling rate of the project or DAW. Jerrone from Toneboosters implemented the same style of oversampling in the Toneboosters EQ 4, he told me that he suspected they did it this way to combat DSP overload as well as a stricter antialiasing filter to combat the distortion aliasing that would impact the overall character of the plugins like the unison plugins. But he was speculating and that was the same conclusion other developers came too as well. So the plugin is agnostic to the DAW sampling rate but the oversampling is not that is why it is more efficient at 96K. Cheers!
I guess I'd expect the same behavior with the DSP in that situation. Perhaps that's a native-only phenomenon? With DSP, 96kHz uses about 25% more DSP on most the UA mkII plugins.
@@MattHepworth Well the difference is that the DSP isn't actually multicore so no the behavior would be very different. See the SHARC DSP cores are independent, 1 core per chip, so they can not share the load of a single plugin. So the Sharc chips can't run say an SSL channel strip EQ on one chip's core and the compressor on another from the same plugin. The entire plugin has to fit on a single DSP chip. But ARM and X86 are multicore designs on a single die where as the Sharc DSPs are single chips connected by a tracers on a PCB that then connect to the Thunderbolt/PCI bus. As well as the compiler and scheduler for a CPU/GPU is fundamentally different than dedicated DSP hardware. So even though they are the same code the architecture they are running on is fundamentally very different. This is why I hope they move to FPGA based interfaces when NAMM comes around this year, FPGAs don't have this issue with sampling rate and the amount of plugins you can use stays the same if you are at 48 or 192. Most of the major live mixers are moving to FPGAs for this reason and they have far less latency compared to traditional DSP. Again I like UAD and I own some of the hardware but there are things they should address since their catalog of effects is getting pretty long in the tooth and i think they will make a leap forward at NAMM in a couple weeks!! Cheers!!
Had this been an actual Emergency… haha 🙂
96 is probably what the manufacturers use for their 'target' figure for comparing each other. "Industry Standard". So 96 is is going to be the preferred quoted figure (because humans ALWAYS want "the most"...."Any _real professional studio_ is assumed to use...")
Perhaps so. The irony, of course, is 96kHz is the least used of the primary three sample rates when it comes to professional use.
Ive got
Virtual Memory at
10k
i7
And
32gb if RAM
I can run about 20 of these
At 48k....and export out at 88
You should have done this test with a modern NATIVE M1 DAW, Pro tools is dead ancient trash.
UADx aren't M1 Native yet, but I did test with Studio One M1 Native here - Pro Tools *is* more efficient at 96kHz than 48kHz with UADx/UA Spark!
ruclips.net/video/4OlWQm_TNbs/видео.html
Only 32 buffer size ? it is very low for mixing.
Yes, low for mixing, but about right for normal production and overdubbing if you're not using some kind of DSP based front end. Keeps latency lowish.
Don't you mean low for tracking or recording? You could mix at 1024 buffer size and it wouldn't matter in the slightest.
@Songstriker Yes. 32 samples for normal production and overdubs. 1024 for mixing.
Maybe SHARCs upsample to 192 and UADx only up to 96
It's possible. I didn't test against this. I have reached out to Will Shanks at UA for the answer and I'll post in these comments once I have that info.
@@MattHepworth The Volt is 96Khz max right?
I doubt about that, because I've seen A/B comparison of Native version (UADx) and SHARC version and when they did null test it nulled perfectly no difference what so ever and also those SHARC processors are so old and slow that I mean literally modern smartphone is more powerful than those SHARC cpus and I'm mot even kidding, so to use less oversampling on native version where modern CPUs like M1 are way more powerful than those SHARC ones makes absolutely no sense.
But at 96KHz probably something about that oversampling mechanism changes I've seen this with Softube plugins that if they use 2x internal oversampling if you use 96KHz sample rate they turn oversampling off completely, but I haven't noticed better CPU performance at 96KHz from them tbh.
So I'm interested what will be the reply from UAD to this phenomenon.
@@danielkisel5661 I'll post as soon as I have definitive info. I've also done null tests (which nulled), but since UA filters the ultra-HF content, I suppose there's a possibility it wouldn't show as a difference in a null.
@@Billy_bSLAYER 192kHz, actually!
What System Usage App is that?
NM. I'm an idiot
I think I was just using Activity Monitor (built in to macOS).
Why only 4 cores in Pro Tools Performance Meter?
Although PT supports M1 CPUs it currently only provides separated metering for the high performance cores, but the main meter (top bar) is correct.
@@MattHepworth thanks for the reply. So, you're using using all, but it's only displaying 4. Makes sense.
@@mikeh7879 That's exactly right. Thanks Mike!
After both coverted to
MP3
You cant hear the difference
Since they upsample to 192kHz anyway there's no sound difference between the versions, so you're good to go at whatever samplerate. It's so strange that you can run even more instances at 96kHz than 48kHz, though!
Are you using reaper? Because Reaper I think automatically runs at 96k within the Daw
Ooops 64khrtz