CPU Usage Errors While Recording Almost Anytime

[scorchedwave]

Hi there,

I am running PT 12.7.1 on MAC OS 10.12.6 on a macbook pro with a 2.5ghz i7 processor and 16gb of ram. I have a 500gb hard drive, and I'm not even using 1/3rd of it. I am also using a thunderbolt Clarett 8pre.

However, even when tracking at 48khz/24bit, the track stops recording and I get a CPU error.

This seems to happen no matter what. Sometimes, I'm tracking a vocalist and I have all the other tracks frozen, and I'll get an error. Sometimes, I'll have a very small project and I'll get a recording error.

Things I have tried:
I have tried fooling with the cache size for the session.
I have tried deleting unnecessary files from my hard drive.
I have tried deleting an app that someone mentioned on this forum, I forget the name. But it allows you to make changes to your Pro Tools account, and it runs in the background at all times.
I have tried changing the audio buffer for the session.

Does anyone have any other solutions? This is becoming extremely annoying for myself, and for clients.

[Darryl Ramm]

You are unlikely to make progress if you keep going like this.

Start at "Help Us Help You" up the top of every DUC web page.

Start by fully optimize you systems, every last thing done, as described there. Try the standard troubleshooting steps.... but I'll give you a likely better path through them below.

Always start with trashing prefs, being careful to follow the instructions for your systems version or use peter Gates' utility to make this easier. http://petegates.com/pg-pt-prefs.html

Deleting any files or apps is worrying, ... unless you mean you were following instructions to trash prefs. Maybe you meant Application Manager, OK that crapware you can uninstall. You need to take notes and be clear what you are doing. Not knowing what you have uninstalled is pretty bad.

What exact MacBook pro? Date code or model or EMC number. That will be printed on the case back. I am not going to spend my time trying to work out what you mean by CPU speed.

The size of you disk and how much you are using is really not intersting. What is important is what *exact* disk is this? e.g. is that the MacBook Pro original internal HDD or SSD and tell me what is System Report utility says that drive is.

And how many disks drives do you have? And which ones is the audio sessions on? If it's an external drive. I want the maker/model/specs for that as well as the internal drive.

Telling us you have tried "fooling" with stuff is a waste of time. What *exactly* have you tried?

And you have really given us none of the most important information...

What *exact* AAE error are you getting?

What IO buffer size are you using? At what sample rate? If you tried 48kHz just keep using that for now. But you did not tell us what buffer size. That is *the* most important parameter here. Try setting the largest possible IO buffer size and seeing if you can get the session stable.

You have not described you session, some clue there is needed: how many tracks, what plugins are in use etc, especially what virtual instrument plugins. What you are trying to do makes all the difference... and we cannot guess. If it's failing at sessions with one track and no plugins, that's is very useful to know. Again we cannot guess. Does this happen for only one session or multiple? (corrupt session can cause lots of types of errors).

Are you tracking or mixing? If mixing set the IO buffer size as big as you can and leave it there... does that work for you? (oops I see now the title says "when recording"... so what you are trying to push the sample size down to is all important... and if a very small size why? Can you live with hardware monitoring in your interface instead? Can you freeze/commit any tracks that use VIs or heavy plugins?).

----

Do not futz with changing and changing back stuff. Get the system fully optimized, every painful little thing done, however inconvenient for now. Leave them all sett that way. Then keep trying stuff cumulatively, don't try one thing then set it back. If there is a likely "better" setting for some thing set it that way and move on to the next thing. So a systemic debugging approach will look something like...

Fully optimize the system

Make sure your interface drivers are up to date. Reboot.

Make sure you are running at a sane sample rate, start at 41kHz or 48kHz.

Set your disk cache to 4GB and don't change it while trying other stuff.

Make sure "ignore errors" is **not** checked. You want any errors to cause Pro Tools to crash.

Uncheck dynamic plugin processing, leave it unchecked.

Trash prefs

Set the IO buffer to the largest size and see if it works, decrease until you start having problems. Then at that setting keep going....

Try disabling hyperthreading (multiple threads on DUC describe how to do that, or you can Google for it)

Trash prefs

Remove all third party plugins. You must always suspect plugins, even if they are installed in Pro Tools but not instantiated in the session. Move all .aaxplugin files out of the plugins folder, trash prefs and restart Pro Tools, it will put back the default plugins. leave it that way while you test further.

Try with an empty new session, and add standard plugins a few at a time.

Trash prefs

Create a new admin account and try with a new session form there.


Try using Built-In Input not the Clarett interface, does that work more reliably?

If you are still stuck report back here after you have tried all that and be very clear what you did (take notes as you do it).