Possible fix for crashing on systems using UAD cards

I’ve started having Cubase crash and knew that there was an issue with UAD if running at anything other than a 44.1 sample rate and 1024 buffer size - which I though I was. However I found my buffer was set much lower so I raised it hoping that would help, especially when coupled with any potential under the hood changes in C7.0.6. For good measure I also updated to the latest UAD (which I’d been holding off on for several revs) for good measure.

Downloading the UAD update took forever because it was over 700MB. However when I looked at the dll files in the “C:\Program Files\Steinberg\VSTPlugins\Powered Plugins” folder I noticed that they were all very small files at 69kB. However the dll files with the same names in the folder “C:\Program Files\Universal Audio\Powered Plugins\UAD-2 Powered Plugins” were much larger.

Trying to understand this discrepancy I searched the UAD forums and discovered that the small files are some kind of pointer back to their larger brothers. Also some folks there discovered that if you deleted (or moved to someplace safe) all the dlls in “C:\Program Files\Steinberg\VSTPlugins\Powered Plugins” and replaced them with big dll files in “C:\Program Files\Universal Audio\Powered Plugins\UAD-2 Powered Plugins” it fixed their crashing problems.

Sadly this did not resolve my crashes, but I figured I’d pass the info on. Also there is some speculation that the UAD plugs are not really 64 bit but instead do some kind of internal bridging.

Here is the link to deep inside a very long thread.

Interesting thread on the UAD forum, I’ve not been following but I just scanned through it…

First I’ll say that I’ve never had any problems with UAD except way way way back on my old UAD1 card. I’ve recently been using 44.1k, 48k and 96k at various buffer size (normally 2048 though). All is well on my Win7-64 PC with 2xUAD2Quad.

I validated that I was using the 64bit versions by renaming the 32bit versions and also checking that the DLL that was being used was not in the x86 tree. Definitely using the 64bit version although the 32bit versions are still installed.

Juding by the info in the thread I would say that the speculation about whether UAD plugins are actually truly 64bit is answered pretty conclusively by a couple of people who investigated the dlls and found them to be 64bit.

I’d hazard a reason as to why UAD use a small ‘wrapper’ or ‘shortcut’ file in the VSTPlugins folder, and that may be because they’re looking towards people installing UAD onto drives other than the system drive, or along the same lines, they’re trying to keep the size down within the VSTPlugin folder. I’ve got an SSD so I’m limited in my OS space to 60Gig, I install most of my large installs onto D: drive for example.

In the ‘old days’ when I had crashes I used to swap my PCI cards around to resolve the problem, perhaps this would help you? I’ve also in the past re-installed the whole of the UAD stuff before, albeit in the UAD1 days, don’t think I’ve had to do it with the UAD2 and 64bit though. As I said, for me it’s been very reliable. Only problems I have is when I reach 100% UAD CPU and then I get errors and plugins stop processing audio, to be expected really!

Mike.

That makes sense for the file size matter.

Actually at this point UAD is way down on my list of culprits, since all the folks on the UAD forum that were having problems resolved it by copying the big files - which I’ve done. And I never had more than a very infrequent crash until recently. Currently I’m only writing using midi, so I went in and disabled all the plugs less than version 3. If that resolves things I’ll start adding back plugs and see what starts causing crashes. Of course it’s quite possible it has nothing to do with plug-ins.

I don’t have problems with my UAD plugins either (I have 1 Octo and 1 Quad), though I only work at 44.1KHz and 48Khz with 256 or 128 buffers of latency. I also do what that thread you linked suggests regarding moving the actual dll’s into the 64 bit VST Plugin folder, et al. The only thing left would be to swap the cards around, as suggested by Mike. Make sure you read your MOBO’s manual to see which slots have the least amount of resource sharing and/or what is being shared. This will also help you find the best PCIe slot for them.

Another thing to check is your DPC Latency (http://www.thesycon.de/deu/latency_check.shtml). Download this utility (don’t worry, it doesn’t actually install) and see if you have problems getting good latency while running a project. Depending on the system and how good you have it configured, you can get sub 100us latency while playing a project and that will be a good average amount. If on the yellow/red, then you may have a driver issue in which case you will have to use process of elimination in order to figure out what’s causing it. Unfortunately, the DPC Latency tool doesn’t provide this info. It only tells you if you have system problems or not. Good luck!