MacBook M1 Pro with USB headphones crackling on Zoom Call after macOS Tahoe upgrade

Yes, I'm on the latest release of MacOS Tahoe 26.1 (25B78).

When I kill `coreaudiod`, the sound in my Zoom meeting goes out for about 2 seconds, then goes back to normal.

After a few minutes the problem comes back, requiring another intervention.

My preferred workaround is to switch to another audio device (MacBook speakers), then back to USB headphones, so that I don't lose 2 seconds of the conversation in the Zoom meeting - which happens if I kill `coreaudiod`.

Another thing I plan to try the next time I have a meeting on this MacBook is raising the nice level of audio-related system processes like this:

sudo renice -5 -p $(pgrep -f /usr/sbin/coreaudiod) $(pgrep -f /usr/libexec/audioclocksyncd) $(pgrep -f /System/Library/Audio/Plug-Ins/usbaudio.bundle/Contents/MacOS/usbaudiod)

So, update from today.

I have raised the nice level of audio-related processes to -5 with this command:

sudo renice -5 -p $(pgrep -f /usr/sbin/coreaudiod) $(pgrep -f /usr/libexec/audioclocksyncd) $(pgrep -f /System/Library/Audio/Plug-Ins/usbaudio.bundle/Contents/MacOS/usbaudiod)

I no longer see the "HALS_OverloadMessage" in unified logs, but the problem still occurs.

I expanded my previous log filter predicate to this in order to find more log messages that are symptomatic of the problem:

log stream --predicate '(eventMessage CONTAINS[c] "audio" || eventMessage CONTAINS[c] "media" || eventMessage CONTAINS[c] "IOSurface" || sender CONTAINS[c] "audio" || subsystem CONTAINS[c] "audio" || process CONTAINS[c] "audio") && NOT process IN {"runningboardd", "airportd"}'

And I think I have caught something interesting, not seen before.

First, during the call while using the USB headphones, log messages saying usbaudiod: current microframe timestamp calcError are constantly being generated at a steady rate.

They look pretty concerning, although initially the audio sounds fine. At some point (usually after a few minutes of running the meeting), this message from libAudioIssueDetector.dylib appears at the exact moment when the crackling starts: coreaudiod: (libAudioIssueDetector.dylib) [com.apple.coreaudio:aid] IssueReporting.cpp:492   RTAID [ use_case=Generic report_type=RMS Generic Chain clientID=HAL node=-Input issue_detected_sample_time=...

Sometimes the message reports node=-Input issue_detected_sample_time (as visible above), but sometimes it reports node=-Output issue_detected_sample_time, and sometimes there are 2 log messages reporting both issue types.

As a subjective observation, the issue seems to be more likely to occur when I switch to a resource-consuming application such as Chrome and do work in there while the call is running, so some system resource utilization congestion might be needed to reproduce this issue.

A few points worth highlighting:

1. This issue does not occur with the built-in MacBook Pro Speakers, only with my USB headphones.
2. I have been using these headphones with this MacBook Pro for a few years now without problems, and I keep using them with Windows - no problems there either. The problem only started on MacOS after the upgrade to Tahoe.

Here are some raw log examples illustrating my comment above: https://gist.github.com/aadamowski/bbe4baab41b676b33d4de4c94efd8025

Providing in the form of a GitHub Gist, because Apple Community does not allow me to post fragments of logs ("You have included content in your post that is not permitted.").

Here are some raw log examples illustrating my comment above: https://gist.github.com/aadamowski/bbe4baab41b676b33d4de4c94efd8025

Providing in the form of a GitHub Gist, because Apple Community does not allow me to post fragments of logs ("You have included content in your post that is not permitted.").

As advised, I have submitted a bug report.

Unfortunately, the feedback submission system did not give me any submission ID/ticket number for follow-up tracking.

I've found an even less invasive workaround - launching the Audio MIDI Setup app, then for the USB Headphones device, in the "Output" tab, I switch back and forth between the two supported sampling rates (48,000 Hz and 44,100 Hz).

This only causes a few hundreds milliseconds gap in the audio I hear, which makes it possible to continue following the conversation.