Transition to AAX: A Real Programmer's Perspective

[Incognito]

Originally Posted by mike connelly

Didn't Frank used to work at digi in the mid to late nineties?

He certainly did: Frank was responsible for authoring the DSP and GUI for

• DPP-1 (that later became the DigiRack "Pitch" TDM plug-in)
• The Procrastinator
• DINR TDM 2.0

[rockridge]

Originally Posted by reichman

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.

So RTAS and AAX have identical sound quality?

[DaveTremblay]

Originally Posted by jeremiahmoore

My question is: Besides the reliability and latency factors (a big issue for the high-end market, where downtime is way more expensive than hardware) are there other technical decisions that went into continuing on the DSP path vs. abandoning it for a native-only system?

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

[DaveTremblay]

Originally Posted by rockridge

So RTAS and AAX have identical sound quality?

RTAS and AAX Native have the same audio precision coming into and going out of the plug-in, 32 bit floating point.

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.

[DaveTremblay]

Originally Posted by LukeHoward

Probably. But going 64-bit at the application level also implies other changes: for example, the Carbon UI framework on the Mac is no longer available. Better for all to address both issues in one update.

It also has to be removed from all plug-ins, which we've done in the AAX infrastructure, but plug-in developers might still have to migrate to newer graphics frameworks. By releasing PT10 with AAX support we are trying to give developers more time to do this work without putting customers in a position where they have to choose between their existing plug-ins and the new ones coming out.

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

[jeremiahmoore]

Dave - thanks for the great technical depth on this stuff.

Are you able to speak to the "legacy" (i.e. HD-era) interface question? Not sure if this is your department, but What technical issues are behind dropping support for legacy interfaces? Is this about technical architecture, or simply about wanting to narrow the grid that testing and support are obligated to handle?

-j


Sent from inner space

[DaveTremblay]

Originally Posted by jeremiahmoore

Are you able to speak to the "legacy" (i.e. HD-era) interface question? Not sure if this is your department, but What technical issues are behind dropping support for legacy interfaces? Is this about technical architecture, or simply about wanting to narrow the grid that testing and support are obligated to handle?

Unfortunately, I don't know much about that part of our code, so I can't really answer in an informed way and I shouldn't speculate. Sorry.

Dave

[jeremiahmoore]

Two other, more DSP-related questions:

1) in HDX, running RTAS or HDX-Native plug-ins on auxes or masters, will we incur a similar voice and latency cost as we see now? i.e. running RTAS reverb on an aux, without ADC on, is like inserting a predelay, as the audio streams out of the DSP mixer, into host processing, and back into the DSP mixer.


and 2) native performance: clock vs. cores

Last year I did a bunch of research into native processing, and whether clock speed or number of cores was the better advantage.

The answer came down to: Clock speed is more important for now.

i.e. a 6-core 3.33GHz Westmere would perform better (presently) than a 12-core 2.93GHz, for Pro Tools anyway.

Any thoughts on what to expect when we move into the next generation of app? Might PT be fully multithreaded? Perhaps it's speculation


-jeremiah

[DaveTremblay]

Originally Posted by jeremiahmoore

1) in HDX, running RTAS or HDX-Native plug-ins on auxes or masters, will we incur a similar voice and latency cost as we see now? i.e. running RTAS reverb on an aux, without ADC on, is like inserting a predelay, as the audio streams out of the DSP mixer, into host processing, and back into the DSP mixer.

If I understand you correctly, yes this is still true. That has more to do with the fact that the host system can't run at the same latency as our cards, so we have to buffer up data to move it back into the host and buffer it up to move it back. If the host OS could run a 1 or 4 sample buffer sizes, we might not have to do that. :)

Originally Posted by jeremiahmoore

and 2) native performance: clock vs. cores

Last year I did a bunch of research into native processing, and whether clock speed or number of cores was the better advantage.

The answer came down to: Clock speed is more important for now.

i.e. a 6-core 3.33GHz Westmere would perform better (presently) than a 12-core 2.93GHz, for Pro Tools anyway.

Any thoughts on what to expect when we move into the next generation of app? Might PT be fully multithreaded? Perhaps it's speculation

Your clocks vs. cores results are actually a little surprising to me, but maybe I can give some additional insight into how we use the cores and such. The Native engine is multi-threaded and not just for processing, but for things like control updates and stuff. Whether you can efficiently use all of the cores might really come down to your session though. If you run plug-ins in serial, like on a single track from insert to insert, multiple cores can't buy you much because we can't process those plug-in in parallel. If you have multiple tracks, now we could potentially processes in parallel, right? In most cases, yes, but there are some other dependency rules that come into play when you use particular bussing schemes and such. I remember being in a discussion a while back where we came up with a worst case session bussing scheme which would prevent the system from ever using any other cores... So, in some sessions, you might see the load balancing work quite well. In others, maybe not. I'd guess that other Native DAWs have similar limitations unless they add latency to break the dependencies, but I don't really know for sure.

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

[raw]

Which model TI DSP will be used in the HDX cards?
Is it one of the TMS320C67xx FP DSPs? Perhaps the TMS320C6727B (@350MHz)? Or something else?