Avid Pro Audio Community

Avid Pro Audio Community (https://duc.avid.com/index.php)
-   Pro Tools 10 (https://duc.avid.com/forumdisplay.php?f=91)
-   -   Transition to AAX: A Real Programmer's Perspective (https://duc.avid.com/showthread.php?t=310093)

reichman 10-25-2011 08:53 AM

Transition to AAX: A Real Programmer's Perspective
 
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:

Quote:

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.

-Frank

Frank Filipanits
Cool Stuff Labs, Incorporated

reichman 10-25-2011 08:54 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Quote:

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).
Quote:

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.
Quote:

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

Frank Filipanits
Cool Stuff Labs, Incorporated

Bob Olhsson 10-25-2011 09:03 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
This really ought to be a sticky!

TOM@METRO 10-25-2011 09:27 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Quote:

Originally Posted by Bob Olhsson (Post 1852075)
This really ought to be a sticky!

I fully agree. This puts a healing perspective on the confusion and misunderstandings plaguing this forum.

originalscottyg 10-25-2011 09:51 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
+1

Quote:

Originally Posted by Bob Olhsson (Post 1852075)
This really ought to be a sticky!


bashville 10-25-2011 09:58 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Quote:

Originally Posted by corp (Post 1852084)
Very good post.......

Would Waves be one that is dragging there feet on AAX.........

I also have a feeling that AAX using dsp version that cause companies to take more time to develope will push cost onto the user......... business as usual... :cool:

Funny this post somehow prompts an immediate "attack Waves" response, when if anything it demonstrates the difficulties plug manufacturers are going to have waltzing around this thing. Mercury has what, 130 plugins? Maybe 7-10 times more than most other companies? It's been two business days post-AES and Waves doesn't yet have a big free package wrapped up in a bow for everybody to download---!

It would be nice, though, to see some statement or reaction from Waves or McDSP or whoever. Like "we just found out about this, preparing a statement" maybe.

I remember when Logic made the big plug-in changeover. They told nobody until the big announcement. So BFD basically said it was news to them also, we're all on the same learning curve. Possibly ProTools held this close to their chest as well....

Farmer Dave 10-25-2011 09:59 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Quote:

Originally Posted by Bob Olhsson (Post 1852075)
This really ought to be a sticky!

+1

Thanks for posting this. I share this perspective on the product changes, though I'm not a developer.

Darryl Ramm 10-25-2011 10:00 AM

Hire that man to run Avid Marketing!

Darryl

John_Toolbox 10-25-2011 10:11 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Finally, a thread about PT10 that's not a complete waste of time to read!

A+++++++++++++++

mike connelly 10-25-2011 10:13 AM

Re: Transition to AAX: A Real Programmer's Perspective
 
Didn't Frank used to work at digi in the mid to late nineties? I thought I remembered seeing his name in the Pro Tools credits back in the day.


All times are GMT -7. The time now is 06:52 PM.

Powered by: vBulletin, Copyright ©2000 - 2008, Jelsoft Enterprises Limited. Forum Hosted By: URLJet.com