Error -9093

[Cheesehead]

Sounds great.

One more question and I promise I'll leave you alone.

What drives do you play your video from and where is your PT session stored?

Is your ssd only for the system drive?

Thanks again

[vudoo]

I'm playing my video from the Peragus Raid and the audio from the Lacie Little Big Disk 500GB SSD. My system drive is also an SSD (512 GB), actually, i believe the nMP only come with an SSD.

[fsavell]

Originally Posted by vudoo

Hi Cheesehead,

I also have an HDX system in a 12 core mac pro. There are sessions that barely play on it that play fine with the above HDN rig.

Hi Vudoo

Can you run a quick test for me? What happens if you run this same session (which is struggling on the HDX MacPro), via the Built In Output, ie. bypass the HDX.

Would be interested to see how much the HDX is choking the system.

Forrester

[vudoo]

Originally Posted by fsavell

Hi Vudoo

Can you run a quick test for me? What happens if you run this same session (which is struggling on the HDX MacPro), via the Built In Output, ie. bypass the HDX.

Would be interested to see how much the HDX is choking the system.

Forrester

Hi there,

If i open the same session (that was struggling under HDX engine) and change the playback engine to Built In Output and change all plugs to native than it will play but the overall CPU usage is much higher which i believe is normal as the ''older generation'' 12 core Mac Pro is not as fast as the nMP.

A while back i tested my HDX (in a sonnet approved chassie) and HDN on the same cylinder MP running only Native plugs and the HDN system performed better than the HDX.

Personally, i really don't see the benefit of HDX unless you need a multi card rig for the extra voices, otherwise, the horsepower of an HDN in a nMP is so much more powerful than HDX or even HDX2.

As for latency, i ran the above tests with a buffer of 32 and 64 and under these settings latency is a not a problem…hardware synth we've used for years has more latency than that !!! I have not tried tracking with plugs though as i never do, but this is where HDX might have a slight edge.

Reliability is the same with both HDX and HDN unless i use lots of VI, and if this is the case, HDN is definitely more stable.

Don't forget that Nuendo, logic, Digital performer…have been able to run ridiculously big session for years. It's just that Avid is starting to catch up with their native stuff. I still use Logic and DP for orchestral mocking because those huge VI session hardly run on HDN and forget HDX unless one wants to deal with constant cpu spike and errors.

[drumster]

Originally Posted by vudoo

I can work for hours and then out of nowhere error AAE -9093. This could be on a session with hundreds of tracks or simply playing one audio track with a click.

I read a lonnnnng thread about this issue awhile back so i guess it has never been fixed???

Mac Pro (cyninder) 3.5 Ghz, 6 Cores, 16 GB ram, Dual AMD D700, OS X 10.9.2
Pro Tools HDN 11.1.2, Avid IO 16 x16

There's nothing else but PT on this machine and running only Avid's plugs.

I am currently doing some testing with Pro Tools HD 11, and the -9093 error shows up every time I open up Pro Tools 11 for this time and try to play back the demo session i.e. Kelly Malone "Earth and Stars" from the beginning of the timeline. Perhaps it is due to all the Avid VI's in the session. i.e. Mini Grand, Boom, Vacuum, Structure and Xpand 2.

The system I am currently testing on is an early 2013 quad core, Retina MacBook Pro - 2.7 GHz Intel Core i7, 16 GB Ram, 512 GB system SSD, in conjunction with the HD Native Thunderbolt Box and the HD Omni. I am using Pro Tools version 11.1.3 and Mac OSX 10.8.5. I tried using Pro Tools 11.2, but it was considerably worse with CPU spiking at almost every buffer level. I installed Pro Tools on a fresh OSX build, and have tried repairing permissions and trashing preferences ect.

[Darryl Ramm]

Have you fully optimized the Mac? Every last thing done?

Other folks have seen problems with some of the AIR plugins, so check you really have the latest versions installed, and you should also try removing all the AIR plugins files from the plugin folder and if that makes things stable put them back and find the one (or more) causing problems. This is a quite likely cause so be sure to do this testing.

Are your sessions on the system drive? As well as all samples? How full is that drive? You can get away with a lot with the fast internal SSD drive on a MBP but that is still not the recommended way to do things and especially while troubleshooting get a nice fast external USB3 or Thunderbolt drive to use for an audio/session drive.

Do all the other standard troubleshooting, trash prefs and databases, exclude a corrupted session (test starting with empty new sessions not a copy, not from a template). Etc. And I would also try comparing using the MBPs built-in audio as the playback engine, disabling delay compensation in the playback engine, and doing all tests with "ignore errors" unchecked... You want to see errors while debugging.

[drumster]

Originally Posted by Darryl Ramm

Have you fully optimized the Mac? Every last thing done?

Other folks have seen problems with some of the AIR plugins, so check you really have the latest versions installed, and you should also try removing all the AIR plugins files from the plugin folder and if that makes things stable put them back and find the one (or more) causing problems. This is a quite likely cause so be sure to do this testing.

Are your sessions on the system drive? As well as all samples? How full is that drive? You can get away with a lot with the fast internal SSD drive on a MBP but that is still not the recommended way to do things and especially while troubleshooting get a nice fast external USB3 or Thunderbolt drive to use for an audio/session drive.

Do all the other standard troubleshooting, trash prefs and databases, exclude a corrupted session (test starting with empty new sessions not a copy, not from a template). Etc. And I would also try comparing using the MBPs built-in audio as the playback engine, disabling delay compensation in the playback engine, and doing all tests with "ignore errors" unchecked... You want to see errors while debugging.

Thanks for the suggestions Darryl. Much appreciated. To answer your questions, the audio session is being run off a brand new 256 GB, Lacie SSD Drive using the USB 3.0 connection on the MacBook Pro. The Lacie only has one Pro Tools session on it (the Pro Tools 11 demo session), so it's got loads of free space. The only VI's installed are the AIR instruments that come with Pro Tools and they are the latest versions. These instruments (Boom, Mini Grand, Vacuum ect.) are currently installed on the SSD system drive of my Retina MacBook Pro, but normally I always run an external sample drive for my sample libraries. In my case, that is usually a Samsung 840 Evo 1TB drive, which is a drive that you recommend highly on this forum. My Mac has been optimized at every level.

I have tried running the session using the MacBook Pro's built in audio for the playback engine, and the results are the same.

Earlier today, I installed Pro Tools 11.2 again, and once again experienced CPU overloads even when no audio was playing in the session. From my experience, 11.1.3 is much more stable, so that's probably the version I'll reinstall to work with Pro Tools 11.

[Darryl Ramm]

All good stuff! I would temporarily move aside the AIR plugin files and see if that fixes it. Yes even if they used to be Avid plugins and are still bundled with Pro Tools. AIR is now a separate company, but more importantly I am pretty sure that other folks have also described what you are seeing and traced it down to their AIR plugins. I think in some cases things magically fixed themselves when they cleaned everything off and reinstalled using all the latest Pro Tools and AIR installers.

If you want to test 11.2. I would be careful to remove older versions of Pro Tools and all remnants including the Avid aax plugin folder and all AIR and any other plugin files. Then test out 11.2 before installing AIR or anything else.

[drumster]

Originally Posted by Darryl Ramm

All good stuff! I would temporarily move aside the AIR plugin files and see if that fixes it. Yes even if they used to be Avid plugins and are still bundled with Pro Tools. AIR is now a separate company, but more importantly I am pretty sure that other folks have also described what you are seeing and traced it down to their AIR plugins. I think in some cases things magically fixed themselves when they cleaned everything off and reinstalled using all the latest Pro Tools and AIR installers.

If you want to test 11.2. I would be careful to remove older versions of Pro Tools and all remnants including the Avid aax plugin folder and all AIR and any other plugin files. Then test out 11.2 before installing AIR or anything else.

Excellent suggestions. I did some more testing with 11.2 today using both the HD Native Thunderbolt as well as the built in output on the Mac. I removed the AIR plugins from the plugin folder, and while that did help slightly, Pro Tools was still throwing errors messages. The good news is that I may have isolated the problem to the Sans Amp plugin. For some reason, this plugin causes random CPU spikes and overloading of the fourth core of my Retina MBP. This sometimes happen at a part of the session timeline where there is no audio playing. Disabling the Sans Amp plugin seems to bring more stability to the CPU usage.

I've tried to move the Sans Amp plugin to the unused plugins folder, but every time I restart Protools, it's right back in the active plugins folder. Perhaps I've never noticed this behaviour before, but is it possible to permanently relocate Avid stock plugins such as Sans amp to the Unused Plugins folder, so they don't load back up on start up?

[Darryl Ramm]

Great!

BTW that reappearing plugins is standard/magic behavior of the base Pro Tools plugins. The idea is you magically get back plugins that are tested by Avid/known to work.... which also makes it easy to just remove *all* plugin files and Pro Tools will put back all but the third party ones. A kinda handy shortcut, but obviously not good if Sansamp is blowing things up.

Now Sansamp CPU issues have been well known in the past -- the so called "denormalization" issue, with the RTAS plugin getting upset by receiving a zero input signal. The trick used to be to stick a dither plugin in front of the plugin to stop these CPU spikes. Arrrgg I was really expecting/hoping this was fixed on AAX, but you could check by doing that dither test. Search DUC for "denormalization" and you'll find more about this.

And be careful that is is really Sansamp, not another plugin you might say have instantiated or installed that Sansamp might be causing to trip up. but either way you have a work around, and hopefully other folks who are having problems can see if theirs is caused by Sansamp.