Transition to AAX: A Real Programmer's Perspective

[jeremiahmoore]

It was stated elsewhere that the RAM cache feature uses a separate process from the pro tools app, and can thus access a full 64-bit memory space today.

Also, user reports are of being able to load up a full 16gb session and the like.

Where you Can't access that memory space for now is in pro tools hosted virtual instruments.

-jeremiah


Sent from inner space

[TDigi]

Originally Posted by jeremiahmoore

Where does FPGA come in on HDX? Is it used for routing? Summing?

Used for routing. A way to route audio @ 32-bit between the host and the DSPs, as well as from DSPs to other DSPs (and other cards) with super low latency (just a couple of samples).

What dither is (or isnt) applied in the new mixer, and where? I gather there is none internally to the mixer (unless within a particular plug-in). Is there automatic dither on output to I/O or files?

No dither applied in the new mixer, or automatically (unless you enable it in AudioSuite processing, via the Preferences dialog). You can apply dither with certain plug-ins like Maxim.

-Toby

[DaveTremblay]

Originally Posted by Marsdy

Altiverb can take up a huge number of chips on a TDM system. The longer the reverb time, the more chips get used. I understand this was due the limited amount of RAM available to each chip on a TDM card. Has this improved/changed with HDX?

Definitely improved. There is now 16MB of RAM per chip. But the timing of accessing RAM among other things has changed, so I'm not sure how that will impact Altiverb.

Dave

[Capta¡nHook]

Thanks for all the info and your time Dave. Something that caught my attention was from Frank's posts:

"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."

Reading that gives the idea that in the past matching bit-for-bit WAS practical, but now won't be. Doesn't that go against the idea of "This new audio plug-in format gives you better workflows and sound parity when sharing sessions between DSP-accelerated and native-based Pro Tools systems."...?

Thanks. :)

[DaveTremblay]

Originally Posted by Capta¡nHook

Thanks for all the info and your time Dave. Something that caught my attention was from Frank's posts:

"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."

Reading that gives the idea that in the past matching bit-for-bit WAS practical, but now won't be. Doesn't that go against the idea of "This new audio plug-in format gives you better workflows and sound parity when sharing sessions between DSP-accelerated and native-based Pro Tools systems."...?

That was one of the few things from Frank's post that I didn't understand. In the past, RTAS and TDM rarely had the exact same signal characteristics just due to the fact that the code is different (entirely) and the numerical representation is completely different. I can tell you that some of ours are significantly different.

In AAX, we should be in a better position to provide that, not worse. There is one thing that Frank may be referencing and that is the fact that the internal numerical precision in floating point units for the two chips (Intel and TI) are different. This can cause rounding errors that might make things not perfectly identical. We've definitely seen some of this in our own plug-ins and there are ways to make them "cancel" perfectly in some cases and in other cases it isn't worth it due to performance penalties and such. And in those cases, we do extensively listening tests to verify that these things sound identical.

A bit of extra info here that I found fascinating. It turns out that the optimizing compilers between OSX and Windows are different as well. OSX tends to use more vector instructions when optimizing the code, which also have different behavior than the scalar floating point unit. This means that sometimes OSX and Windows don't cancel. I mean, seriously, the worst case effects are like 100dB down so you couldn't likely hear a difference, but I sure thought it was interesting...

Dave

[airon]

Let's not feed the nervous signal path trolls under the snake oil bridge.

Andy of Cytomic is commenting on his AAX DSP development of The Glue over at Gearslutz atm. He's optimizing the DSP routines atm. He also commented on the 4 samples latency that DSP systems offer, which sure is a sweet feature.

Thanks for all the great insights in to the platform. Probably the best and most positive thread here right now.

[Capta¡nHook]

Thanks again for the info Dave, did seem odd indeed. Cheers. :)

[daeron80]

Originally Posted by airon

Let's not feed the nervous signal path trolls under the snake oil bridge.

Hey! I'm gonna make you pay extra next time you cross my bridge for that comment, buddy!

[[email protected]]

Excellent post Frank. You said exactly what I assumed was the situation, and what needs to be clearly understood in the community. Thank you for taking the time to write this post.

[rockridge]

Originally Posted by DaveTremblay

The compilers are really good if you know how to give them the latitude to optimize and quite frankly the chips (even the DSPs now) are ridiculously complicated with all their parallelism.

Dave

Parallelism... meaning routines need to run together...

C++ can handle many thing at once!
What an undertaking!