Final Cut Pro constantly beachballing and hanging at nearly every action

Derek, the spindump indicates that during a blade edit operation, an audio effect initiated a failure cascade that hung the main UI thread. Sequence:

• The operation started as a blade edit (-[TLKSplitItemsHandler splitAtCurrentLocation:])
• This triggered an audio unit effect activation (-[FFAudioUnitEffect effectActivated:])
• The hang occurred during parameter synchronization in AudioUnitGetParameter
• The thread is stuck waiting for a response from an XPC service call (mach_msg2_trap)

Multiple audio processing threads are involved, suggesting a complex audio effect chain. This pattern suggests the hang may be due to one of these scenarios:

1. An audio unit (effect/plugin) is not responding properly during the parameter retrieval
2. There's a deadlock in the audio processing chain during the effect state copying
3. The XPC communication with the audio service is timing out. With Apple Silicon, all third-party plugins must be run in a separate host process and communicate with FCP via XPC calls. This reduces the chance of a buggy plugin crashing/hanging FCP, but does not totally prevent it.
4. Verify you are not running FCP itself in Rosetta2. Some misguided audio Fx vendors have not updated their AU effects to Apple Silicon and have covertly given guidance to customers to run FCP under Rosetta, which enables the use of their x86 plugin without them updating it to Apple Silicon. However, this often results in instability. Use Activity Monitor's CPU tab and examine FCP in the "Kind" column. That should say "Apple", not "Intel."

Suggestions:

• Reboot MacOS -- it's been up for 10 days
• Remove all possible audio effects and examine behavior
• Duplicate the timeline, open the duplicate, select all clips with CMD+A, remove all audio effects with Edit>Remove Attributes>(select effects to remove). Examine behavior.

You do have at least some remnants to the keystone stuff:

  [Not Loaded] com.google.keystone.agent.plist (Not signed - installed 2024-11-14)
    <Empty>

  [Not Loaded] com.google.keystone.xpcservice.plist (Not signed - installed 2024-11-14)
    <Empty>

  [Not Loaded] com.google.GoogleUpdater.wake.plist (Google LLC - installed 2024-07-31)
    Command: ~/Library/Application Support/Google/GoogleUpdater/Current/GoogleUpdater.app/Contents/MacOS/GoogleUpdater --wake-all --enable-logging --vmodule=*/components/update_client/*=2,*/chrome/updater/*=2

Also, you seem to have both Google Drive and DropBox.

Make sure that you are not using your libraries or media in any file location that is actively being synced to an online storage.

You have plenty of stuff from homebrew. This may or not be all right - sometimes different versions of some libraries are installed with homebrew and they may be used instead of the system ones, causing a big mess.

There was a kernel panic. This could be a hardware problem, but it seems more likely to be related to some of the installed daemons or extensions.

On 2024-11-13 you had a kernel panic, which is normally an OS or hardware problem. However that was a month ago. Your disk space is adequate.

Please reproduce the FCP hang problem and take a spindump on FCP and post that on a file sharing site I can access. To take the spindump, during the beachball phase, select the FCP process in Activity Monitor and press CTRL+OPT+CMD+S. That will take about 10-15 sec to run, so practice the procedure in advance to ensure it completes while FCP is in the beachball state.

Your description implies it's easy to reproduce, so at least it's easy to get troubleshooting data. Please do the above procedure twice and send me two spindumps, that way I can compare them.

Derek were the RX plugins iZotope RX? If so, what version? I vaguely remember some past versions of the iZotope RX plugins would destabilize FCP, but that was a few years ago.

I just upgraded to RX 11 Advanced, and it installed a bunch of FCP plugins, but I haven't tested them thoroughly yet. In general, due to fear of stability problems, I only use the external iZotope RX app, not the plugins.

I only examined the FCP portion of your spindumps. Upon closer study, a separate process AUHostingServiceXPC_arrow runs your plugins, which in turn communicates via XPC to a VST "wrapper" plugin within the FCP address space, which presents the appearance of AUs to FCP. Actual AUs can run within FCP's address space, which is a different scheme than video plugins which FXPlug4 mandates must be out-of-process. However your spindumps did not show in-process AU plugins.

However -- at the time of the spindump when FCP was hung, the separate process AUHostingServiceXPC_arrow was deranged, and was running 269 threads related to audio plugins.

Even though the separate process attempts to isolate FCP from a buggy plugin, if the AU host process goes completely crazy, that can crash FCP.

FCP still needs to maintain tight synchronization with that AU host process for real-time audio processing.

This communication happens through XPC messages that must be handled on both sides. If something disrupts this careful dance, problems cascade quickly. The presence of 269 threads suggests each plugin instance might have created multiple threads for processing. While these threads run in the separate hosting process, FCP still needs to:

• Maintain XPC connections to each plugin instance
• Manage shared memory regions for audio data transfer
• Handle synchronization messages and callbacks
• Coordinate timing and buffer management
• Process UI updates based on plugin parameter changes

If the hosting service becomes overwhelmed (perhaps due to those 269 threads competing for resources), it might stop responding to FCP's messages promptly. FCP, waiting for these responses, could:

• Block its audio processing thread while waiting for data
• Deadlock while trying to synchronize multiple plugin responses
• Run out of buffer space while waiting for processed audio
• Become unresponsive while trying to maintain XPC connections

A suite of plugins can work more-or-less OK on a given version of MacOS and FCP, then the updated OS or FCP may expose existing problems or compatibility issues with the plugins, which just never manifested. In general the OS or app (FCP) cannot be updated to fix a plugin problem, rather the plugin must be fixed whenever cases like this are encountered.

What is the history of this problem? Did it start upon upgrading a MacOS or FCP version?

It would be a good idea to update all audio plugins to the latest versions. That is a typical procedure when a plugin incompatibility is encountered.

Then I restarted, launched FCP only, made one cut and it immediately hung again

Derek Jones3 is a 2021 model and my MacBookPro is a 2020 model. These are old people who are on the verge of being excluded from development. Even with the latest OS, the old system remains all over the place, so I don't think throwing away apps and plugins will solve the problem.

I think the cause of the crash is complex and not just a problem with FCP. Also consider doing a clean install of a stable old OS (Sonoma/Ventura).

Turn off background rendering, then delete all render files.

What PERCENTAGE of your system drive is free space?

Do you have anti-virus software or CleanMyMac installed?

Thank you for reporting back. Did you also report to iZotope? They list support for PP and DVR, why not FCP too?