A Programmer's Perspective on the AAX Transition + Q&A
This was posted on the Daw-Mac list recently. Frank Filipanits generously gave me permission to share it here. I think his (2) posts are required reading for everyone:
Transition to AAX: A Real Programmer's Perspective Quote:
|
Re: Transition to AAX: A Real Programmer's Perspective
AAX DSP/Native vs. TDM/RTAS
Quote:
Quote:
Quote:
|
Re: Transition to AAX: A Real Programmer's Perspective
First, let me thank Frank for making such an in-depth post about what AAX really is and why we we had to tackle a new plug-in platform. I was tempted not to reply at all because his comments are so comprehensive, but I decided to post to validate his comments as well as provide any additional information I could provide about AAX, both the reality of what we've shipped as well as some of the back story that drove us in this direction.
AAX is truly just a plug-in specification, as Frank mentions. Early on, we were really just trying to add HDX support to the legacy plug-in spec. (I'll admit, back then it had a different name, and a MUCH different architecture to just accomplish that goal) But when we started to look at the feature requests the plug-in developers were asking for to create amazing new plug-ins for all of you guys and our internal roadmap of products we'd like to create, that old plan just didn't make a lot of sense. This infrastructure had been growing by bolting on features for 17 years and it just wasn't easy to add even seemingly simple features to the SDK (Software Development Kit) anymore. Not to mention all of the 64 bit issues that come along with 17 years of development... So, about a year ago we decided to take a more aggressive stab at setting ourselves and our third party plug-in developers up for the future. We looked at the backlog of feature requests, we looked hard at our road-map, we spent a lot of time studying all the intricacies of our current formats (RTAS and TDM), and we started designing AAX. We had several really talented teams working on this from multiple angles to make sure it satisfied all of our requirements and was simple. (And I don't mean limited in features, I mean simple to develop for, which hopefully in the long run leads to fewer bugs.) We had to preserve preset compatibility between formats. We had to make all of the new types swap out seamlessly with TDM and RTAS when you round trip your sessions. We had to make the porting process for plug-in developers as straightforward as possible. We needed to support complex engine interactions with both real time plug-ins and non-realtime (AudioSuite). We needed to make sure that new plugs-in mixed in with legacy plug-ins (and not break those, by the way). The list goes on and on and I just can't tell you all how proud I am of the teams that worked on this project. There's the story, or enough of it at least... So, where are we now? Truthfully. We've shipped AAX, which solves all of the legacy issues that were preventing us from getting to 64 bit, which I could go on and on about. It also provides a much simpler path for plug-in developers to create DSP accelerated plug-ins, which is important in a world where DSP isn't always needed and developers may not be as motivated to do a TON of extra work to develop for that platform. (It's still extra work for them, so please be understanding) We have a design that is modular that will enable us to do some pretty darn cool features/products in the future. (Trust me, we're just getting started with this...) We've incorporated a ton of feedback from plug-in developers that will enable them to make cool new products. In fact, I think we closed out 14 of the top developer feature requests the day we shipped AAX. I'm personally looking forward to what these guys can do with the new platform. And finally, with the incredible support of our third party plug-in developers, we're launching PT10 with shipping third party AAX plug-ins (Native and DSP) from some companies as well as firm commitments from a ton of others. All of the feedback they provided during their development process was critical in the refinement of AAX. Hopefully, they all feel like this platform is as much theirs as it is ours. With their continued efforts and feedback, we'll be able to make it even better. We're still polishing up the last details on HDX, so I might not be able to answer questions quickly, but I will follow this thread and answer any additional questions as quickly and candidly I can. Thanks again Frank for dispelling the myths and giving your very candid opinions on all of this. Dave Tremblay Sr Engineering Manager - DSP Group Avid |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
1) The communication channel between the Host CPU and the TDM Cards. 2) The drivers all have to be fixed for 64 bit. 3) All plug-ins would have to be rebuilt to communicate with the DSPs. 4) All plug-ins would have to be rebuilt to remove non-64 bit safe graphics frameworks on OSX. Actually, the list is quite a bit longer, but suffice to say it's a ton of work for both us and for 3Ps. Dave |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Additionally, an HDX system still has all the benefits of Native in that you can run a ton of AAX Native plug-ins up on the host AND get additional power (and low latency) down on the DSP cards. So, that all sounds like marketing speak, and I apologize for that, but it's true. Many of our customers demand a high reliability and/or low latency solution, and these cards are designed to do that. I will add a fun little technical tidbit which might make people think a little. So, Native cores have all this power. We've all seen the numbers of the ridiculous FLOPS and other specs, but one thing to keep in mind is that modern processors all have a cache because accessing memory is kind of slow. The cache isn't that big and worse yet, that cache (or much of it) is shared between all of your cores. In the audio world where you have a ton of data from your audio tracks to your plug-in states, the cache becomes a rather precious resource, and cache contention can become a major bottle neck that hobbles the real performance of your native cores. This can be mitigated somewhat by larger buffer sizes, but as you shrink that down, this cache problem starts to become pretty major as every process has to hit memory directly. Now, what if each of your individual cores had it's own memory and it's own cache and didn't have any contention with other cores? That would be cool, right? Well, look at the HDX card. It has 18 individual processors with their own memory and cache. No contention. These chips, while seemingly less powerful if you look at the raw numbers can be run much closer to the bleeding edge. Dave |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
AAX DSP also has 32 bit floating point data path, so it shares that higher precision, which wasn't true with TDM which was 24 bit fixed point. Because the data path and processing code can be identical between AAX Native and AAX DSP, you can use the full precision inside your plug-in without making a compromise to have your plug-in sound the same between Native and DSP. For an individual plug-in, I guess the answer is yes, but it all depends on how the plug-ins are written. For the system as a whole, things got a whole lot better because all plug-ins are 32 bit floating point precision and won't likely have internal clips or clipping between the plug-ins for that matter. Some of our plug-ins use 64 bit double precision internally for higher sound quality in the processing code, but I believe 32 bit floating point is more than adequate for the data paths between plug-ins and it makes the system perform much better because you don't have to move twice as much data (memory) around. |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Transitions like this are very difficult to do, but we're convinced that this transition plan was the right thing to do for our customers and third party plug-in partners. Dave |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Quote:
Since multi-core is obviously becoming the future, we are and will continue to be looking at even better ways we can intelligently use all of your cores. Dave |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Dave |
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
2) I would say that dither is not needed between plug-ins in a 32 bit floating point signal path. Floating point has fundamentally different numerical representation that makes use of dither awkward. Dither is really intended when you are reducing the bit depth to a final integer representation, like right before you go to your converters. Since all plug-ins are now 32 bit signal path, DSP and Native, you shouldn't need dither between any plug-ins, only before you hit your converters. 3) Good question, and not simple to answer. I'm not positive, but I believe the native mixer stayed the same. For the HDX Mixer, it has obviously been rewritten for the new DSPs and now uses 64 bit floating point accumulators internally, which is a significant improvement. 4) Not necessarily, the signal quality in and out of the plug-in are both 32 bit floating point. I will say that in our efforts to move over to AAX, we took some opportunities to modernize pieces of our code, internal to the plug-ins, which could/will make them sound better and perform better. That said, there is a benefit that there aren't all these conversions back and forth between 24 bit for TDM and 32 bit float for RTAS. Dave |
All times are GMT -7. The time now is 07:27 PM. |
Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com