AAX DSP/Native vs. TDM/RTAS

Posted by: Nathaniel Reichman on Sun Oct 23, 2011 6:51 am (PDT)

I was at AES on Friday, and despite some controversy over high upgrade prices, and developers dragging their feet, it was completely evident that Avid has put a tremendous effort into Pro Tools 10. I used systems there, and they were snappy and powerful. The plug-in menus on the demo rig showed that there are separate "DSP" and "Native" menus, similar to RTAS and TDM now. However, Avid product specialists where quick to point out that the underlying sonic code is identical, so hopefully developers won't have a hard time making both versions of the new AAX plug-ins (would love to hear from Frank Filipanitis here).

Posted by: Ben Cox on Sun Oct 23, 2011 6:56 am (PDT)

What I want to know is, does it also make it so that developers won't have a hard time making plugins that only work in Native or DSP modes, and thus charging separately for them? I'd love it if _all_ AAX plugins would run in Native or DSP, and it was not possible for a plugin vendor to charge separately for DSP vs. Native.

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