Mac audio crackling after an update: what macOS 26 actually broke, and what fixes it

If your Mac's sound started crackling right after an update, you are in well documented company. macOS Tahoe's first releases shipped real CoreAudio bugs, reported across Apple's own support communities within weeks of launch, and later updates fixed the worst of them. Update past 26.1 first. The diagnostic below covers whatever crackle is left.

I build Submix, a per app mixer, and this post ends with an honest accounting of what a mixer can and cannot do about OS level bugs, which is less than a product page would like. Every claim about macOS 26 is attributed to a named, dated source.

macOS 26 audio issues: what actually went wrong

The community record came first. A thread opened on Apple's support communities on 3 October 2025 describes crackling on every kind of sound after the Tahoe update, notifications, calls and video playback alike, on MacBook Pro models from M1 Pro through M4 Max, and it drew dozens of me too responses (the thread is still readable). Coverage on Mac troubleshooting sites that month describes the wider family: pops, brief dropouts, warbly playback, and one channel, often the right, going silent after sleep until Core Audio was restarted (macReports, October 2025).

The vendor record is more precise. Rogue Amoeba, which builds SoundSource and Audio Hijack and lives inside this exact machinery, wrote on 4 November 2025 that macOS 26.0 shipped two critical audio bugs: captures from FaceTime and the new Phone app failing in many setups, and audio capture failing when a secondary output device ran at a different sample rate than the default. The same post lists further problems fixed in 26.1, including Safari audio at 44.1 kHz skipping during capture, low sample rate captures ceasing to work, excessive low pass filtering, and wrong or silent output on some professional interfaces, and its advice was to move straight to 26.1 or higher.

Developers filed their own chapter: a thread on Apple's developer forums titled "macOS 26.0 Tahoe + Xcode 26.0.1 Simulator causes system-wide audio distortion" describes launching the iOS Simulator degrading all system audio, which matches the pattern in community reports of crackle arriving under heavy load.

The timeline is the useful part. Guidance inside that October community thread already pointed to 26.0.1, then the vendor advice settled on 26.1 once its audio capture fixes shipped. That is the recurring shape of macOS audio trouble: the point releases immediately after a major update carry the fixes, so staying on the .0 build means keeping the bugs on purpose.

Why an update can make sound crackle at all

Crackling is what a gap sounds like. Audio reaches your speaker as an unbroken stream of samples on a hard deadline, passed along a chain of buffers by the apps playing sound, the system's audio daemon, and the device driver at the end. When a link in that chain misses its deadline, or hands the next link samples at a rate it did not expect, the stream tears, and a torn stream is a pop, a crackle, or a warble depending on how often it tears.

An OS update replaces the middle of that chain wholesale: coreaudiod, the frameworks above it, the drivers below it. A regression there touches every app at once, which is also the diagnostic signature. One app crackling while others play clean points at that app. Everything crackling, across apps and even across output devices, points at the layer they all share, and that is exactly what the Tahoe reports describe. The sample rate bug Rogue Amoeba documented makes the mechanism concrete: when two devices in one path disagree on sample rate, something has to resample the stream between them, and macOS 26.0 broke inside precisely that machinery.

The workarounds that circulated, and what each one actually does

Updating macOS is the fix; everything else is a bridge. The bugs above were fixed in specific releases, per the vendor post already cited, and as of early September 2026 Tahoe stands many updates past 26.1. A machine still on 26.0 is running the buggiest audio build of the entire cycle.

Restarting Core Audio: `sudo killall coreaudiod`. This restarts the daemon that owns every audio device, so all sound stops for a moment and anything mid call drops its audio stream briefly. It clears whatever bad state the daemon accumulated; it patches nothing, so the crackle can return. This is the workaround a senior community member posted in that October 2025 thread, and the original poster reported it working, for a while.

Toggling the output device, or reseating USB, HDMI and Thunderbolt audio connections. Switching away from a device and back forces macOS to tear its path down and rebuild it, the same reset at a smaller radius. The October 2025 workaround lists lean on this one for crackle tied to docks and external displays.

Re pairing Bluetooth devices. Removing and re pairing rebuilds the connection and its negotiated settings from scratch, which is why it appears on the same lists for AirPods and other Bluetooth audio.

Aligning sample rates in Audio MIDI Setup. The circulated advice was to open Audio MIDI Setup and set output devices to one common rate, typically 48 kHz. This is the workaround with the clearest mechanical story: given that the documented 26.0 capture bug fired when device rates disagreed, forcing every device onto one rate keeps the stream out of the resampling path that was breaking.

Mac sound crackling with no update to blame: a short diagnostic

1. Follow the device. Play the same audio through a different output. If both crackle, suspect the system layer or the source. If only one does, suspect that device's path: the cable, the dock, the hub, the Bluetooth link.
2. Follow the app. One app crackling alone points at that app; quit and relaunch it, and check its own audio settings. Everything crackling points at the shared layer.
3. Check rates. In Audio MIDI Setup, look at the sample rate of each output device, especially if you use an aggregate device, and set mismatched devices to one rate.
4. Watch the load. If crackle arrives with compiles, exports or Simulator boots, you are reproducing the load linked pattern from the developer forum reports rather than a hardware fault.
5. Reset the daemon. sudo killall coreaudiod, accepting the momentary silence it causes. If the crackle clears and stays clear, it was accumulated state. If it returns on schedule, it is a bug or a device, and steps one to four say which.
6. Check the calendar. If the noise began the same day as a macOS update, search Apple's support communities for that release before suspecting your speakers. The Tahoe chapter above is proof enough that the OS can be the whole story. And file it with Apple's Product Feedback site, which is where that community thread pointed reporters; OS level audio bugs get fixed on the strength of those reports.

What a per app mixer can and cannot do about this

Honesty first: a per app mixer cannot fix crackling the operating system produces. Submix works through Core Audio process taps, which ride the same daemon, the same clocks and the same device paths as everything else on the machine, so an OS level artifact passes straight through a mixer, and any per app tool claiming to cure one is overreaching, mine included.

What a mixer genuinely helps with during a bad audio stretch is narrower and still useful. It can pull one misbehaving app down or mute it without touching the call you are on. It can move a single app off a glitching output onto a different device while you sort the first one out. And its per app level meters answer the question diagnosis keeps asking, which app is actually making sound right now, at a glance; how those meters come for free with the mixing pass is covered separately.

One last piece of advice that cuts against my own product: while you are actively chasing a suspected OS audio bug, simplify the path. Quit the mixer, test bare, and add it back once the base system plays clean. Every tap is one more moving part in the chain you are trying to isolate, and a clean result with nothing extra running is the fastest way to know where the fault does not live.

Changelog: first published September 2026, with the macOS 26 record accurate to the dated sources named above.