Today I happened to revisit the thread on the DUC entitled Transition to AAX: A Real Programmer’s Perspective, and in the light of the conversations and observations here and elsewhere, makes for some very interesting reading, especially in the light of the debate as to how easy it would be to take an AAX Native plug-in and convert it to an AAX DSP plug-in, which of course has been at the core of the whole Waves AAX discussion as well as a number of “off the record” conversations with developers who are not finding it as easy as the Avid Sales talk implied.

This isn’t going to be a short post but I hope folk will find it helpful to bring out some of the comments that have been made since PT10 was released that maybe have been lost in the noise. So what follows are some selected posts from this thread starting with the posts that started the thread from Frank Filipanits at Cool Stuff Labs but formerly worked for Digidesign as an in house plug-in developer so is well qualified to talk on the issue.

There’s a lot of almost-correct or sort-of-right information floating around regarding AAX, RTAS, and TDM. I’d like to try to set the record straight about a few things.

Unified AAX architecture:

The AAX spec strives to unify development so that the same algorithm can run natively or with DSP hardware acceleration on the new “HDX” TI-based floating point DSP cards, but there will remain a distinction between AAX Native and AAX DSP, with some (mostly third party) plug-ins only supporting one or the other. While Avid appears to intend to offer all of their plugs in one version only that runs on both, it is quite possible to create a plug-in that is either AAX Native only, or AAX DSP only.

Bit depth vs. internal processing:

There seems to be much confusion regarding how bit widths apply to different aspects of plug-ins.

TDM passes audio around using a 24-bit fixed-point pipe. Internal processing can be 24 bits, 48 bits, 56 bits or more. I lost track of what the mixer uses but it is very, very large.

RTAS passes audio around using a 32-bit floating-point pipe. Internal processing can be 32 bits, 64 bits, 80 bits, or more. I don’t know what the native mix engine uses but again it’s very very large.

AAX also uses a 32-bit floating-point pipe to pass audio around, for both Native and DSP. Internal processing can be 32 bits, 64 bits, 80 bits, or more.

Application word size:

When folks talk about an OS or APPLICATION being 64-bit, what that refers to primarily is the maximum size of a memory pointer, which places limits on the maximum amount of memory an application can use. It has nothing to do with the size of the data streams, or how efficiently the CPU can handle 32 vs. 64 bit float operations. A 32-bit application is limited to directly addressing 4Gb of memory.

Whether a plug-in (or host) is “64-bit ready” or “runs as 64-bit” has nothing to do with the word size of the audio pipes between plug-ins, which may well remain 32-bit float. Even if the audio pipes between plug-ins are 64-bit, the internal calculations may still use 32 bit operations since they are considerably faster than 64-bit operations (regardless of whether the host app or plug-in is “32-bit” or “64-bit”).

Why a whole new format?

When the TDM spec was written in the early 1990’s, the state of the art was 68000-based Quadras running System 7 and hard drives in the tens of Mb. It had provisions for black and white monitors. RTAS was added as a branch of that spec, and Windows compatibility was grafted in. Quite honestly, it is amazing how long that spec lasted — through the transition from 68k to PPC, NuBus to PCI, OS9 to OSX, PPC to Intel. But facing continuing aggressive evolution of OSX and fundamental structural incompatibilities with operation in a 64-bit host application environment (among other concerns), it was time to rewrite the plug-in spec to meet the needs and capabilities of today’s and tomorrow’s systems.

Some question why Avid didn’t simply adopt AU or VST — a few simple reasons are these: AU is a mac-only spec, and VST simply doesn’t have the power and flexibility to do everything RTAS/TDM and AAX are capable of.

Believe me, I am less than thrilled that the 17 years of expertise, techniques, tools, and libraries I built around the RTAS/TDM spec are now as useful as COBOL. But AAX was a necessary move on Avid’s part, and not one they took lightly.

Personally, I think it is remarkable that Avid made PT10 a transitional product - one that runs BOTH the old (RTAS/TDM) and new (AAX) formats (with the one limitation that TDM and AAX DSP can’t coexist simultaneously). It would have been much easier to simply make a clean break with the old.

“It’s just a scam to make more money”: Some people seem to think third parties are dancing with delight at the opportunity to force people to repurchase their plugs in a new format — nothing could be further from the truth. This is a HUGE pain in the ass for third parties, and plug-in manufacturers are stuck between a rock and a hard place: they have to spend considerable money and effort to port their software to the new spec, because no one is going to continue to buy the old format. But on day one, the market size for the new format is exactly zero. And existing customers often expect to get the new version for free or close to it. It’s an unpopular, very costly exercise for third party companies.

It’s not unlike having an expectation that since you bought an 8-track of “Led Zep II” for $5 back in 1969, that Atlantic Records would have provided you over the years a new copy — at no cost to you — in LP format, then cassette, then CD, then DVD-Audio, then mp3, then SACD, then Blu-Ray….

So take a deep breath. Remember that the TDM//RTAS system you have today works just as well and is just as capable as it was last week, and no one is going to force you to stop using it. PT10+ and AAX have some real advantages moving forward, and when those advantages overcome the cost disadvantages for you, bite the bullet and upgrade. Just like you did going from 68k to PPC, or NuBus to PCI, or OS9 to OSX. And give your plug-in companies the benefit of the doubt; this change is hard and expensive for them too.

RTAS and TDM require two completely separate implementations due to the fundamental differences in architecture; RTAS is written in C or C++ in a floating-point environment, TDM is written in 56k assembly language in a fixed-point environment. While the GUI and “glue” code could be shared between the two, the actual processing code had to be written completely separately for TDM and RTAS. This made ensuring bit-for-bit matching and synchronization of changes difficult.

HDX changes the DSP hardware to a floating-point architecture and AAX enables the possibility of writing a single implementation of the algorithm in C that compiles to both the native and hardware-accelerated versions. Note I said “enables the possibility”. The realities of writing an algorithm for the constrained architecture and feature set of the HDX hardware and TI DSP makes it significantly harder than simply writing a plug-in to run on the host. There are many differences to factor, ranging from the straightforward (buffer size) to the complex (subtle differences in mathematical operations btw Intel and TI). And while simple algorithms can indeed run identical code on Native and DSP, many will still require some conditional code that is different on Native vs. DSP.

In general however, it should be the case that if the algorithm runs as AAX DSP it can run as AAX Native with little additional effort (though not necessarily optimized for speed). The converse, however, is not true… while it is MUCH more straightforward to adapt an AAX Native algorithm to AAX DSP than it was to adapt RTAS to TDM, there is still a considerable amount of effort and additional testing involved. So I expect we may see some companies elect to do plugs that run as AAX Native but not AAX DSP, at least initially.

I hope that we won’t see stratification in the market, with different price points for AAX Native and AAX DSP+Native; I think it is much simpler to have a single SKU and pricepoint for both. But the fact remains that making a plug run on the DSP requires additional cost, effort, and support — so it either gets baked into the price of a unified (DSP+Native) plug, or companies can attempt to recoup that additional cost only from those customers using the DSP side, while keeping the Native side a little cheaper.

I should also mention that attaining bit-for-bit matching between Native and DSP may no longer be practical for many algorithms…. expect to see manufacturers changing that bullet point to “matches to -96 dB” or “difference below -110dB” or something to that effect.

One last note regarding “developers dragging their feet”… the AAX spec was rolled out on a VERY aggressive schedule. Some vendors were able to refactor their plugs for AAX quickly, others were not. Avid provided a tremendous amount of support and encouragement to get as many third-parties ready for the roll-out as possible, but the amount of effort required varies tremendously from plug-in to plug-in. AAX also obsoleted a graphics framework used by some plug-ins, so vendors whose products were based on that not only have to refactor the processing code for HDX but also completely redo the UI code. Some companies are also better positioned to endure the painful parts of being on the bleeding edge, while others need to wait for things to settle out and stabilize before committing resources.

Again, while it is going to be a painful transition for many people — users and developers alike — I do believe that this is a good and necessary move for the future.

Frank Filipanits

Cool Stuff Labs, Incorporated

Now we have a number of posts straight from the horses mouth from Dave Tremblay who is Senior Engineering Manager for the DSP Group at Avid.  It is interesting to see that Dave has been prepared to discuss the technical issues of this debate. First a response to Frank’s posts…

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

Then on the subject of whether DSP systems would be needed now Native systems are so much better, someone from Avid under the DTS banner posted…

Here’s the mistake that those who aren’t in large production facilities make - native simply is not as fool proof, reliable and as predictable as DSP based solutions. 

Facilities like post houses, broadcast, film sound, etc have very different needs than your average studio owner or hobbyist. These DSP based solutions fill that gap.

Avid Audio Tech Support

Now a fuller explanation of the “is DSP needed?” debate from Dave Tremblay….

It is definitely true that Native systems are very powerful these days, which is why we released the HD Native product. It is quite possible that Native will work great for many people and meet their needs, but DSP based systems have a few advantages as you mention in your question. Low latency is a very difficult problem to solve in Native systems because the OS (windows or OSX) just isn’t designed to have ultra high priority threads that are the dominant priority. The newer audios specs like Core Audio are pretty good, and we can run 32 sample buffer lengths to get latency down, but it comes at a price. The system becomes much less reliable as you crank down your buffer settings. (thats why we ask you to turn them back up if you start glitching :) ) So, in a way, a Native system is a compromise between low latency and reliability. Our DSP systems are not. They are extremely low latency and rock solid because all those chips do is process audio.

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

Next Dave responded to to a question about Track Freeze etc., which as a possible new product he wouldn’t be drawn on, however he did make this point, which is very interesting, in the light of the debate as to why there aren’t AudioSuite versions of every plug-in, before moving on the issue of AAX Native to AAX DSP….

We overhauled AudioSuite when bringing it into the AAX world, so all developers have to do is add a single line of code to make their AAX Native plug-ins work as “AudioSuite”. This one line change tells the system that this AudioSuite processing is identical to the AAX Native processing. I’ll let you infer anything beyond that. 

While we’re talking about this, there has definitely been some confusion on this idea that AAX plug-ins just automatically support DSP acceleration. Frank mentions this in his original post, but it is not true. What we’ve done with AAX is create a modular little plug-in spec that separates the actual processing code from the “data model”, which is the piece of code that stores that actual parameters and such. While making this separation, we made it so the data model (again, the storage of parameters and conversion of those parameters into things the processing code needs to actually…process) doesn’t actually know where that processing code lives. It could be on a DSP, it could be on the Native CPU. We take care of that communication in an abstract way and route it to the proper location. Because that processing code is a tight little package that doesn’t need to know anything about the system its running on, we’ve made it pretty easy to just recompile that processing code for our DSP chips. The same exact code can be compiled for either processor.

Sounds simple enough, and in many cases it is, but that code won’t necessarily build and run in an optimal way for the DSP processors. I can tell you that, for our plug-ins, we can get them to build easily enough and even run right away from AAX Native (in most cases), but we go back and spend a decent amount of time really tuning them to run lean and fast on those DSPs so you guys can get your money’s worth out of these new cards. I would expect third party developers to have to go through a similar process (which is more work) to provide DSP accelerated versions of their plug-ins. 

It is WAY easier than TDM, but it still isn’t free.

Dave

Finally, from my selection, Dave responded to a question about Avid “encouraging” 3rd party developers to get a move on with AAX Plug-ins…..

I can certainly understand your frustration, but from a technical and business perspective, we can’t force third party plug-in companies to port to AAX. We don’t have access to the code nor any legal rights to it. What we do instead, is stay in contact with these companies and offer every little bit of help and encouragement we can. I would encourage you to reach out to these companies and tell them how much you’d like to see their plug-ins on HDX. Customer feedback is usually taken more to heart than feedback from a business partner.

Dave

So hopefully this long post shows straight from the horses mouth that, as we have said many times here, the Avid people at the coal face are genuine, hard working and honest people. None of what I have quoted here is off the record, it is all from

the post on the DUC

, but I found it very interesting to read in the light of the continuing debate, and for me it reinforces that Avid’s marketing and communications need a major overhaul and the sales and marketing spin needs throwing out and replacing with honesty. The information has been out there, this post was started in late October, very soon after the PT10 launch but the honest information from Frank and Dave has been lost in the noise from the responses to the marketing spin.