What causes CoreAudio to crash on macOS Sequoia?

Yep, it's definitely related to Rogue Amoeba SoundSource and their new "ARK" engine.

Apple should take half the blame for that, as they've made it insanely, and I mean insanely, difficult to install System Extensions (which SoundSource used to use).

On the other hand, this is a TERRIBLE problem. Suddenly I was on a very important international Zoom call and I couldn't hear the other person (and don't know if they could hear me, but probably not). It was really embarrassing, and after a couple minutes, I force quit SoundSource and got sound back.

More recently, I've had to force quit coreaudiod just to even reboot the system.

This is really bad, especially since SoundSource is a paid product. Why did Rogue Amoeba switch us all over to a new engine without sufficient testing of its stability?

macOS is only operating system in which you can't control audio levels of specific apps separately.

And Sequoia made best solution (SoundSource) almost unusable, since it constantly crashes now.

Why can't macOS just be normal..

This is still happening on latest version of Soundsource on my m3 macbook pro. Randomly anything that might use audio will lock up and I will have to force quit and reboot my macbook.

Hey there

I am having the same issues.

Suddenly Apps that use Audio (FCP, Spotify, Quicktime, etc) stop working or refuse to even start.

I then have to force quit coreaudio to make them work again.

I ALSO use SoundSource and also suspect the Rogue Amoeba tools to contribute to the issue in some way.

I have these issues too, with Rogue Amoebe we are investigating if SoundSource or ARK might be causing these hangs. Are you using SoundSource as well?

Ever since upgrading to macOS Sequoia I'm having this problem too on my macBook Air M1, even on macOS 15.1.1. After some amount of time Safari stops functioning. Pages keep failing to load and the error message "This page was reloaded because a problem occurred" appears. Here's a video of this behavior: https://www.youtube.com/watch?v=HO1KJVyBSEk

It also sometimes causes the Finder to become sluggish/unresponsive. Or video cannot be played from apps. I already disabled all Safari extensions, but that didn't help. Activity Monitor doesn't show a huge increase in CPU or memory for Safari or any other process.

I did once notice that both Rogue Amoeba SoundSource 5 and a Facetime process were red/not responding. Killing those didn't solve the problem. I did contact Rogue Amoeba support and sent them a Spindump of the unresponsive SoundSource process and they replied:

"Based on some similar reports, it seems that the underlying audio system itself (coreaudiod ) is running into some sort of resource limitation which is causing our app – and all other apps that use audio on the Mac – to stop responding entirely."

So SourceSource is either the root of the problem or it's a victim of coreaudiod malfunctioning. I've removed SoundSource from automatically starting at boot. So far the problem hasn't happened again.

The fact that Apple makes it difficult to install System Extensions doesn't have anything to do with this problem. Also, paid products almost always still contain bugs. Software development is hard and so is software testing This might be an edge case that's very hard to find during regular testing.

Anyway, this is a bug. And at the moment I think it isn't totally clear who is the culprit. It might be SoundSource and/or their Audio Routing Kit (ARK). But it can also be caused by a bug in macOS Sequoia, and specifically coreaudiod. Apple is known for making major changes to their audio pipeline for every macOS version. This often breaks products that use audio, especially the more low-level things like audio interface drivers. Maybe SoundSource is making the proper API calls, but coreaudiod somehow gets into a buggy state, taking down all apps that use audio.

It does have to do with the difficulty of installing system extensions. The new ARK engine is easier to install as it doesn’t seem to require a system extension (as I didn’t have to authorize it / downgrade security for it). Rogue Amoeba is trying to improve UX. They should have allowed us to choose which engine to use until the new one becomes stable.

Tom, it seems your previous reply to me was deleted. Frankly, I wasn't sure how to respond to that long off-topic tirade about you being a legally blind, very experienced software engineer and Apple taking things away, becoming worse at UX, etc. And you claiming I was discounting your point of view about system extensions being difficult to install.

This is a topic about an issue that's causing CoreAudio to freeze/crash. Whether any apps related to this issue/bug are difficult to install isn't relevant. I don't see what the install experience of an app has to do with this issue manifesting itself.

Note, I fully agree with you that Apple's implementation of installing system extensions is a bit rough and a bad UX. The same applies to macOS privacy/security permission system. It seems Apple chose security over UX. And as you also mentioned, we've seen Apple and app makers slightly improving things. Also, we see app makers transitioning away from low-level system extension stuff. Rogue Amoeba has replaced its ARC system extension with the new ARK audio capture engine, which is much easier to install.

You claimed this new ARK engine isn't stable and that Rogue Amoeba didn't test it enough. I was just responding to that, by saying that we cannot be sure of that. For all we know they did very extensive testing, but just didn't hit upon this bug. I'm also a very experienced software engineer and I know these things happen. You can test all you want, but there are always bugs you don't catch before releasing your software into the wild.

What I find interesting is that ACE was a system extension, which in theory could cause way more harm to the system, because it had low-level access to the kernel. The new ARK engine isn't and probably does its work using new macOS APIs Apple has provided for apps so they can still do their thing, without requiring system extension level access. How can it be that such apps are still able to bring coreaudiod to a halt? That sounds like a bug in those macOS APIs.

For what it's worth, I noticed Rogue Amoeba has just released a new version of ARK (and SoundSource) and so far I haven't had this issue happen again. But again, we don't even know for sure if ARK/SoundSource is causing this issue or if it's a victim of this issue.

Difficulty of installing System Extensions is a social cause; I never said it was a technical cause. This bad UX probably led to fewer people installing the app (because how many can actually figure out how to install an extension anymore?), which led to lower sales. The need to keep sales up would necessitate better UX, which would improve conversion rates, and was likely done as soon as possible.

The ACE engine, which was a System Extension, was more stable. I agree with you that CoreAudio is probably very buggy; I've had other issues with my own screen reader app, likely related to CoreAudio. I do argue that UX has a lot more to do with the success of software -- at least by small companies -- than engineers often give credit.

yes, see my post above