|
Avid Pro Audio CommunityHow to Join & Post • Community Terms of Use • Help Us Help YouKnowledge Base Search • Community Search • Learn & Support |
|
|
Thread Tools | Search this Thread | Display Modes |
#11
|
|||
|
|||
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Quote:
Quote:
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Quote:
-Toby |
#17
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
Dave |
#18
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
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
|
|||
|
|||
Re: Transition to AAX: A Real Programmer's Perspective
Quote:
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 |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 |