Alongside its Pro Tools 10 and HDX unveiling, Avid turned some heads by recently announcing it was replacing its RTAS and TDM formats to a new format called AAX, “Avid Audio eXtension.” Now, your first reaction may not be unbridled enthusiasm, exactly: it seems the last thing users are likely saying is, “yes, please, I’d like a new plug-in format to worry about.” But I wanted to give the engineers at Avid a chance to tell us what they were thinking and why they made the move.

Avid’s product announcements have unfortunately coincided, presumably because of the financial calendar, with unpleasant restructuring and downsizing news, a topic NYC-based audio engineering site SonicScoop takes up. However, I prefer to focus here on the engineering side of what’s happening; we can look at Avid’s business and the changing business landscape another day. (For what it’s worth, I’m not as bleak as SonicScoop about the industry at large – least of all because I think the larger audio market remains healthy, even if Avid has been caught adapting to a new marketplace.)

The picture painted by Avid is one of a smooth transition to AAX. Now, of course, you’d expect them to say that, but I think they do have some specific technical reasons that, even with the change of name, the shift should be friendly to Avid developers. I’ll let them explain, though.

Bobby Lombardi, Senior Pro Tools Product Manager goes into the technical details of what AAX, and what it means for Pro Tools developers and users.

CDM: The main draw appears to be the ability to switch between native and DSP-based processing more easily, correct? From the end user perspective, can you get into specifics on what a user will see and how this will differ from RTAS/TDM?

Bobby: Visually, a user will see that the RTAS/TDM pop-up on the Pro Tools 10 Plug-in header has changed to Native/DSP. The exciting part is what they will hear. In the past, with HD Accel systems using a 24-bit fixed point processing environment, and host-based systems using 32-bit floating point processing, the gain staging could be quite different and produce significantly different results. With the introduction of AAX, sessions that migrate between host-based and DSP-accelerated HDX Pro Tools systems will sound identical.

How much work will it be for developers to migrate from RTAS/TDM to AAX?

Moving from an existing RTAS plug-in to AAX Native is relatively simple. Plus, once a developer has an AAX Native plug-in running, it will take a small amount of development effort to support AAX DSP. In comparison to TDM 56k used with the legacy HD hardware, AAX DSP is much easier to support and developers do not require specialized skills in writing 56k assembly code, so it opens up the opportunity for many developers to create DSP accelerated versions of their plug-ins.

We’ll still see parallel, separate versions of plug-ins for AAX Native and AAX DSP, correct? And some will, as with RTAS, presumably be native-only?

This is really up to the individual developer. Some developers may find it strategic to support one or the other, however Avid’s goal with this new format was to simplify plug-in development and reduce the complexity to support accelerated hardware.

RTAS and TDM are listed as “legacy” formats. Is Avid making any commitment to how long they’ll last?

The RTAS and TDM formats will continue to be supported in the 32-bit versions of Pro Tools but will not be supported once Pro Tools is released as a 64-bit application. The new AAX plug-in format is the bridge to 64-bit plug-ins for the Pro Tools and Media Composer platform.

Avid has expressed a desire to embrace open formats, but why is there still no common, industry-wide plug-in format? (Actually, there may be no good answer to that question, but I feel obligated to ask!)

We absolutely do embrace open platforms because they can open workflows that enhance the user experience. Part of the experience we need to ensure is that it’s stable, integrates well on our control surfaces, and provides a long-term commitment to the customer. For these reasons it’s important that we can design the plug-in architecture. For example, without designing AAX we could never give customers a plug-in environment that supports both DSP accelerated and native Pro Tools systems and ensure they delivered 100% sound parity. We hope that by providing a modernized AAX SDK for plug-in development, developers will find it easier not only to support Avid’s products, but also finding it easier to develop for non-Avid plug-in formats.

Any word on when we’ll see third-party plugs with AAX support?

More developers are coming online each week with their AAX offerings. We had over 25 developers showing over 60 individual AAX plug-ins at the AES tradeshow in NYC last month, and expect to see many more at the upcoming NAMM tradeshow. With the ability to provide all Avid third party developers a optimized development path to DSP-accelerated plug-ins, we do expect to see more DSP-accelerated plug-ins on the new AAX platform than the legacy TDM platform.

Thanks, Bobby. And for one other take, I happened to get to talk to Universal Audio about their transition. UA, given that they have their own DSP platform and support Avid’s rival packages, certainly aren’t dependent in their business on the Avid ecosystem (though you can be sure it makes a big part of their market). Anyway, here’s what they say; I’m guessing other third parties would say something similar, but if you’re a third party reading and wish to comment, please do so, and don’t let the fact that I only have UA here dissuade you.

Lev Perrey, Universal Audio Director of Product Development, responds to CDM:

Universal Audio intends to support AAX Native in conjunction with UAD-2 DSP accelerators ­ exactly like we have just completed with RTAS support in UAD Powered Plug-ins v6. There is no announcement as of yet as to when the transition to AAX will be complete but we are actively developing and committed to the Pro Tools platform. Pro Tools 10 does support RTAS and initial testing with UAD plug-ins shows it to work just like Pro Tools 9.

As for the significance question, for UA moving to AAX Native should be similar to our recent migration to RTAS ­ although it will be easier for us now moving to AAX since we have fully invested in direct Pro Tools development and better understand the Avid SDK.

We’ll continue to follow this story. Thanks to Avid for getting us more details; I know it’s appreciated.

More info:
AAX Audio Plug-ins @ Avid

For some time, the move has seemed inevitable – even more so as the rumor mill started echoing with suggestions that a native release was coming. But now, it’s happened: Pro Tools HD will now run without HD DSP hardware. And that’s not all — you can also use the same hardware with your existing DAW of choice, for users of software like Cubase and Logic.

There’s a price tag attached, though. This remains what for many would be a high-end solution. At US$3495 retail and up, it’s not competition for buying a basic interface card and Cubase. Think, instead, a more affordable and flexible way to equip studio rigs, and some potentially serious competition for vendors like Apogee, especially since you can use any DAW you want.

Just to say that again: Avid is making a version of Pro Tools HD that runs on the CPU and supports any DAW on Windows 7 or Mac OS X Snow Leopard and higher.

The AIR (Avid) user blog has some terrific analysis on the announcement even before it became public, comparing leaked price info for Native to an Apogee rig. If you haven’t been reading the AIR blog, they’ve hardly been shills for Avid; they’ve savaged some of the company’s decisions. And they’re actually pretty positive here. (Spoiler: Avid winds up being cheaper than Apogee by a few hundred bucks in their calculus.)
Is An Avid Pro Tools HD Native Core System Expensive?

What you get for that investment, though, is something worth discussing. It also reveals what’s necessary to get real, low-latency audio operation, which is relevant even if you aren’t in the market for Pro Tools|HD Native. CDM gets some insight into that from the developers.

First, Pro Tools|HD Native at a glance. Bundles:

Native core: $3495 buys you the necessary PCIe native card plus Pro Tools HD 8.5 software. The card comes with two Digilink mini ports on it.

Native core + OMNI Add an HD OMNI interface to the above. Total: US$5995.

Native core + HD I/O 8x8x8 Get a full 8x8x8 HD I/O interface. Total cost: US$6995.

Native core + HD I/O 16×16 analog US$7995.

Availability: November 4.

So, why bother with “HD Native” when there are versions like LE? The difference is that some of the more serious studio features remain:

• Surround, VCA mixing
• Destructive/track punch, advanced automation
• Solo Bus AFL/PFL, track-based input monitoring
• Sync HD support
• 9-pin Machine Control
• Venue support. (Yeah, that’s pretty huge, since Venue rigs don’t necessarily need all the TDM stuff.

This isn’t a TDM solution, though, so you don’t get TDM plug-in support, which for many is one of the big draws of Pro Tools. That includes the recently-announced HEAT, an analog-modeling sonic sweetener based on the qualities of tape. (There’s more to say about HEAT; I just got off the phone with its talented designer Dave Hill, so expect the results of that interview soon.)

It is a significant “mid-range” studio solution, and will likely fill a big need for Pro Tools customers. Avid told CDM in a briefing yesterday that they’ve gotten enormous demand for just such a solution. Just doing a discounted upgrade to HD got a big response, and users have wanted something between LE and the TDM-based HD for project or secondary studios. It also seems to me that it demonstrates Avid is willing to change, which could have greater implications down the road.

What you get is, says Avid, not a replacement for their DSP solutions, but otherwise unrestricted in sync, I/O, and functionality. It has the mixing and I/O LE lacks, and it even supports legacy “blue” HD converters (192, etc.), making it a likely candidate for upgrading studio setups that didn’t make the leap to 8.5 software.

If you don’t want to use Pro Tools as your DAW, you get 64 channels of I/O with any Core Audio (Mac) or ASIO (PC) system. Avid says they’ve tested extensively with Logic and Nuendo; Digital Performer, SONAR, and others should work, too.

And, notably, it’s a native system with extraordinarily low latency. Pro Tools|HD does .44 ms (at 96k and a 64 sample — yes, sixty-four total – buffer). But HD Native does a very respectable 1.6 ms; less than half that if you choose direct monitoring while recording, which you can do with simple stereo monitoring or even 7.1 surround setups. That’s 1.6 ms through the native setup, through PCI, and through the kernel and operating system. We’ve heard those kinds of theoretical numbers, but it’s a big deal to get it consistently on a computer system with a single, stable setup.

The Latency Story

I was curious to hear more about how Pro Tools|HD Native achieves those low latencies. The answer says something about the direction of Pro Tools, but also the potential of native computers for this sort of processing in general, regardless of the tool you use. (And that’s the sort of information we like.)

Bobby Lombardi, head of Pro Tools Product Management, explains to CDM:

The magic answer to all this is the Core Audio/ASIO “safety buffer” which is an additional layer of latency used by third party IO manufacturers (HW) manufacturers who provide Core Audio drivers for their HW. We also use a safety buffer for all of our hardware (including LE and M-Audio) that have Core Audio and ASIO drivers.

A safety buffer can have a very wide range of values. PCIe based hardware IO is the best case where manufacturers could theoretically get down to a 9 sample buffer, and go as high as several hundred samples for USB devices.

The key for a high-performance, low-latency system is PCIe-based IO and quality low-latency converters. This is the main reason why a PCI-based Pro Tools HD Native system combined with an HD IO has such exceptional latency.

The story gets even better at 96kHz sample rates where most converter latencies where the host CPU latency halves itself, and many high-end converters are capable of a low-latency converter mode without sacrificing quality. Our new HD IO and OMNI IO have such converters and perform in a low-latency performance mode when used at 88.2 and higher sample rates.

So to recap. The best possible latency story for Pro Tools HD Native using AD/DA converters is:

Pro Tools HD Native
Pro Tools HD Software @ 96kHz, 64 sample playback buffer
HD IO or HD OMNI interfaces

If anyone wants to get deeper into these issues with Avid (or anyone else), let me know; I’m game.

Don’t Write Off TDM Yet

Worth saying: this is probably good news for the future of DSP-based, TDM Pro Tools systems, not bad. The business advantage for Avid is, they sell more hardware and software, and keep more people on their platform. (I don’t think they can be faulted for that.)

But if you’re wondering, why bother with the pricier TDM systems at all, the story there doesn’t really change. As Avid puts it, TDM’s advantages don’t suffer when your CPU becomes more powerful. That just means you can use all the horsepower of the CPU and all the additional DSP processing of the HD TDM iron. Some of their customers are also using pretty extreme use cases, like recording 500 channels a time of a symphony orchestra. (I got an angry note regarding Logic Pro after writing a review of Apple’s DAW for Macworld where someone complained that Logic was choking over just sort a setup. Naturally, as a home producer, I had neither tested – nor could really conceive – what that setup looked like.)

There’s also time. Developing highly-optimized TDM plug-ins in Assembler is a different game from writing RTAS (or VST, or AU, etc.) plug-ins in C, and not everyone will port from one to the other.

What’s interesting to me, though, is that some of these issues transcend usage scenarios, budget, and the like. I don’t doubt that every musician would love 1.5 ms latency. And those fundamental architectural issues I believe will continue to be relevant for the entire musical community – whether their tools count as particularly “Pro” or not.

The explosion of interest in filtering out sounds of the vuvuzela has spawned some interesting discussions. Most amusing to me is the notion of some sort of anti-vuvuzela bias. The simple matter of the fact is, recorded (and broadcast) sound are not the same as the sound you hear when you’re physically in a location. If you’re at a sporting event, you hear all kinds of noise. Your expectations are differently calibrated, and you have 360 degrees of (real world) sound spatialization. Watching TV is different. You want background sound, yes, but not to the point that it drowns out commentary. In effect, you want the broadcaster to create an artificially well-balanced soundscape. What’s really striking about the World Cup is that the planet’s largest broadcasting companies all seem to have been caught unprepared for the vuvuzela cacophony.

Which brings us to Waves. So, yes, I took some cheap shots at Waves’ pricing on their plug-ins in yesterday’s massive round-up, and yes, I did actually … hear about it.

First, I want to be clear that in the avalanche of responses to the vuvuzela, there are a number of different techniques – not all notch filtering, though, as my headline hinted, the fact that “notch filtering” is a phrase coming up in mainstream media, blogs, and sports coverage is itself newsworthy.

Waves’ approach involves their noise suppressor. What I said about pricing may have been unclear in regards to the presets: the custom-developed preset chain, made by Waves for broadcasters (and apparently in collaboration with one, specific broadcaster Waves has not named), is entirely free. The cost to which I referred is the noise suppressor itself (US$2900) and the parametric EQ ($300).

And no apologies here for pointing out the gap: compared to most audio software, $2900 is indeed a lot to pay for a plug-in. One of the strange things about audio is that there are sort of parallel dimensions of value/cost equations and markets. In this case, I’m sure the broadcasting market is absolutely willing to pay $2900 for audio software – looking at the cost of, say, a World Cup license, the cost of the equipment used for that broadcast, the human hours that go into plug-in development, and the limited number of potential broadcast customers, Waves’ pricing is actually pocket change. But that further illustrates the disparity: it’s pocket change to the BBC or ESPN, whereas an individual, home audio producer might well use tools that are entirely free as an alternative.

Waves isn’t even, as [someone] pointed out to me, the pricey end of that spectrum – not by a longshot. France’s Canal+ hired an entirely private commission to do what, for Waves customers, at least, was free. [article in French] The result: a non-TDM custom effect solution from a local developer with what was likely a very, very high price tag.

But you can also judge this for yourself: if you’re curious to try out the Waves solution, both WNS and Q10 provide a 7-day demo. It’s definitely the posh steakhouse of plug-ins, to the “street vendor sausage cart” alternatives I mentioned. Pricing is economics, not a quantification of value – such is the nature of the beast. But you can determine how much that market-driven pricing translates to the software. What Waves gives you is certainly a friendly interface, some sophisticated tools tailored to the task, and what’s likely, out of the box, to come closest to producing broadcast-quality sound. Naturally, I also think that delivering that broadcast-quality sound ought to be the job of the broadcasters, not someone at home with a TV set. The question of which tools are relevant for music production, rather than covering the World Cup with an entire network TV crew, can be saved for another day.

While we’re clarifying, I think the most interesting of the long list of solutions I mentioned, apart from Waves’ solution, is the plug-in from the Centre for Digital Music (C4DM) at Queen Mary, University of London. Dan Stowell notes that, while some of the other techniques mentioned do indeed involve notch filtering, what’s at work here is “a bit cleverer, kind of tuned median-filter.”

The C4DM plug is truly free software, under an MIT-style, open source license. It’s actually a pleasure to browse through the code – bless you, digital signal processing, as mathematically, tasks like this look pretty readable in C and C-style code. No, such things aren’t comparable to, say, a Waves plug-in. At the same time, at their heart, they are fundamentally the same animal. We’ve seen this basic technique (digital signal processing) packaged in wildly different forms. We have academic research centers, which one might argue should engage in open code if they’re publicly funded. We have free code that comes from people who aren’t in academia. We also have businesses that naturally spawn around catering to a very different customer, for whom value is easy to justify given the potential revenue from the product (a sports broadcast), and who likewise have higher expectations of user interface, real-world performance, and support.

But such is the broad spectrum (ahem) of sound software today. Take something as simple as filtering out a drone at a particular frequency, and you see a broad set of potential uses, an audience literally as large as the entire planet’s sports fans, tools on every conceivable platform and operating system, and markets that range from interested academic researchers and programmers to broadcasters with deep pockets.

All over a cheap plastic horn.

It’s a reminder of all kinds of disparities. There’s the economics of sound software, scaling from hobbyist to academia to business, from code that people give away to highly-priced custom services that make Waves plug-ins look like $2 iPhone apps. But more important than that, while specialization in sound software remains the domain of a tiny niche of society, but the ultimate market – human ears – is in the billions. Perhaps while we hide out in our blogs and trade magazines, we forget that.

7.4.2 Announcement – download is right there [Digidesign]

That’s the good news. The bad news is, your plug-ins may not yet be along for the ride. Digidesign reports some current instruments and plug-ins may be “incompatible.” Based on other reports, I assume this means it’ll run, but may either cause instability or sub-par audio performance.

Digi is maintaining a plug-in compatibility page for Leopard.

Here’s the other bad news news: for the most part, that’s just plug-ins that Digidesign ships directly. Some of them at least have updates, but some of Digi’s flagship instruments (Hybrid, Strike, Structure, Velvet, and others) are awaiting updates as of press time. Your third-party plug-ins require a whole separate set of compatibility checks.

At least what we’re generally hearing from readers is that the situation is getting better, not worse. I’m still far from being able to recommend Leopard, however, especially given the fact that Tiger remains such an adequate OS. Update: Digidesign tells us that they’ll be monitoring other third-party plug-ins on that page, as well.

FireWire Fixes (Non-Digidesign)

Via PowerPage, some users of Leopard are having FireWire connection dropouts. At least for this issue, though, there are some suggested fixes. The symptoms, as reported at MacFixIt:

After the installation of software updates, the FireWire ports on various Mac models may cease to properly function, not recognizing devices or exhibiting other issues. For some users, this has occurred with printer driver updates and for others it has occurred with the latest QuickTime update. One MacFixIt reader reinstalled Leopard and the problem still occurred.

FireWire connection dropouts: more fixes [MacFixIt]

That’s a pretty nasty issue, but it sounds different than the intermittent audio issues users here were reporting, so I don’t know how widespread it is or whether it’s related to problems CDM readers have had.

I’ve actually seen less documentation of the audio issues, which means, brave CDM readers – it’s up to you. You’re the ones pushing your Mac’s audio. So if you are still having issues, even with current drivers and 10.5.3, be sure to let us know exactly what your hardware and software configuration is.