• Welcome to the General Discussion forum for UAD users!

    Please note that this forum is user-run, although we're thrilled to have so much contribution from Drew, Will, and other UA folks!

    Feel free to discuss both UAD and non-UAD related subjects!

    1) Please do not post technical issues here. Please use our UAD Support Forums instead.

    2) Please do not post complaints here. Use the Unrest Forum instead. They have no place in the the General Discussion forum.

    Threads posted in the wrong forum will be moved, so if you don't see your thread here anymore, please look in the correct forum.

    Lastly, please be respectful.

I Challenge UA to Fix The DSP Limitations on This Platform

scratch17

Venerated Member
If UA does not fix the platforms' DSP limitations, count me out when it comes to new interfaces. I did not post this in the Wants and Wishes category because it is a necessity, not a feature upgrade I'd like to see.

I was going to respond to the thread about waiting for TB3 on new UA interfaces. As I started to write my reply, I found myself writing, "I don't care if a new interface has TB 1, 2 , 3 or 33!"

That got me to thinking. No incremental improvement in the UA platform will be nearly enough of an incentive for me to purchase any other hardware (and maybe plugins) from UA. Not TB3; not full MIDI implementation, not dual core SHARCs on Apollo; not AVB; not even a digital only in/out version of Apollo.

Don't get me wrong, I am a huge fan of UA. I have made a huge investment in plugins, an Apollo 8 Duo, and a SF Quad.

Nor am I planning to leave the platform. I am selling my Apollo Quad SF and my Apollo 8 Duo to buy a new Apollo 8 Quad. I will do so because of the promo. The Quad Satellite offer entices me enough to go with the current limitations. But I am not going further with UA. At this point, we are stuck.

So at the risk of stating and repeating the obvious:

One DSP per track just doesn't cut it. Period. And not being able to use chips across multiple Apollos is ridiculous. Multi-threading and multi-core technology on native systems has been available for more than a decade. No, I am not asking for or wanting native versions of UA plugins. I am simply making the point that other systems are not limited in this manner.

I understand that there are physical reasons for the DSP limitations with respect to the PFGA chips in Apollos.

So I challenge UA: Even if you have to charge more for an Apollo with a PFGA capable of using DSP across hardware and more than one chip on a track, just do it. At that point I will buy.

When I bought my Apollo 8 in 2015, I did not understand these limitations. That is on me. I should have done more research into the platform.

But it is two+ years later. When you consider the entry level cost for an Apollo 8, you should not have to put up with this situation. The number one reason I bought into the UA world was I wanted to be able to access the UA plugins. I thought that having the hardware host the plugins with on board DSP would be a plus. Then I ran into the DSP limitation issues.

Winter NAMM is upon us. The big rumor is a Twin single with a TB3 connector. Why on earth should we care? Sure, I am all for any updated feature set like TB3, MIDI implementation, etc., for Apollo. But without a DSP limitations fix, it is simply not enough.

As a group, those of us on this forum over the last few years have generally accepted this state of the UA universe. I believe it is high time we stopped accepting a system with a basic design flaw. What do you think?
 

Kcatthedog

Hall of Fame Member
"Multi-threading and multi-core technology on native systems has been available for more than a decade."

While this is true, I wonder if this is the solution or what is the real problem ? I wondering if the upsampling of Ua plugs, although a processing step, somehow prevents ua from implementing a dsp solution ?
 

drsax

Member
I think we live in a time where our options are incredible. Each manufacturer and platform has its own benefits and limitations. I’d like to see some of those features too, especially Routing across multiple units and dsp shared across units for live tracking... but I’ve used so many products and you have to purchase based on your needs. In the end, for me, the Apollo workflow is pretty amazing. I previously had a 192 i/o interface which could route to any input to any output... and rarely used that feature. The way Apollo integrates to live sessions with 4 headphone cues, and a great UI - well, I think it’s amazing. They can’t please everyone and it seems as though they are advancing their platform. As long as they keep improving it and keep us audio professionals in mind, I think the future is bright with UA. The stability of their system is worth more to me than any features.
 

Kcatthedog

Hall of Fame Member
ah the computers or the apollos ? Given all the inconsistencies reported with windows , as a platform and with windows configs as opposed to apple, i don't think the poll result would tell us very much of anything ? I'd completely expect worse anecdotal reporting of windows performance ?
 

ChrisMilne

The Originator
Moderator
ah the computers or the apollos ? Given all the inconsistencies reported with windows , as a platform and with windows configs as opposed to apple, i don't think the poll result would tell us very much of anything ? I'd completely expect worse anecdotal reporting of windows performance ?
Well the drivers for Windows and thunderbolt are pretty recent and since they moving away from the USB interface there must have been some issues (or didn't sell well) as well?

Although my only Mac i've ever bought was a macbook pro for $2000, and it didn't go well. The battery died after a year of use ($120 to replace) and then not long after my wife left it at her parents while visiting (who happen to be on the other side of the planet), so it sat for a year (which killed the 2nd battery). Then it lasted a few months after i got it back and the motherboard burned out...just turns on but eveything is black, Apple said they'd have to replace the motheboard, but they couldn't guarantee it wouldn't be replaced with a motherboard that had a recall on the graphics card killing motherboards, which only came with a 90 day warranty). So haven't bought another Mac, but with the audio world going Thunderbolt and Windows lack of support i'm not sure what to do. My current windows desktop is from 2005/2006 so it's time for an upgrade.
 

Kcatthedog

Hall of Fame Member
Agreed neither Mac or windows are perfect:) Anectdotally, in terms of what I have seen discussed here, in general, a lot more problems with Windows running apollo. There was the fw problem with Mac but when I switched to tbolt: bullet proof performance. THE USB twin seemed problematic or maybe that is just what was reported here ? When peeps use the right mb apollo experience with Win seems fine , once they get their settings dialed in ?
 

TimTee

Active Member
Hopefully windows side will settle down with good support for usb-c/tb3. I like quite few others I’ve spoken to will likely migrate to windows down the line. I’ve had similar problems with MBPs like the other poster, and apple’s response was quite simply appalling. I was lucky to have one MBP replaced with a later one that didn’t seem to be plagued with the dreaded graphics card issue only because the MB fried 3 times very quickly and it was under warranty, but quite frankly Apple had major issues with graphics chip frying for far too many versions of their MacBook pros. 3 of them for me... I haven’t forgotten. It’ll depend on what they offer pro wise when it’s time to upgrade.

DSP wise it depends on what someone needs. I’m good with my quad for now, I suspect many are, I run channel strips going in, if I wanted to run an eq and or compressor I likely could. But I get the frustration, I don’t know why you can’t share cores and more.

But someone said they are more interested in reliability than more features. I couldn’t agree more. If something doesn’t work reliably for my sessions then I have to find something that will.
 
Last edited:

scratch17

Venerated Member
[MENTION=35079]drsax[/MENTION], I appreciate your opinion.

I agree that Apollo is rock solid stable on my Mac. If it weren't I would have sent it back soon after I bought it. I also know from personal experience that MOTU makes rock solid interfaces too. Stability is a prime requirement in an interface. So why give UA extra credit for stability?

I previously had a 192 i/o interface which could route to any input to any output... and rarely used that feature.
My issue is not with the somewhat limited routing in Console 2. It is with the limitations on how plugins are allocated DSP resources. Those restrictions limit where, how many and which combinations of plugins can be used.

The maximum DSP available per channel is one chip . This is an amazingly restrictive limitation.

Here is a real world example of how drastic the affect of these limits becomes. You have an Apollo 8 Quad. You are recording an acoustic guitar part in mono. Nothing else is being recorded in the session.

You want to run it through a channel strip to get the Unison microphone preamp and do some EQ. Maybe you need a bit of compression, too.

The acoustic guitar you are using still sounds a bit thin. Better add Woodworks in the next slot.

And of course you want to place the guitar in the correct spot in a great room. I have a small one room studio so I always slot the Ocean Way Studios plugin on my acoustic guitars. I also like the integrated reverb that matches the room's space.

So I put the SSL E Series Channel Strip in the Unison slot. My DSP goes to 41.8%. Then Sound Machine Woodworks goes into the next slot. DSP is now at 78.2%. When I try to add Ocean Way Studios I get a warning that I am unable to instantiate it because I have exceeded DSP load limits.

In the meantime, I am sitting with three DSP chips at idle. With the restrictions of one chip per channel, the additional chips I paid for when I bought my Quad are about as useless as tits on a bull. That is just plain wasteful. Note that this example does not even account for the DSP usage required to run the system.

Can anyone on this forum really state that they bought their UA hardware because of the quality of the interface and not because they wanted access to UA's world class plugins?

I agree with you drsax when you say:

I think we live in a time where our options are incredible. Each manufacturer and platform has its own benefits and limitations.
We do have a plethora of great choices when it comes to our audio interfaces. If interface quality and features were the only issue for me, I would sell my Apollos and buy a MOTU 1248 and an 828ES. The converters are the same, and for the cost of one Apollo 8 Quad, I'd have 6 mic preamps, 16 line inputs, 4 channels of SRC S/PDIF coax, 16 channels of ADAT at high sample rates, more than twice the outputs, more flexible routing, and AVB.

And with two Macs and a PC, I could combine the power of two computers to make my setup more powerful through AVB.

I can't say from personal experience whether audio quality of the MOTU interfaces is as good as Apollo 8's audio quality because I have not tried one of the new MOTUs. I'd bet that they'd be really close though. Note that the retail price of the two MOTU interfaces is the same as one Apollo 8 Quad.

I am selling my two Apollos (SF Quad and Apollo 8 Duo). I figure I can get about $2500 net for them. I will buy a new Apollo 8 Quad with the free Quad Satellite because I love the plugins. That in no way means that the DSP restrictions are not a huge negative for me.

To accent this I will also point out that if the Apollo system was able to share DSP across devices, I would be considering purchasing two Apollo 8 Quads. That would give me 8 chips for tracking without restricting how DSP would be allocated.
 

ChrisMilne

The Originator
Moderator
Unfortunately my MOTU 896 (which i've barely had a chance to use over the years) is dying for no reason (the lcd, which i can live without, but also making weird noises sometimes when starting up), so i may have to make a choice sooner than later about a new PC and an Apollo. I priced out a few pc options on PC Parts Picker 9 months ago, and the prices have gone up, not down which is crazy). I had assumed that all PC's would be TB3 equipped by now after they started to trend that way (and Intel's licensing structure is supposed to have dropped), but they are getting even harder to find on new motherboards. Hoping for new Mac Mini's...but after 3 years without an update, i think they are done.
 

JamesNorth

Hall of Fame Member
Totally perfect Z270 Gigabyte board (with Alpine Ridge Card) running OS X 10.12.6 here with the full UAD suite of devices.

I think PC hardware is obviously much more flexible but there's always been something about the stability of OS X and audio interfaces (in my experience).

I did the Hackintosh thing several years ago when there was a big hole between G5 and Intel Mac Pros and it's never let me down.

With respect to the OP and topic - I survived for ages on UAD-2 with just a Quad card (before switching to an all Apollo setup) and don't quite understand the issue with the limitation thing at all.

I'd say that if you only use UAD plugs in your DAW and you load up your Apollo channels with traditionally DSP hungry things (like reverbs) you're asking any system to do a lot.
 
Last edited:

mark714

Active Member
I'm with you, scratch17- I hope they get this sorted. DSP allocation and stranding DSP is a problem. Three Apollos and two Satellites here, not much room to grow. It is a good platform with great potential, but even 5+ years in it is not yet fully realized.
 

Gerk

Venerated Member
Sorry in advance, serious geek alert here. If you don't want to know about the differences between serial and parallel processing just skip this post now ... but if you're curious as to the mechanics behind these sorts of limitations read on. I'm going to massively simplify things here (I will try to keep my instructor hat off here, but having taught this material before it will be hard!)

The thing is that what you are proposing seems like it's not complicated, but it is. More so than most can even imagine. This is the same problem that's faced pretty much all forms of digital computing since day one and aside from making bigger and faster processors that can push through the serial information quicker there's no easy solution -- and this doesn't mean more processors, more cores or more additional devices with those things, this means one single core of one single processor that is faster and able to push more data through the pipe faster. This is not limited to DSPs for audio processing and it is not limited to UAD, this limitation applies to pretty much every piece of processing silicon in existence. We've hit some serious physics based walls in terms of making these processors actually go faster which is why multi-processor and multi-core stuff came along in the first place. It's not the ideal solution to the problem but it's the only one we have.

So this single stream of processing is called serial processing. It uses an approach called FIFO -- First In First Out. It's the easiest and fastest way to get things done, a bit comes in, gets processed, and goes out again, repeat as necessary and that's the whole procedure and there's nothing further to it. Easy peasy to control and nothing to slow you down. This is how we get that < 2ms latency from the Apollo devices, because it can send each single stream of data (in our case audio) through a single core of a single DSP.

But now what you're asking for is called parallel processing. That means that FIFO can no longer apply which means you have to add a TON of overhead into the whole situation here. You have to split up this single stream of data into tiny bits, track them all, know what all of the available cores across all of the DSPs are doing at all times (so you know which one to send the next bit to), you need to schedule all of these bits into the best order you can to make sure they get done as efficiently as possible (don't forget latency), you need to have all kinds of checks in place to ensure that the bits you sent got to the other hardware because now you're adding in other kinds of busses here like thunderbolt or USB or Firewire that are thousands of times slower than staying on a single chip and are dependant upon other things to control the flow of those, you have to know that they got processed correctly, you have to know that they made it back to whatever is being the "master" type controller and scheduling all of this stuff ok (and you do want to make sure that a single thing is controlling everything here otherwise you're making this exponentially more complex yet again), then you have to read that bit and figure out where it needs to get inserted to go back into that serial stream of data (our audio). And this is a very, very simplified version of what really happens.

So now that we're doing things that are multitudes more complex as opposed to FIFO (which requires zero effort) there are other things to consider because this will absolutely not work in realtime due to the nature of it all. What happens when a packet gets lost or held up or just simply takes a bit longer than the packet before it did? You need to stop sending all of your output until you get the appropriate data back so that you can insert things into the correct order, hence latency, hence buffers.

When you can control the timing of all of the output then a parallel type solution can work (within reasonable limits) because if one of the parallel processes takes more time to complete then you just hold up all of the I/O to wait for it because you have a bit of a buffer -- that's why it exists. So that the master controller of all of this chaos can reassemble all the pieces and have it all come out correctly in the data stream. The bigger the buffer the more time the system gets to reassemble the bits at the end so they come out right, which also means the more processors and cores you can have in play across multiple devices that cross outside of your own controlled hardware bounds. Because you've got time to spare before you need to deliver that audio stream.

In mixing terms this means it's possible to use a bunch of different threads on different processors or cores to do the work, but at a price. Latency. Not just the potential for it but real, measurable and unavoidable latency because it takes time to do things. And you're stuck at the speed at which we can physically jam those electrons through the silicon + all the time and overhead it takes to keep track of this controlled chaos + all the round trip time it takes to get to other devices and back again, etc. And when you're talking about sending information across a bus -- any bus (even fast ones like Thunderbolt) you are still talking multitudes slower than keeping that data within a single custom silicon processor (i.e. a SHARC in this case). And I'm sure that UAD is pushing the limits of the SHARC processing to get those single serial data streams pumping out in < 2 ms right now staying within the bounds of their custom silicon ...

So this is also the exact reason why you can't go from custom silicon based processing to native either, no matter how fast your CPU is or how fast your bus is, or how fast your ______ (whatever creative option people come up with next) is.

And sorry if this was a little over the top and/or if it doesn't make as much sense as it should -- I'm kinda hopped up on cold meds right now :(

*end teaching rant*
 

shimel

Venerated Member
Thanks for your input Gerk !
As far as I understand, that means UA has no other choice than propose a solution to make more DSP (I mean really more ! ) working in parallel ( and so overpass the actual 8 DSPs limitation in Apollos ) while pushing the price cheaper because the customers don't want to give more more money for old tech's DSP than current generation Intel monsters ....
It's maybe the right time to leave the old Sharc's road or take a new path ? or make bunch of Sharcs working together around an ARM's core that can manage the data streams ?
 

klaatu

Active Member
They announced new sound card called "Arrow" today at gearslutz but now thread is missing? I did not see what kind of DSP is inside...but i wonder what do they have under the table.

I am almost sure they will migrate to FPGa as being mentioned on this forum last year.
 

Ashford

Venerated Member
There are two ways that the DSP can handle more plug-ins, parallel processing or larger DSP chips. I do not think that the Apollo DSP is currently configured to handle parallel processing, or UA would have already implemented it and UA are already using the largest available Analog Devices SHARC chips. I do not think that it will be possible for UA to increase the DSP available for real time recording in their current Apollo range. There is way to increase DSP for live recording, but it comes with a latency disadvantage. In Console, send the input channel that is being used for recording to an Aux and then send the Aux to a Cue output. You can then insert more plugins on to the Aux channel.
 
Last edited:

DanButsu

Administrator
Forum Admin
Moderator
Gannon told me in a Skype chat that the sharcs are not going anywhere, any time soon! It’s a stable reliable system. He also said that there was an “issue” with the dual-core chips, so it’s unlikely we will see them soon.
 

Gerk

Venerated Member
Thanks for your input Gerk !
As far as I understand, that means UA has no other choice than propose a solution to make more DSP (I mean really more ! ) working in parallel ( and so overpass the actual 8 DSPs limitation in Apollos ) while pushing the price cheaper because the customers don't want to give more more money for old tech's DSP than current generation Intel monsters ....
It's maybe the right time to leave the old Sharc's road or take a new path ? or make bunch of Sharcs working together around an ARM's core that can manage the data streams ?
No. SHARCs are not the problem here, it's a serial vs parallel issue. Making a "bunch of SHARCs work together with an ARM core" is exactly the opposite of a solution. You probably need to re-read my post (it's a complicated issue).

I'm not qualified to tell you what UA's options are here, just wanted to point out that realtime == serial processing and there's physics based physical limits happening there. The solution is to break the laws of physics and make clock speeds double or triple overnight (not gonna happen) or let others with a MUCH higher pay grade than me keep working on the solutions. UA has some pretty killer people at work at it already and I have faith in them!

I just wanted to point out that while it seems like a simple request it's not. And it's not just a limitation with UA's platform and it's not a limitation with their chosen custom silicon or SHARCs, but it's the same problem facing the entire computing industry. Frankly I'm completely blown away with UA's offerings as I know how complex this stuff can get. There's a reason why they are the only players in this game right now! If it was easy everyone else would be jumping on the bandwagon.

Also worth pointing out that things that chip makers have tried to do to resolve this over the years sometimes come back to bite them in their behinds ... like this whole current issue Intel and ARM have with Spectre/Meltdown. It's directly related to this exact issue -- they do predictive branch processing to try and stem potential bottlenecks in the whole management/scheduling end of things and worry about some of the other bits after the fact ... and it turns out that this is a very very bad idea as it allows things to get processed that it shouldn't have (we won't get into that whole discussion here).
 

Gerk

Venerated Member
Gannon told me in a Skype chat that the sharcs are not going anywhere, any time soon! It’s a stable reliable system. He also said that there was an “issue” with the dual-core chips, so it’s unlikely we will see them soon.
That's good to know (that SHARCs are not going anywhere soon). The dual-core chips probably try and implement a hardware based thread management solution -- quite a few of them are trying that these days as I guess it's the next logical step to the parallel processing issues I mention above -- but it comes with a price and while it might work ok for some usage for realtime it's probably a no-go. At least that would be my guess based on my previous rant :)
 
UAD Bundle Month
Top