Avid Pro Audio Community

Avid Pro Audio Community

How to Join & Post  •  Community Terms of Use  •  Help Us Help You

Knowledge Base Search  •  Community Search  •  Learn & Support


Avid Home Page

Go Back   Avid Pro Audio Community > Pro Tools Software > AAX Plug-ins

Closed Thread
 
Thread Tools Search this Thread Display Modes
  #11  
Old 10-27-2011, 07:11 PM
TDigi TDigi is offline
Avid
 
Join Date: Jun 2004
Location: Colorado
Posts: 39
Default Re: Transition to AAX: A Real Programmer's Perspective

Yes, thanks Dave (and Frank!) for the informative posts - nice job I'll chime in on a couple of these from mr. daly and rockridge:

1) So I always assumed the signal was dithered from 48bits to 24 bits at the output of every plugin.... It is up to the TDM plug-ins themselves, and not all do this (many do internal processing at 48-bit, but don't necessarily add dither to go down to 24-bits). As this dither would be at roughly -144 dB it is often a better choice to avoid the extra processor cycles required. The "dithered" mixer will add dither at its final output stage on any given output path, but this only happens once at the 48->24 bit truncation.

As far as the native mix engine, it is not significantly different (in terms of signal path) with native PT10 systems. However, as Dave mentioned the new HDX system is different from legacy HD/TDM systems, one advantage being that audio is kept at 32-bit between the host CPU and the HDX cards, so you don't lose anything (as opposed to needing to convert to 24-bit fixed point when sending the audio signals to the HD/TDM cards).

Re: coding in different languages -- fortunately we are able to keep the PT10 system mostly to high level languages (C/C++) for both the host system and HDX/DSP plug-ins, although the processors are different for the new plug-ins so a bit of tweaking at a lower level is sometimes needed to get the very best performance. And of course FPGA coding is a different ballgame as well (!)

-Toby Dunn
Avid Engineering
  #12  
Old 10-28-2011, 08:25 AM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Sonopolis View Post
Could AAX plugs support off-line bounce?
I can't comment on future products or engine improvements as we are a public company.

I will say that 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
  #13  
Old 10-28-2011, 08:34 AM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by rockridge View Post
Are there routines that would benefit from 16 bit or even 8 bit?

Back in the Atari 1040ST days, since RAM and processing power was scarce, I heard that programmers would code in multiple languages.

Using the most efficient wherever they could.
That always impressed me.

Is that still necessary these days?
Not really. There are ways to make those types super fast if you use SSE instructions in the processor. Things like this are done in the graphics world for instance, but for Audio, it isn't really worth the tradeoffs. 8 bit color is fine. 8 bit audio sucks. (unless you're going for that sound of course) There are also ways to use SSE for floating point and double floating point, which we do use to squeeze out every last bit of performance from the machine.

We generally use C++ for everything today, as Toby mentioned. 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
  #14  
Old 10-28-2011, 08:41 AM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by anearforgear View Post
I've always wondered (and heard through the grapevine) about consolidating regions, or "clips" as we're now calling them. I'm always a bit hesitant to hit option+shift+3 because I've heard that when you consolidate you're adding dither as a result.

Is this true?
I believe this depends on whether you have the AudioSuite Dither option turned on. That is what I'd infer from watching plug-ins get created and destroyed behind the scenes. At least historically...

I believe that option+shift+3, consolidate, no longer uses AudioSuite plug-ins to perform this task though (as of 10), so I would guess that we don't apply dither during a consolidate regardless of that option now. But someone could easily step in and prove me wrong here. I'm not super familiar with the changes in this feature for PT10.

And yeah... IdeaScale is your friend. Regardless of what anyone else in the forums say, we do watch this...

Dave
  #15  
Old 10-28-2011, 08:57 AM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Marsdy View Post
1. I was wondering about chip sharing on the new HDX cards. On TDM systems there are some "chip hog" plug-ins. For example, an instance of Virus Indigo uses 13% of one chip, the remainder of the chip's capacity being unusable for anything else. Not even another instance of Virus Indigo can use the remainder. If I only use a single instance of a McDSP plug-in like Retro EQ in a mix, it uses 18% of one chip, the remaining 82% is then unusable for anything other than another McDSP plug-in.

With HDX having fewer chips than say an HD3 system, are "chip hog" plug-ins going to have a bigger impact on overall DSP capacity? I'm thinking a few greedy plug-ins might eat into the advantage HDX has over my HD3 system because fewer DSP chips are available per system. Maybe you could comment on how chip sharing is managed on the HDX cards? Or is this down to the plug-in developers?
AAX is a multi-shell environment, so all plug-ins share. It isn't an additional option like it was with TDM. Turns out this is very difficult to do in a general way, but I think we've nailed it. There are some circumstances where plug-ins will hog a chip right now because of non-deterministic resource contentions on the chip, but these cases are rare. And these outliers as far as chip resource usage tend to be the huge plug-ins, which would likely end up taking most of a chip anyway. I think you'll see these chips being packed much tighter than the legacy TDM system was capable of. Please let us know if you don't, and we can take an additional look at how to optimize the allocations.

Quote:
Originally Posted by Marsdy View Post
2. Will AAX plug-ins read user preset files created by their TDM equivalent?
Yes, if the plug-in developer sets up their plug-ins to be compatible. All of our AAX plug-ins convert seamlessly between their legacy and AAX counterparts. This includes conversion of types when you switch decks, settings saves in the session, presets, etc. This was actually a pretty tough compromise to make in the design, but we're not in the business of pure technical research. We understand that you guys switch between systems and we needed to make this transition as painless as possible.

Quote:
Originally Posted by Marsdy View Post
3. Are we likely to see many DSP AAX virtual instruments? If so, could an AAX VI running on an HDX card stream samples off disk?
Good question. I think that ultimately depends on the third party companies. There are a couple things that would need to happen. Your actual processing code for your instrument has to be pretty disentangled from the rest of your plug-in. You'd want the VI to be pretty deterministic in how much CPU it will take, which could be tough in many cases. And lastly, we have much less memory on the TI chips than in the host, so large samplers are probably not an appropriate fit for the DSP. If I had to guess, I'd say we might see synths someday on the DSP, which would be cool. Samplers, I'd guess not, but you never know. We're certainly willing to collaborate with the plug-in developers on creative ways to make all of these things possible...

Oh, and to answer your second question... not really. You can read the samples off disk from the host side of your plug-in and push them down to the DSPs just in time, but you'd have to really analyze whether this is a good use of the DSP and the CPU.

Dave
  #16  
Old 10-28-2011, 10:29 AM
TDigi TDigi is offline
Avid
 
Join Date: Jun 2004
Location: Colorado
Posts: 39
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by jeremiahmoore View Post
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).

Quote:
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
  #17  
Old 10-28-2011, 12:07 PM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Marsdy View Post
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
  #18  
Old 10-28-2011, 04:27 PM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by Capta¡nHook View Post
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
  #19  
Old 10-31-2011, 11:10 AM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by kbruff View Post
Ultimately will AAX allow me to buy TDM only pluggins and run them in pt10 native?

i.e. heat, tc electronic, and others?
I think the long term answer is yes, but ultimately it depends on what the plug-in companies want to sell and how they want to sell it. With AAX, we've strongly encouraged developers to use standard C++ code for their processing which can be compiled for different processors and platforms, but it doesn't mean they will choose to distribute those versions. There might be other factors weighing into their decisions.

Heat is a funny beast because it is technically a plug-in, but it is wired into the system in a very particular way. building the plug-in as Native is relatively simple, but wiring both versions seamlessly in, a little less so...

Dave
  #20  
Old 10-31-2011, 07:41 PM
DaveTremblay DaveTremblay is offline
Member
 
Join Date: Oct 2011
Location: Colorado
Posts: 191
Default Re: Transition to AAX: A Real Programmer's Perspective

Quote:
Originally Posted by kbruff View Post
So AVID is essentially enabling the pathway for developers, and not necessarily preserving a barrier as was the case with TDM versus RTAS. Therefore there can technically be dismissable difference between a Native session versus a HDX session, provided CPTK and 100% ITB mixing.

Is that a fair remark?
To be honest, I'm probably not the best person to answer this question as it speaks to a larger Avid strategy, but I'll try to give you some sort of answer as it pertains to AAX...

AAX was definitely designed to make plug-in development more consistent and simpler across various hardware architectures, and not just the processing code. Across the board, we moved to a much more modular portable design with AAX.

It would be easy to look at 64 bit and HDX and say, "hey, that's why they did AAX". And while that certainly factored into the timing of all of this, it is hardly the only goal... We're trying to set ourselves up for the future and the previous plug-in architecture was just too tied to our past. It was a very difficult project to maintain the important pieces of the past while setting us up for the future, but I think the team did an excellent job preserving our design goals.

Dave
Closed Thread

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Transition to AAX: A Real Programmer's Perspective reichman Pro Tools 10 289 03-02-2013 10:59 AM
perspective control 24 youbringmesuffering ICON & C|24 10 01-31-2010 09:27 AM
PC to Mac....looking for a little perspective Studio66 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 15 10-09-2008 03:50 PM
Reason / PTLE (different perspective) basis3708 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 14 09-06-2001 07:58 AM
Female perspective Doc 003, Mbox 2, Digi 002, original Mbox, Digi 001 (Mac) 6 07-16-2001 09:21 AM


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


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