Skip to content

Instantly share code, notes, and snippets.

@metrovoc
Last active July 15, 2026 20:37
Show Gist options
  • Select an option

  • Save metrovoc/0b5e3590c6069cf99b01559863bc2ce4 to your computer and use it in GitHub Desktop.

Select an option

Save metrovoc/0b5e3590c6069cf99b01559863bc2ce4 to your computer and use it in GitHub Desktop.
macOS Tahoe audio glitch workaround: kill all CoreAudio clients + daemons to restore degraded audio without reboot

macOS Tahoe Audio Glitch: Diagnosis & Workaround

Symptom

On macOS Tahoe (26.x, tested on 26.3 / M3 MacBook Air), system audio gradually degrades over time — volume drops significantly and sound becomes muffled across all outputs (built-in speakers, Bluetooth headphones, etc.) at the same volume setting.

  • Onset is intermittent: anywhere from hours to days after a clean reboot.
  • coreaudiod sometimes shows elevated CPU usage during the degraded state.
  • A full reboot reliably restores normal audio. The issue then eventually recurs.

What doesn't work

  • sudo killall coreaudiod: Does not resolve the issue. In my experience, each restart of coreaudiod appeared to make the CPU usage slightly worse, suggesting the problem compounds with repeated restarts.
  • Toggling sample rate (48000 ↔ 44100 via Audio MIDI Setup): No effect in my case.
  • pmset sleepnow (sleep/wake cycle): Did not help either.

Key observation

When I killed all audio daemon processes (coreaudiod, audiomxd, audioclocksyncd, etc.) without killing audio client processes first, the audio would recover for approximately 1 second before immediately degrading again. This strongly suggests that one or more audio client processes hold some corrupted state that gets re-applied to the freshly restarted audio stack.

When I killed all processes using CoreAudio (clients + daemons together), audio recovered and remained normal.

What works

Kill all CoreAudio client processes first, then restart all audio daemons:

# 1. Find and kill all user processes that have CoreAudio loaded
lsof 2>/dev/null | grep CoreAudio | awk '{print $2}' | sort -un | xargs kill -9 2>/dev/null

# 2. Kill Xcode/CoreSimulator if running (known to exacerbate the issue)
killall Xcode SimulatorTrampoline com.apple.CoreSimulator.CoreSimulatorService simdiskimaged 2>/dev/null

# 3. Restart all audio daemons (not just coreaudiod)
sudo killall -9 coreaudiod audiomxd audioclocksyncd audioanalyticsd audioaccessoryd AudioComponentRegistrar

See fixaudio.sh for a ready-to-use shell function.

Environment & possible contributing factors

These may or may not be relevant — listed for completeness:

  • macOS Tahoe 26.3 (25D125), Apple M3 MacBook Air
  • Data migrated between machines (Air M3 → Pro M4 Pro → back to Air M3). Migration left behind ghost audio device entries (BlackHole, Zoom virtual device, old Bluetooth devices) in /Library/Preferences/Audio/com.apple.audio.SystemSettings.plist.
  • Bluetooth headphones (Bose QC Ultra 2 HP) frequently connected/disconnected.
  • Xcode and CoreSimulator services running in the background. Multiple community reports indicate Xcode/Simulator can amplify Tahoe audio issues.

Status

This is a workaround, not a root fix. The underlying cause appears to be a bug in macOS Tahoe's CoreAudio stack. Apple has reportedly addressed some audio issues in 26.1, but the problem persists through 26.3 in my environment.

I have not yet identified which specific client app is the primary culprit. The watchdog is running and I'll update this if I find out.

#!/bin/bash
# fixaudio — workaround for macOS Tahoe audio degradation bug
# Kills all CoreAudio clients + all audio daemons to restore normal audio.
#
# Usage: source this file and run `fixaudio`, or add the function to your .zshrc/.bashrc.
# Requires sudo for killing system audio daemons.
fixaudio() {
sudo -v || return 1
local skip="coreaudiod|audiomxd|audioclocksyncd|audioanalyticsd|audioaccessoryd|AudioComponentRegistrar|audio.DriverHelper|audio.SandboxHelper|ParrotAudioPlugin"
echo "=== Audio clients ==="
lsof 2>/dev/null | grep CoreAudio | awk '{print $2, $1}' | sort -t' ' -k1,1 -un | grep -vE "$skip" | while read pid name; do
echo " kill $name ($pid)"
kill -9 "$pid" 2>/dev/null
done
killall Xcode SimulatorTrampoline com.apple.CoreSimulator.CoreSimulatorService simdiskimaged 2>/dev/null
sleep 1
echo "=== Audio daemons ==="
sudo killall -9 coreaudiod audiomxd audioclocksyncd audioanalyticsd audioaccessoryd AudioComponentRegistrar 2>/dev/null
echo " killed all audio daemons"
sleep 2
echo "=== Done. coreaudiod PID: $(pgrep coreaudiod) ==="
}
@tcleveland93-jpg

Copy link
Copy Markdown

Hahahaha

@hberberoglu

Copy link
Copy Markdown

Try to update Xcode to version 26.3 (17C529)

@RealDyllon

Copy link
Copy Markdown

just encountered this on 15.7.4 - the fix still works

@fl034

fl034 commented Mar 27, 2026

Copy link
Copy Markdown

That's too intrusive and slow. It's even closing apps. And after 20mins, the issue is back.
I have done a shortcut to switch audio output from external and internal and back. Fixes it also for 30mins but only interrupts audio for 100ms or so.
I used https://github.com/deweller/switchaudio-osx for this

@fl034

fl034 commented Mar 28, 2026

Copy link
Copy Markdown

@hberberoglu

Copy link
Copy Markdown

Did updating Xcode to version 26.3 (17C529) not work? It worked for me, the problem was solved after the update.

@fl034

fl034 commented Mar 30, 2026

Copy link
Copy Markdown

Nope. Neither Xcode 26.3 nor 26.4 fix it for me. Maybe macOS 26.4 does. Will check.

@mlChrono

mlChrono commented May 4, 2026

Copy link
Copy Markdown

I am on MacOS 26.4.1 with the latest updates, this issue is still happening and the only thing that fixed it was to run the commands from this gist.

@elisatems

Copy link
Copy Markdown

I have this problem after upgrading from Sequoia (15.6.1) to Tahoe 26.5.1 on an M1 MacBook Pro. I do not use Xcode or any simulators (also implicated as triggers for the bug). I have not tried the commands given here, but given that rebooting the machine does not fix it (except temporarily), I don't see how they could possibly offer anything except temporary relief from the distortion.

@elisatems

Copy link
Copy Markdown

I also found (what I assume is) your OP on discussions.apple.com. Other than the fact that I am not currently using Zoom, and my trigger is usually either Apple's Music.app or third party-notation software that generates playback audio, the necessary condition is the same: happens only when audio goes through USB headphones, external speakers and built-ins sound fine. And what you described, a gradual degradation of audio that begins some time after audio starts playing, is identical to what I am experiencing.

I took the liberty of giving the link to your OP on the Apple site to Apple to add to my case as a suspected case of the same problem. Your logs, I think, make clear that the problem is indeed in the Core Audio stack in Tahoe, and also that it is still extant in 26.5.1.

@iamsiddiquek

Copy link
Copy Markdown

MacBook Pro Apple M1 Pro 2021 - 14" macOS Tahoe 26.5 (25F71)

Possible trigger: Before the audio broke, I used Antigravity by Google to scaffold an iOS app. The setup installed Xcode, Swift, and Python on my machine. Audio stopped working shortly after. Worth noting since your script already targets Xcode and SimulatorTrampoline — this may not be a coincidence.

Slightly different symptom from others here: built-in speakers went completely silent out of nowhere — no gradual degradation, just instant silence. Wired headphones developed a continuous ticking noise. Bluetooth headphones work fine.

Notable: Audio MIDI Setup had silently activated the Mute button on MacBook Pro Speakers without any user action — likely a side effect of the same CoreAudio bug.

fixaudio ran successfully (CoreAudio restarted, new PID confirmed) but produced zero improvement — not even 1 second of audio recovery. Tried running it in a loop; still nothing. This suggests the bug manifests differently depending on the machine or macOS build, or that Xcode/Simulator installation leaves behind a persistent CoreAudio client that survives daemon restarts.

Other things that didn't work:

  • NVRAM reset
  • Safe Mode boot (rules out third-party apps running at login)
  • Full macOS reinstall via Recovery Mode
  • Apple Diagnostics (passed — no hardware errors)

Headphones working + diagnostics passing confirms hardware is fine. The CoreAudio driver for the built-in speaker path appears broken at a level that survives even a full OS reinstall on 26.5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment