Audition Beach Balling (CPU Bound) Constantly

[clwill]

I'm running Audition 12.1.4.5 on MacOS Mojave 10.4.6 (although this problem predates either of these updates). The computer is a beefy one, a top of the line Mac Pro (2013) with 32gb of memory.

I'm editing a fairly simple podcast, with one voice track a small SFX track and a music track. No fancy effects on any of it, a parametric equalizer on a couple of tracks, and Dynamics on the voice track. Nothing complex, although I do have ducking on the music track.

I get a 20-30 second beach ball on nearly every action. Simply clicking on a track, changing tools (razor to move or vice-versa), heck even click over to it just now to check the version. I get a 30sec beach ball. And the CPU is hitting 450+%, even showing as "not responsive" in the Apple Activity Monitor. It's almost impossible to be productive.

The files are located on a NAS connected with gigabit network, and the caches are all on the local SSD. The Audition memory preferences screen shows 26gb available for Audition. The local SSD has 700+gb free.

The strange thing is this doesn't always happen. Sometimes when I use Audition, it's lightning fast. Other days, this happens. I've tried rebooting, that doesn't change it. I've tried closing down everything else (Chrome for example), no change. I've tried pre-rendering effects, no help. 

Anyone have any clues? This is killing my productivity.

Thanks!

[SteveG_AudioMasters_]

Usually it's something completely different - like virus protection or network polling - taking over the machine that causes this. But whether that applies to a Mac I have no idea, being a PC user. You might need a developer comment on this, or at least another Mac user, although we don't get many of them.

[clwill]

Thanks, but I know it's Audition doing it. As I noted, I watch the Activity Monitor (the Mac equivalent of the Task Manager). When this is happening, Audition shoots right to the top, using 450+% of the CPU (multi-core machine) and stays there while it beach balls.

I'm going to try moving the project locally and see if it's some disk issue. Not sure what I'll do then... but worth a try.

Still open to other ideas 🙂

Thanks

[SuiteSpot]

Try moving the media (and the sesx) to the local hard drive of your Mac - just to eliminate the network as an issue

[clwill]

Just tried this. I copied the entire tree (17gb) over to the local SSD, renamed the remote copy so Audition wouldn't find it. Confirmed that it was finding and using the local copy. Essentially no difference. Merely opening the SESX takes a while, but the very first mouse click, and I get a 30sec beach ball. Some actions seem to be better, but not infrequently I get this long ponderous beach ball, lasting 20-30secs.

For reference, here's the other stuff I've tried:

-- restarted both the machine and the NAS

-- did everything I could find in the Apple communities about SMB performance (remove signing, etc)

-- tried using AFP to connect to the NAS

-- rebooted the machine and run absolutely nothing else when running Audition

I still get these huge pauses. Audition runs fine otherwise, the functions all work, playback and mixdown are fine, etc. Just these interminable beach balls. Arrrggghhhh....

[SuiteSpot]

From your post we just discovered an important piece of information - "I copied the entire tree (17gb) over to the local SSD"..
Audition has been dragging 17gb over the network - that is a lot in anyone's game.
As expected there is some improvement by moving it to the local SSD but even so it is still 17gb.
To prove / disprove save a copy of the session (the local SSD version) and remove two thirds of the tracks and any reference to 'unused media' and run the session again. Any improvement?

[clwill]

No, you misunderstood. By “the entire tree” I meant the entirety of my podcast world. This project has five source files, their entire combined size is <50mb.

[SuiteSpot]

It did seem like a big podcast LOL. Is the option 'reference all open audio and video files when saving sessions' unticked? And have you selected File > Close unused media?

[clwill]

here are no files open other than the ones mentioned.

Gosh I hate this UI. How do I reply in a multiline window?

[SuiteSpot]

Yes it is a PITA - once you hit enter for a new line it posts the reply and then you have to edit it to get multiline

[SuiteSpot]

Can you email me the sesx file to info@aatranslator.com.au ?

[clwill]

OK, I've uncovered a bunch more. What is happening is also mentioned on this thread here: https://community.adobe.com/t5/Audition/Why-so-sluggish/m-p/10405686

I have one main file, the main narrative file. I misspoke above, it's ~150mb in size. Then three music files (not that large, ~30mb each) and a tiny sound effects file (~3mb). Three tracks (dialogue, sfx, music). No complex effects (eq and dynamics only).

When I first begin the edit, the UI is lightning fast. But then, I begin clipping the heck out of the narrative file, removing ums, ahs, breathing, mistakes, etc. The narrative file goes from one clip to ... hundreds? Each new clip on the big file makes it slower. By the time I get to the end, that's when it's crawling.

I found this out by copying the exact project to a new one, and ploppping in the main narrative. The UI is blistering fast. Only when I clip it up does it get slow.

[clwill]

So, I guess I'm going to have to change my process. I'll take the main file into the single file editor, chop it up, even divide it into chapters, then export it, and end up with only four or five clips in the main narrative file?

What a royal pain the in butt. I thought that was the point of a non-destructive DAW?

[SuiteSpot]

Each clip is a reference to the same media file so my guess is that it is pulling that same media file across the network for every clip so maybe try not having the media on the NAS and making some of the clips that you edit "Unique" (right click 'make unique copy')

[clwill]

But, as I noted, it didn't make it much faster when I did it from the SSD. I seems that each clip being a reference to the same file _is_ the issue.

Hmmm, tell me more about the "unique copy" thing? Never heard of that?

[clwill]

The more I think about this, the more I guess I'm going to have to change my process. I'll make a pass at the main file, edit it down significantly, remove the crap, fix the timing, etc., and export it. Into four or five "chapter" files. Then use those in multi-track to make the final edits with music, etc. It's an extra step, but I guess I gotta 🙂

Thanks for your help. Wonder if the developers will ever fix this issue, I note that the other post I commented on is from 8mos ago...

[SuiteSpot]

You did say "didn't make it much faster" - that is still faster 😉 but either way try the 'unique' clip option first

[clwill]

Thx, I will.

[clwill]

An interesting thing I just noticed. See my update below, I found a way to make it work. But this is a new episode. Same length (to within almost a second) same essential number of cuts on the main narrative. But the one that beach balls has an SESX file that's 175mb, the one that's lightning fast has an SESX file that's only 13mb. What could cause an SESX file to get so darn large??

[SuiteSpot]

Any chance youcan email me the two sesx files? info@aatranslator.com.au

[clwill]

I'll try. Compressed, they're 50+mb...

[clwill]

Just sent you Google Drive links for them. Thanks!

[clwill]

Well, I'm back to report that I found a way to make it work.

What I did today was take the main narrative file (~20mins in length) and just simply chop it into pieces no longer than about 5 minutes. That means that each file has no more than, perhaps 20 clips from it. Then just add those to the track in their usual time line spot. I didn't edit the files in any way, just broke the original 20min file into several pieces.

Though a PITA, this works. I haven't seen a beach ball all day. Similar length and complexity of audio and a similar number of cuts, but now it works great.

This is a truly sad bug on Audition's part. This shouldn't behave this way. But at least I found a workaround.

Thank you both for your help,

Chris

[SuiteSpot]

I am still looking at this sesx - it only has 123 clips in it and 5 media files yet is 171 mb. I have one here with 1003 clips and 129 files and is 3mb. Trying to find the bloat.

[SuiteSpot]

I have found the cause but before I say anything I need to bounce my findings off one of the devs - be back asap