Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 6:05:53 GMT -6
I haven't had any UA products, but I had concerns going from a SSL MX4 DSP system to an all-native plugin setup. I ran a lot of plugs on the DSP card and never had issues with CPU/RAM loading. After reading all about people overloading their CPUs and such running what seemed to be normal signal chains I was worried. Turns out it was nothing to worry about. I run 4x the amount of plugs in my sessions now and barely get above 40% CPU. The only plugs I can't record with in real-time are a couple reverbs that have higher DPC latency. So I wouldn't worry too much about going away from DSP plugs and into natives. I did a quick test, so I had 14 audio tracks with NI's 1176 and a native pultec EQ. 2 tracks with Guitar rig pro on it, 4 lots of Kontakt synths including 4X aux's with RC48 and stereo 1176, plus Abbey Road Modern Drummer (which is a quite the CPU hog may I say). They all had EQ / comp etc. on them.. I ran the project at 96Khz / 32 samples on a 2019 2.6Ghz hexacore (12 threads) Mac and in general I was using 35% of my CPU. Problem is the multi-thread usage was rather lop sided, in Logic there's a CPU meter and certain plugs just trashed the 1st thread. Ozone broke it whilst the rest of the CPU was yawning away (probably because it ran on the same thread as the VST's), some bus effects also kept the 1st thread spiking (Ozone off). I switched the project to 64 samples, took Ozone off again and It settled to about 40% CPU usage across the board until I arm enabled Abbey Road MD which caused more buffer under runs.. At 96Khz / 32 samples the latency for a USB audio interface using Core Audio is about 5.2ms RT, 64 samples is 5.9 and 128 samples is 7.2ms.. The latter not being ideal for overdubs really.. The biggest surprise was changing the buffer size (up to 128 at least) really didn't make much much of a difference. So, I probably would still worry about going from DSP to native in some instances.. However there's ways around it, I froze two of the heaviest Kontakt instances and I was able to run the entire session at 32 / 96Khz whilst using 15% CPU w/ Ozone 9 enabled, I'm really not sure why it affected the 1st thread (and CPU usage) so much, maybe midi VST instruments to bus tracks cause extensive overhead? Anyway I suppose if you're happy to freeze a few bits / unload / bypass and re-load plugs etc. then it's not an issue. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 8:37:13 GMT -6
I haven't had any UA products, but I had concerns going from a SSL MX4 DSP system to an all-native plugin setup. I ran a lot of plugs on the DSP card and never had issues with CPU/RAM loading. After reading all about people overloading their CPUs and such running what seemed to be normal signal chains I was worried. Turns out it was nothing to worry about. I run 4x the amount of plugs in my sessions now and barely get above 40% CPU. The only plugs I can't record with in real-time are a couple reverbs that have higher DPC latency. So I wouldn't worry too much about going away from DSP plugs and into natives. I did a quick test, so I had 14 audio tracks with NI's 1176 and a native pultec EQ. 2 tracks with Guitar rig pro on it, 4 lots of Kontakt synths including 4X aux's with RC48 and stereo 1176, plus Abbey Road Modern Drummer (which is a quite the CPU hog may I say). They all had EQ / comp etc. on them.. I ran the project at 96Khz / 32 samples on a 2019 2.6Ghz hexacore (12 threads) Mac and in general I was using 35% of my CPU. Problem is the multi-thread usage was rather lop sided, in Logic there's a CPU meter and certain plugs just trashed the 1st thread. Ozone broke it whilst the rest of the CPU was yawning away (probably because it ran on the same thread as the VST's), some bus effects also kept the 1st thread spiking (Ozone off). I switched the project to 64 samples, took Ozone off again and It settled to about 40% CPU usage across the board until I arm enabled Abbey Road MD which caused more buffer under runs.. At 96Khz / 32 samples the latency for a USB audio interface using Core Audio is about 5.2ms RT, 64 samples is 5.9 and 128 samples is 7.2ms.. The latter not being ideal for overdubs really.. The biggest surprise was changing the buffer size (up to 128 at least) really didn't make much much of a difference. So, I probably would still worry about going from DSP to native in some instances.. However there's ways around it, I froze two of the heaviest Kontakt instances and I was able to run the entire session at 32 / 96Khz whilst using 15% CPU w/ Ozone 9 enabled, I'm really not sure why it affected the 1st thread (and CPU usage) so much, maybe midi VST instruments to bus tracks cause extensive overhead? Anyway I suppose if you're happy to freeze a few bits / unload / bypass and re-load plugs etc. then it's not an issue. Single core performance was and is still a hugely limiting factor. And it just sucked and still sucks on most macs, which couldn’t push the Intel CPUs into turbo all the time and arm, well arm the clock rate is it. This is why you can never have enough cpu power. You’re going to max out one of the cores and bring it to its knees with a heavy itb workflow. Kontact/Diva -> Tupe on hq -> Kirchoff eq -> Molot GE on insane -> cool shelf eq -> Satin and stack up the tracks with reverb and delay sends. Throw Izotope stuff in and damn. Time is money and freezing is money down the drain. Having to freeze and unfreeze is a huge workflow and efficiency killer. If UAD prevents that, use them. Just gojng with a UAD card and an Apollo instead of a new computer puts a band aid on the wound though. |
|
|
|
Post by svart on Dec 28, 2021 9:01:12 GMT -6
I haven't had any UA products, but I had concerns going from a SSL MX4 DSP system to an all-native plugin setup. I ran a lot of plugs on the DSP card and never had issues with CPU/RAM loading. After reading all about people overloading their CPUs and such running what seemed to be normal signal chains I was worried. Turns out it was nothing to worry about. I run 4x the amount of plugs in my sessions now and barely get above 40% CPU. The only plugs I can't record with in real-time are a couple reverbs that have higher DPC latency. So I wouldn't worry too much about going away from DSP plugs and into natives. I did a quick test, so I had 14 audio tracks with NI's 1176 and a native pultec EQ. 2 tracks with Guitar rig pro on it, 4 lots of Kontakt synths including 4X aux's with RC48 and stereo 1176, plus Abbey Road Modern Drummer (which is a quite the CPU hog may I say). They all had EQ / comp etc. on them.. I ran the project at 96Khz / 32 samples on a 2019 2.6Ghz hexacore (12 threads) Mac and in general I was using 35% of my CPU. Problem is the multi-thread usage was rather lop sided, in Logic there's a CPU meter and certain plugs just trashed the 1st thread. Ozone broke it whilst the rest of the CPU was yawning away (probably because it ran on the same thread as the VST's), some bus effects also kept the 1st thread spiking (Ozone off). I switched the project to 64 samples, took Ozone off again and It settled to about 40% CPU usage across the board until I arm enabled Abbey Road MD which caused more buffer under runs.. At 96Khz / 32 samples the latency for a USB audio interface using Core Audio is about 5.2ms RT, 64 samples is 5.9 and 128 samples is 7.2ms.. The latter not being ideal for overdubs really.. The biggest surprise was changing the buffer size (up to 128 at least) really didn't make much much of a difference. So, I probably would still worry about going from DSP to native in some instances.. However there's ways around it, I froze two of the heaviest Kontakt instances and I was able to run the entire session at 32 / 96Khz whilst using 15% CPU w/ Ozone 9 enabled, I'm really not sure why it affected the 1st thread (and CPU usage) so much, maybe midi VST instruments to bus tracks cause extensive overhead? Anyway I suppose if you're happy to freeze a few bits / unload / bypass and re-load plugs etc. then it's not an issue. I see. Seems like certain plugs are causing more issues than others. I don't use those plugs, so I guess I can't really relate to your specific situation. Does the 2.6G CPU have a turbo mode? Can you lock it to max turbo frequency? Lots of plugs have issues when the CPU load management tends to try to shift C states back and forth too quickly to conserve power. On my machine (PC) I've locked the CPU to use max all-core frequencies which are around 4.8GHz. I use buffer of 128 and I get around 8ms round trip times similar to yours, but nobody I've tracked nor I have been able to perceive any latency from this, so I don't know why 5ms is fine but 8ms is not for you. It sounds like your Kontact and Ozone are fighting for the same thread/core here. I don't know if there's any way to force either to other cores or not. I haven't seen any of my plugs hog specific cores, yet. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 9:48:27 GMT -6
Single core performance was and is still a hugely limiting factor. And it just sucked and still sucks on most macs, which couldn’t push the Intel CPUs into turbo all the time and arm, well arm the clock rate is it. This is why you can never have enough cpu power. You’re going to max out one of the cores and bring it to its knees with a heavy itb workflow. Kontact/Diva -> Tupe on hq -> Kirchoff eq -> Molot GE on insane -> cool shelf eq -> Satin and stack up the tracks with reverb and delay sends. Throw Izotope stuff in and damn. Time is money and freezing is money down the drain. Having to freeze and unfreeze is a huge workflow and efficiency killer. If UAD prevents that, use them. Just gojng with a UAD card and an Apollo instead of a new computer puts a band aid on the wound though. It'll do a solid 4.0Ghz consistently when turbo'd even though it gets hot, the 2.9 version of my MBP era machine had some serious heat throttling issues AFAIK hence the reason I avoided it. Thing is even the fastest single thread CPU according to Passmark (i9-12900KF) with a whopping 5.2Ghz clock speed isn't twice as fast (single core) so what's that, 2 - 4 instances of some heavy duty plugs? Multi-core on a relatively new(ish) I7 / M1 etc. doesn't matter at this point, I got bored around the 100 plug mark when the machine could spread them out properly. Anyway, there's definitely still a case for DSP consoles in instances, especially with VST's and heavy duty effects (convolution verbs, tape sims, advanced limiters etc.).. If UA bought Toontrack sheesh, they'd corner the market (more than they already have). |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 10:20:50 GMT -6
I see. Seems like certain plugs are causing more issues than others. I don't use those plugs, so I guess I can't really relate to your specific situation. Does the 2.6G CPU have a turbo mode? Can you lock it to max turbo frequency? Lots of plugs have issues when the CPU load management tends to try to shift C states back and forth too quickly to conserve power. On my machine (PC) I've locked the CPU to use max all-core frequencies which are around 4.8GHz. I use buffer of 128 and I get around 8ms round trip times similar to yours, but nobody I've tracked nor I have been able to perceive any latency from this, so I don't know why 5ms is fine but 8ms is not for you. It sounds like your Kontact and Ozone are fighting for the same thread/core here. I don't know if there's any way to force either to other cores or not. I haven't seen any of my plugs hog specific cores, yet. Yes and yes, it runs at 4.0Ghz.. In terms of latency that's a long and drawn out subject but AES did some research into the matter. Apparently vocalists will notice discrepancies at 3ms, according to their study it seems to be centred around the instrument itself more than the players of said instrument. I suppose adaption is a factor as well, I'm relatively sensitive to latency but I'm sure in the past I've used less than desirable interfaces / machines with poor latency and just got on with it. music.stackexchange.com/questions/30323/when-does-audio-latency-matter-and-not-matterPersonally none of this really matters because of my new setup (mixer with OTB synths, comps, verbs, EQ's, mastering limiter etc.). Because I can monitor through the desk that'll cut latency in half and the CPU will be barely ticking over as the need for plugs is extremely small at best. I just found it rather interesting after being part of the DSP ecosystem for many moons, it has been a while since I've tried "true native". |
|
|
|
Post by viciousbliss on Dec 28, 2021 10:31:20 GMT -6
I got the Vision and the Studer with coupons. Been playing around with Massive Passive. It's definitely a lot thinner than Magenta. But one is not really a substitute for the other. Magenta sometimes takes a minute or two to activate and deactivate in PT, Acustica can be such a workflow killer. SPL Passeq is also bigger and fuller-sounding than Massive Passive and kinda allows you to do the same thing. It's easier to tweak a master with. Massive Passive feels like it should be on some $29.99 PA sale, not demanding $100 after a coupon. The reason I got the Studer is because with what I'm using now for mixing, it gets the right frequencies in the music tracks out of the way better than my other tape sims. It's bigger and fuller than any of the others. But also very clear too. It's a very identifiable sound and something I notice in a lot of classic albums now. It also makes the UAD 102 pair much better with my mixes when I use it in mastering.
I'm definitely curious what the fastest processors can do nowadays. I'm still running a slightly overclocked 1700 with 8 gigs of RAM. I know there's processors now that have about a 50% higher single core speed even without overclocking. Molot GE in insane mode definitely can put a drag on my PC though, even in 44k sessions. Usually I just use a few mono instances. I'm not sure how much a 50% higher single core speed would allow me to run though. A lot of these high single core speed cpus also have multi-core speeds that are in the territory of the original Threadripper processor that had the most power, I think.
There's been some debate on GS about whether UAD saves any cpu power nowadays. I believe it was Undertow/Alistair who gave a detailed post about why the processing power used by UAD hardware ends up eating up more cpu than using native plugins. Maybe 20 years ago cpus were so weak that a UAD card used less. With my first Octo Satellite that was ruled defective after months of haggling with UAD support over its various problems, adding a bunch of UAD to a big 96k session that was previously all native made me run out of cpu a lot easier. I'm not sure I've experimented since. Usually I don't come close to maxing out cpu unless I'm using a lot of Molot GE or a few Acusticas.
UAD has a lot of phenomenal and very good stuff though and I'd say it's worth owning for anyone really into audio.
|
|
kcatthedog
Temp
Super Helpful Dude
Posts: 15,850 
Member is Online
|
Post by kcatthedog on Dec 28, 2021 11:19:48 GMT -6
“processing power used by UAD hardware ends up eating up more cpu than using native plugin”
Ah, people are drawing direct comparisons between sharc chips and computer chips, not following the basis of that comparison ?
Sharc chips aren’t fast !
Can’t say I get all the hullabaloo, if one already has UA plugs and an octo, very unlikely you will sell all that simply to buy a more powerful computer?
If one were starting fresh then yes one needs to decide. But not everyone has the experience of those here who know exactly what other plugs they would buy instead of UA.
I wonder too kind of like pro tools what pro can afford to not run UA in the sense of if you are sent a session with UA plugs : what ya going to do?
Sure UA could go native, but boy that corporate decision would need a huge amount of marketing finesse re: the embedded client base backlash.
I can’t believe the sense of entitlement behind many of the complaints I read at UA forum, dropping sharcs would be huge.
|
|
|
|
Post by ab101 on Dec 28, 2021 11:24:51 GMT -6
Would it be wise for UAD to upgrade the sharcs, perhaps with a discount for current owners? Would it make a practical difference in the use of an Octo card, for example?
|
|
|
|
Post by svart on Dec 28, 2021 11:58:37 GMT -6
“processing power used by UAD hardware ends up eating up more cpu than using native plugin” Ah, people are drawing direct comparisons between sharc chips and computer chips, not following the basis of that comparison ? Sharc chips aren’t fast ! Can’t say I get all the hullabaloo, if one already has UA plugs and an octo, very unlikely you will sell all that simply to buy a more powerful computer? If one were starting fresh then yes one needs to decide. But not everyone has the experience of those here who know exactly what other plugs they would buy instead of UA. I wonder too kind of like pro tools what pro can afford to not run UA in the sense of if you are sent a session with UA plugs : what ya going to do? Sure UA could go native, but boy that corporate decision would need a huge amount of marketing finesse re: the embedded client base backlash. I can’t believe the sense of entitlement behind many of the complaints I read at UA forum, dropping sharcs would be huge. It's not about the overall speed of the DSP chips. It's about shuffling the data into and out of the DSP array. The CPU still has to compute certain things, and the system still has to process and package up the data to/from the DAW to the DSP array. Much like how older spinning HDD can become a bottleneck now and SSD can drastically improve system speeds. |
|
|
|
Post by svart on Dec 28, 2021 12:18:04 GMT -6
Single core performance was and is still a hugely limiting factor. And it just sucked and still sucks on most macs, which couldn’t push the Intel CPUs into turbo all the time and arm, well arm the clock rate is it. This is why you can never have enough cpu power. You’re going to max out one of the cores and bring it to its knees with a heavy itb workflow. Kontact/Diva -> Tupe on hq -> Kirchoff eq -> Molot GE on insane -> cool shelf eq -> Satin and stack up the tracks with reverb and delay sends. Throw Izotope stuff in and damn. Time is money and freezing is money down the drain. Having to freeze and unfreeze is a huge workflow and efficiency killer. If UAD prevents that, use them. Just gojng with a UAD card and an Apollo instead of a new computer puts a band aid on the wound though. It'll do a solid 4.0Ghz consistently when turbo'd even though it gets hot, the 2.9 version of my MBP era machine had some serious heat throttling issues AFAIK hence the reason I avoided it. Thing is even the fastest single thread CPU according to Passmark (i9-12900KF) with a whopping 5.2Ghz clock speed isn't twice as fast (single core) so what's that, 2 - 4 instances of some heavy duty plugs? Multi-core on a relatively new(ish) I7 / M1 etc. doesn't matter at this point, I got bored around the 100 plug mark when the machine could spread them out properly. Anyway, there's definitely still a case for DSP consoles in instances, especially with VST's and heavy duty effects (convolution verbs, tape sims, advanced limiters etc.).. If UA bought Toontrack sheesh, they'd corner the market (more than they already have). I suppose I could look it up myself, but do you know if the UAD DSP will allow non-DSP plugins to run? My old SSL DSP would allow it, but it would wrapper them up and run them on CPU regardless, and this seemed slower than simply running them in the DAW itself. I had to be careful to only run DSP accelerated plugs on the DSP card, so third party plugs like Ozone wouldn't even work on the DSP system without causing more headaches. |
|
kcatthedog
Temp
Super Helpful Dude
Posts: 15,850
Member is Online
|
Post by kcatthedog on Dec 28, 2021 12:28:56 GMT -6
There is a sort of dual core sharc chip but apparently when UA tried them there were heat issues.
I am not aware of UA dsp running any other plug ins, is that what you meant svart or am I misunderstanding you ?
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 13:07:23 GMT -6
There is a sort of dual core sharc chip but apparently when UA tried them there were heat issues. I am not aware of UA dsp running any other plug ins, is that what you meant svart or am I misunderstanding you ? Let's cut this short CPU's cost too much, they do too much and they give off too much heat. So there were "reasons" back in 1995 but nowaday's.. C'mon? I've heard everything via articles etc. from lack of FMA ops (which were announced by Intel in 2008 (alongside AVX)) to memory, never heard of cache? Some of these were from 2021 as well. There's a few arguments still but.. The lines have gotten even blurrier, Apple have just moved to an ARM SOC (system on chip) for their M1's and mobile phones have more processing power than an older mac mini. You can use ARM as a microprocessor w/ DSP architecture to do pretty much everything and considering a 10W TDP for that amount of power. Yeah.. This has nothing to do with "DSP" at this point as it'll always have uses (not going to use an I9 in a speaker are ya?), it's a matter of offloading methodology to get plugins away from your core CPU (if needed) and the expense of migrating from DSP code. |
|
kcatthedog
Temp
Super Helpful Dude
Posts: 15,850
Member is Online
|
Post by kcatthedog on Dec 28, 2021 13:19:48 GMT -6
not arguing with you but the dual core sharc chips I think were released about 5 years ago. I had seen a reference to someone talking to someone in the know at UA about considering those chips as they had the same footprint/ pin out as the current chips.
All water under the bridge.
My octo and my used m1 mini cost around the costs of an entry level new mbp m1x, still seems like good value to me.
|
|
|
|
Post by Guitar on Dec 28, 2021 13:21:37 GMT -6
God I love listening to Engineers talk about equipment. I need to go to EE school or just join a club or something.
I wouldn't be surprised at all if UAD DSP plugins actually make your native CPU work harder than if the same code was running native.
It's like some huge cosmic joke that this expensive DSP really is just "a dongle." And one that slows down your system!
|
|
|
|
Post by ab101 on Dec 28, 2021 13:44:51 GMT -6
This conversation, including the accessing of the Sharc chips and CPU impact, is making me wonder if plugins should ideally be on another drive besides the C drive? Is the DAW accessing the plugins while playing back, or is all the information needing to be accessed in RAM, or is it just nonconsequential? This part is over my head!
|
|
|
|
Post by svart on Dec 28, 2021 13:57:21 GMT -6
This conversation, including the accessing of the Sharc chips and CPU impact, is making me wonder if plugins should ideally be on another drive besides the C drive? Is the DAW accessing the plugins while playing back, or is all the information needing to be accessed in RAM, or is it just nonconsequential? This part is over my head! Completely up to the code I think, but I also think most of the actual "plugin" would be in RAM. The plugin code shouldn't be all that complex. It's what it's doing with the audio data that needs the resources. |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Dec 28, 2021 14:00:35 GMT -6
God I love listening to Engineers talk about equipment. I need to go to EE school or just join a club or something. I wouldn't be surprised at all if UAD DSP plugins actually make your native CPU work harder than if the same code was running native. It's like some huge cosmic joke that this expensive DSP really is just "a dongle." And one that slows down your system! DSP from a 1000 mile view is a dedicated (mostly parallel operation) form of processor with specific dedicated arithmetic systems that are cheap, low latency, heat efficient and effective at their purposes due to their architecture (HBA, memory / bank organisation etc.) At one point they were on average 2 - 3 times more powerful at specific operations than an equivalent multi-purpose RISC or X86 device.. Now SOC's (especially) have everything + the kitchen sink included plus a lot of raw brute power whilst remaining efficient that's not necessarily the case.. I'm all for offloading certain plugins especially when they continue to increase in CPU consumption however I'm not convinced Sharc is the future.. |
|
|
|
Post by svart on Dec 28, 2021 14:06:43 GMT -6
God I love listening to Engineers talk about equipment. I need to go to EE school or just join a club or something. I wouldn't be surprised at all if UAD DSP plugins actually make your native CPU work harder than if the same code was running native. It's like some huge cosmic joke that this expensive DSP really is just "a dongle." And one that slows down your system! DSP from a 1000 mile view is a dedicated (mostly parallel operation) form of processor with specific dedicated arithmetic systems that are cheap, low latency, heat efficient and effective at their purposes due to their architecture (HBA, memory / bank organisation etc.) At one point they were on average 2 - 3 times more powerful at specific operations than an equivalent multi-purpose RISC or X86 device.. Now SOC's (especially) have everything + the kitchen sink included plus a lot of raw brute power whilst remaining efficient that's not necessarily the case.. I'm all for offloading certain plugins especially when they continue to increase in CPU consumption however I'm not convinced Sharc is the future.. We use FPGAs for our DSP stuff at work. We can tailor DSP pipelines for specific work using MATLAB and just reconfig as needed. Not quite as low cost as ASIC DSP chips, but the ability to change DSP architecture on the fly is worth it. |
|
