Production Expert

View Original

The Role In DSP Based Plugin Processing - A Community Member's View

Community member Bertrand Grichting has been in touch with a response to the big UAD Octo-Test James was conducting . This test got him thinking about the role of DSP-based systems in these days.  Over to you Bertrand...

As we all know the support from plug-in manufacturers for AAX-DSP has been not overwhelming but on the other hand platforms like UAD have an ongoing success. As much as I like tests that stretch the technical boundaries like the OCTO-test, honestly I was not really impressed by the performance of the system itself.

I look at it this way: The UAD-system has 6 Octo-cards, totalling 48 physical Sharc DSP`s. James was able to run 96 Plugins and then the system was fully loaded, no additional plugin could be opened. That’s 2 plugins per DSP! That’s it!

Then I did some testing of my own. First let me say, they are not really comparable as I don’t have the test session James was using and I could not really conduct a fully functional test at 96K. But as one of the goals James was trying to achieve was building an analog console in the digital domain, that’s what I tried as well. Of course I don’t assume that most of us are actually tracking 96 tracks at once, but for mixing this makes some sense. Therefore I also did not put that much weight on the buffer size. This is my test set up...

  • Macbook Pro 15”, 1 x i7 Quadcore 2.2 GHZ, 16 GB RAM, SSD drive.
  • Pro Tools: Running at 24/48, 96 Tracks, each track has audio and volume automation on it and is 1 minute long.

To get some kind of analog feel and because I know that Slate’s plugins are not taking too many resources, I chose to use the VMR with the Virtual Console Collection, FG-N, FG401, FG-S and Revival on each track (The Thick rock kit preset plus VCC). That’s five plug-ins per track! At buffer sizes 32 and 64 the CPU was around 70%, but I got occasional CPU errors. With the hardware buffer size set at 128 I could play through the 1 minute tracks without any errors.

So basically I have 96 Tracks, each has 5 plugins in the VMR = 480 Plugins per physical CPU running at 70 percent. Of course an i7 CPU is not the same as a Shark-DSP, but on the other hand an I7 CPU has to do a lot of different things other than a DSP and the DSP’s sole task is to run plugins.

I did try it at 96K and I could just about manage to get 64 Tracks running, but with CPU errors even at 1024, the different buffer settings did not really make that much difference.

The bottom line for me, even as I said I don’t compare these tests, I can get almost the same result (analog feel on 96 Tracks and I can still open more plugins) without having to spend 9000 Euros (6 x 1500 Euros for the OCTO at MusicStore) excluding the chassis.

Don’t get me wrong, I love the UAD stuff, have lots of it. But it got me thinking:  Do plugin developers like Slate or Exponential Audio, that rely on the performance of the host CPU, or take a lot more care into programming efficient code in order to get the max out of the CPU? Why are UAD plugins such massive resource hogs? Just because they can be? If the customer runs out of DSP’s just let him buy another and/or bigger card/satellite? I wonder how UAD plugins would behave if they were running natively on the host CPU…

Thanks Bertrand for taking the time to do these tests and to respond to James' article. As a community, what do you think about Bertrand's thoughts on the cost effectiveness of DSP solutions. So share your thoughts in the comments below..

See this gallery in the original post