What causes "issue_type = overload" in coreaudiod with USB audio interface?

DS1 --> CalDigit TS3+ Thunderbolt hub --> MBP16

Code Block 
Hardware Overview:
  Model Name:	MacBook Pro
  Model Identifier:	MacBookPro16,1
  Processor Name:	8-Core Intel Core i9
  Processor Speed:	2.4 GHz
  Number of Processors:	1
  Total Number of Cores:	8
  L2 Cache (per Core):	256 KB
  L3 Cache:	16 MB
  Hyper-Threading Technology:	Enabled
  Memory:	64 GB
  System Firmware Version:	1554.100.64.0.0 (iBridge: 18.16.14556.0.0,0)
System Software Overview:
 
  System Version:        macOS 11.3 (20E232)
  Kernel Version:        Darwin 20.4.0
  Boot Volume:        Macintosh HD
  Boot Mode:        Normal
  Computer Name:        mymbp16
  User Name:        myusername
  Secure Virtual Memory:        Enabled
  System Integrity Protection:        Enabled
  Time since boot:        1 day 15:54
AppleUSBAudio:
 
  Version:        405.39
  Last Modified:        1/1/20, 2:00 AM
  Bundle ID:        com.apple.driver.AppleUSBAudio
  Notarized:        Yes
  Loaded:        Yes
  Get Info String:        AppleUSBAudio 405.39, Copyright © 2000-2021 Apple Inc. All rights reserved.
  Obtained from:        Apple
  Kind:        Universal
  Architectures:        arm64e, x86_64
  64-Bit (Intel):        Yes
  Location:        /System/Library/Extensions/AppleUSBAudio.kext
  Kext Version:        405.39
  Load Address:        18446743522231001000
  Loadable:        Yes
  Dependencies:        Satisfied
  Signed by:        Software Signing, Apple Code Signing Certification Authority, Apple Root CA

I have the same problem on my MBP M1 connected to a M-Audio 192/6. I have to restart the machine to make it work. Terrible experience.

This issue developed on a 2020 5K iMac after I updated to Monterey 12.0.1 public release, then to the 12.1 Beta, then did a full wipe and a clean reinstall of Big Sur 11.6.1. Never had it before (this iMac shipped with Catalina and I updated to Big Sur without doing a clean install).

In my case it starts happening on the second or third day after a restart. Once it starts happening, if I unplug the USB audio interface, the whole computer locks up and needs a hard reset.

Same problem here with a 2021 M1 Pro Macbook Pro and Monterey 12.2.1.

Granted, it's a complicated use case, I use a FiiO K3 plugged to a USB 3.0 KVM plugged to a USB-C Hub. But I have two computers at home and I thought that sharing the audio between my desktop and my laptop would be easier (and it's almost the only way to share USB audio between both machines). Never had a problem with Windows.

The sound is fine after killing coreaudiod and starts degrading after a few minutes of playback. The logs show the same errors some of you have reported:

error	10:10:07.009105+0100	coreaudiod	 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002EE
error	10:10:07.331413+0100	coreaudiod	 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7
error	10:10:07.334532+0100	coreaudiod	[DetectorNode.cpp:278   rtaid::DetectorNode:0x108b11e80] CheckAnalyzer/AnalyzeABL called concurrently at usb |34|Output|0
error	10:10:07.334554+0100	coreaudiod	 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7
error	10:10:07.334634+0100	coreaudiod	 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7

The promise of USB-C being great to use everything with a single cable seem to have a few pitfalls.

This issue remains in macOS Monterey 12.3 and is easily reproduced with no foreground apps open except Plexamp by enabling the "Shake mouse pointer to locate" Accessibility option (this setting only makes it easier to reproduce on demand):

• MacBook Pro (13-inch, 2020, Four Thunderbolt 3 ports) → CalDigit TS4 → Schiit Modi 3+
• Issue disappears with the same USB-C cable but MBP → Schiit Modi 3+ directly

Same problem on upgrading to Macbook Pro M1 Pro from my old 2016 Macbook Pro. I'm using Behringer XR18 over USB through a hub, Dual monitors 1xHDMI, 1xUSB C Also got a webcam (Logitec 920) and a hard drive on USB via the monitor's hub. This all worked fine before I upgraded to this new superpowered Macbook!

Same have FireFace UCX II, direct or via hub still gliches it's mad!

Specs: 16" MacBook Pro, M1 Max, 32GB ram

This issue is absolutely killing me. I'm unable to watch a YouTube video without dropouts using my USB -> S/PDIF converter. Also getting these dropouts when using the built-in speakers.

Also getting dropouts when recording using an RME-ADI 2 Pro FS connected directly to the MBP using a USB-C -> USB-A adapter.

Happens often when using Anker Thunderbolt 4 hub, however the issue is reproducible with USB -> S/PDIF converter connected directly to MBP using short USB-C -> USB-A adapter.

Audio device is "XMOS HIFI DSD"

default	12:06:19.804922-0400	coreaudiod	     CAReportingClient.mm:480   stopping (
    1748051689507
)
default	12:06:19.805032-0400	coreaudiod	     CAReportingClient.mm:508   message {
    "session_duration" = "6.851477980613708";
}: (
    1748051689507
)
default	12:06:19.805656-0400	coreaudiod	 IO Stopped Context 7823 after 0 frames.
default	12:06:19.805748-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 7823 AppleUSBAudioEngine:XMOS :HIFI DSD:2130000:1 (AppleUSBAudioEngine:XMOS :HIFI DSD:2130000:1): stopping with error 0
default	12:06:19.806476-0400	coreaudiod	 HALC_IOContext_PauseIO(7822)
default	12:06:19.806807-0400	coreaudiod	 HALB_PowerAssertion::Release: releasing power assertion ID 35239 of type '<private>' with name: '<private>' on behalf of 8657
default	12:06:19.808996-0400	coreaudiod	 HALC_ProxyIOContext::PauseIO: -> 0 0 id:7822 called from <private>
default	12:06:19.809264-0400	coreaudiod	 HALC_ProxyIOContext::PauseIO: <- 0 1 id:7822
default	12:06:19.809541-0400	coreaudiod	 HALS_IOA1Device::_HandleMajorEngineChange: but nothing changed
default	12:06:19.809743-0400	coreaudiod	 HALB_IOThread::_Stop: Attempt to stop a thread that was not created or has already exited.
default	12:06:19.809781-0400	coreaudiod	[Detector.cpp:85    rtaid::Detector:0x109d82130] Node usb |7803|Output|0 with nodeID 0 already present, replacing it
default	12:06:19.810827-0400	coreaudiod	[Detector.cpp:119   rtaid::Detector:0x109d82130] Created node usb |7803|Output|0 with nodeID 0 - reporting period = 10.000000, sample rate = 44100.000000
default	12:06:19.804610-0400	Messages	 HALC_IOContext_PauseIO(7816)
default	12:06:19.804833-0400	Messages	 HALC_ProxyIOContext::PauseIO: -> 0 0 id:7816 called from <private>
default	12:06:19.811333-0400	coreaudiod	[NodeFormatConverter.cpp:61    rtaid::NodeFormatConverter:0x10b6d2eb0] AudioConverterNew succeeded with incoming format  2 ch,  44100 Hz, Float32, interleaved and outgoing format  2 ch,  44100 Hz, Float32, deinterleaved
default	12:06:19.804872-0400	Messages	 HALC_ProxyIOContext::PauseIO: <- 0 1 id:7816

Same thing happening over here as well; I have 2 older MacBook Pros (2014, and 2019) which don't exhibit these issues, but the new M1 Pro MacBook Pro is driving me insane with audio dropouts and glitches on an USB Scarlett 2i2 as well as the internal speakers.

Connecting the USB device directly or via the hub does little to nothing, dropouts persist. Killing coreaudiod also doesn't do anything.

What I've noticed is that, after a reboot, it's slightly more stable, and gradually goes from 1-2 times a minute to 10-15 times per minute over the course of the day.

I've attached the related coreaudiod console logs to some of the dropouts happening.

It seems that the issue is caused by RAM usage as describing here https://old.reddit.com/r/macbookpro/comments/vluqp9/psa_suffering_from_your_m1_macbook_pro_making/

I tested it myself and my usb audio dropping occurred exactly when the memory pressure turned to yellow.

Same issue happening over here as well. Have had multiple intel based Macbook pros lately and this M1 Macbook Pro 14" is the first where the annoying issue persists. My previous work laptop (intel based 2018 Macbook Pro) was hitting more memory pressure than this new M1 mac but never had audio issues. I cannot listen to music while working anymore...

What's wrong with Apple nowadays? More and more annoying issues in computers we pay thousands of euros.

Same thing happening to me, M1 Pro MacBook 16" with an external USB DAC. Similar log entries as above:

Audio IO Overload thread: 773922 inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no

Does seem to improve if I reduce memory pressure, but that's not a workable long term solution, I get yellow memory pressure from firing up all the tools I need.

Experiencing the same issues here on a 2021 MBP (M1 Pro), 32GB memory, running macOS 12.6.1. If this truly is a memory issue, it's maddening the CoreAudio daemon can't request more memory to satisfy its buffer.

The logs I captured share the same story as everyone else, but here are the redacted logs (attached) if anyone else wants to see them.

Full logs here:

The important tidbit:

default 11:48:12.767285-0600    coreaudiod       CAReportingClient.mm:508   message {
    "HAL_client_IO_duration" = 14125;
    HostApplicationDisplayID = "com.spotify.client";
    cause = PageFaultsOffIOThread;
    deadline = 94228159;
    "input_device_source_list" = Unknown;
    "input_device_transport_list" = USB;
    "input_device_uid_list" = "AppleUSBAudioEngine:miniDSP:miniDSP 2x4HD:0:1,2";
    "io_buffer_size" = 512;
    "io_cycle" = 184033;
    "io_cycle_budget" = 2713583;
    "io_page_faults" = 0;
    "is_prewarming" = 0;
    "is_recovering" = 0;
    "issue_type" = overload;
    lateness = "-509";
    "other_active_clients" = "[  ]";
    "other_page_faults" = 70;
    "output_device_source_list" = Unknown;
    "output_device_transport_list" = USB;
    "output_device_uid_list" = "AppleUSBAudioEngine:miniDSP:miniDSP 2x4HD:0:1,2";
    "safety_violation" = 0;
    "sample_rate" = 192000;
    "scheduler_latency" = 8500;
    "smallest_buffer_frame_size" = 512;
}: (
    402601644392452
)

happening for me too on my MacPro 5,1 with a Xonar HDAV1.3 Deluxe PCI-E sound card.

going to get an RCA cable to see if i get sound like the rest of you.

my box has 128GB memory so i don't think it's a memory issue.

it is more likely something to do with the format parameters and an imprecise bytes-to-frames calculation.

i know mine need tweaking for this SPIFFY PCI EXPRESS SOUND CARD ON MY MACINTOSH

I'm having this issue for years, especially after 2018 Macbooks. My current setup: 2021 Macbook Pro 14" M1 Pro 16GB RAM Traktor Kontrol S2 MK3 connected with USB to USB-C from CableMatters ( also tried with various cables and USB-C hubs ) Here are logs at exact moment that audio dropped

error	11:16:15.609358+0300	coreaudiod	 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7
default	11:16:15.625699+0300	coreaudiod	 HALC_IOContext_PauseIO(236077)
default	11:16:15.626461+0300	coreaudiod	 HALC_IOContext_PauseIO(236784)
default	11:16:15.626589+0300	coreaudiod	 HALC_ProxyIOContext::PauseIO: -> 0 0 id:236784 called from <private>
default	11:16:15.626605+0300	coreaudiod	 HALC_ProxyIOContext::PauseIO: <- 0 1 id:236784
default	11:16:15.626542+0300	coreaudiod	 HALC_ProxyIOContext::PauseIO: -> 0 0 id:236077 called from <private>
default	11:16:15.626715+0300	coreaudiod	 HALC_ProxyIOContext::PauseIO: <- 0 1 id:236077
default	11:16:15.635833+0300	coreaudiod	     CAReportingClient.mm:504   Stopping { careporter_id=2731599218817 }
default	11:16:15.658449+0300	coreaudiod	     CAReportingClient.mm:537   Sending message { message="{
    "session_duration" = "79.47630107402802";
}", reporters="(
    2731599218817
)" }
default	11:16:15.658963+0300	coreaudiod	 IO Stopped Context 236814 after 1024 frames.
default	11:16:15.659142+0300	coreaudiod	 HALS_IOContext_Legacy_Impl::IOWorkLoopDeinit: 236814 AppleUSBAudioEngine:Native Instruments:Traktor Kontrol S2 MK3:E27CE236:1,2 (AppleUSBAudioEngine:Native Instruments:Traktor Kontrol S2 MK3:E27CE236:1,2): stopping with error 0
default	11:16:15.659240+0300	coreaudiod	 HALB_PowerAssertion::Release: releasing power assertion ID 39291 of type 'PreventUserIdleSystemSleep' with name: 'com.apple.audio.AppleUSBAudioEngine:Native Instruments:Traktor Kontrol S2 MK3:E27CE236:1,2.context.preventuseridlesleep' on behalf of 62302 taken at <private> for 79.480554 seconds
default	11:16:15.649364+0300	coreaudiod	 index: 0, start: 0x5c7f612a51a5, duration: 0x115, fault address: 0x127c28000, fault pc: 0x1aff076ac, faulting TID: 0xf6fee0, fault type: 0x9, PID: 0x27c
default	11:16:15.677856+0300	coreaudiod	 index: 1, start: 0x5c7f612a52ed, duration: 0xbd, fault address: 0x127c9c000, fault pc: 0x1adcf7fcc, faulting TID: 0xf6fee0, fault type: 0x9, PID: 0x27c
default	11:16:15.678823+0300	coreaudiod	 index: 2, start: 0x5c7f612a53c3, duration: 0x32, fault address: 0x127c9c000, fault pc: 0x1ade11ed8, faulting TID: 0xf6fee0, fault type: 0x4, PID: 0x27c
default	11:16:15.700464+0300	coreaudiod	 index: 3, start: 0x5c7f612a544c, duration: 0xc6, fault address: 0x131268000, fault pc: 0x1adcc4078, faulting TID: 0xf6fee0, fault type: 0x9, PID: 0x27c
default	11:16:15.700486+0300	coreaudiod	 index: 4, start: 0x5c7f612a5a59, duration: 0x69, fault address: 0x126d20000, fault pc: 0x1adcfcf90, faulting TID: 0xf6fee0, fault type: 0x9, PID: 0x27c
default	11:16:15.712676+0300	coreaudiod	 HALS_IOA1Device::_HandleMajorEngineChange: but nothing changed
default	11:16:15.712917+0300	coreaudiod	[Detector.cpp:92    rtaid::Detector:0x126fb53e0] Node usb -Output with nodeID 0 already present, replacing it
default	11:16:15.713002+0300	coreaudiod	     CAReportingClient.mm:537   Sending message { message="{
    "issue_detected_sample_time" = "3811944.000000";
    node = "usb -Output";
    peak = "-3.304815";
    "report_type" = RMS;
    rms = "-16.722528";
    "rtaid_client" = HAL;
}", reporters="(null)" }
default	11:16:15.713114+0300	coreaudiod	IssueReporting.cpp:481   RTAID [ use_case=Generic report_type=RMS Generic Chain clientID=HAL node=usb -Output issue_detected_sample_time=3811944.000000 ] -- [ -16.722528, -3.304815 ]
default	11:16:15.713249+0300	coreaudiod	[Detector.cpp:126   rtaid::Detector:0x126fb53e0] Created node usb -Output with nodeID 0 - reporting period = 10.000000, sample rate = 48000.000000
default	11:16:15.713383+0300	coreaudiod	[Detector.cpp:92    rtaid::Detector:0x126fb53e0] Node usb -Input with nodeID 1 already present, replacing it
default	11:16:15.713510+0300	coreaudiod	[Detector.cpp:126   rtaid::Detector:0x126fb53e0] Created node usb -Input with nodeID 1 - reporting period = 10.000000, sample rate = 48000.000000
default	11:16:15.714014+0300	coreaudiod	[NodeFormatConverter.cpp:61    rtaid::NodeFormatConverter:0x127888160] AudioConverterNew succeeded with incoming format  2 ch,  48000 Hz, Float32, interleaved and outgoing format  2 ch,  48000 Hz, Float32, deinterleaved
default	11:16:15.714488+0300	coreaudiod	[NodeFormatConverter.cpp:61    rtaid::NodeFormatConverter:0x1274d6480] AudioConverterNew succeeded with incoming format  4 ch,  48000 Hz, Float32, interleaved and outgoing format  4 ch,  48000 Hz, Float32, deinterleaved
default	11:16:15.714612+0300	coreaudiod	[Detector.cpp:54    rtaid::Detector:0x126fb53e0] initialized with error = 0
default	11:16:15.715305+0300	coreaudiod	 Audio IO Overload thread: f6fee0 inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no
.
.
.

I googled the error and found this thread. Thank you for posting it. There's a reddit post that links here, too.

I am experiencing this issue on a 2018 MacBook Pro (T2, Intel Core i7) running macOS 12.6 Monterey. The Mac needs to be running continuously for a LONG time before the issue starts to occur. My Mac's uptime is about 75 days right now. All applications using audio are affected when the default device is the external USB adapter. The issue goes away immediately if I switch to something else, like the internal speakers.

Examples of aberrant behavior:

• Teams hangs for 30 seconds while starting a call and becomes unresponsive
• Videos in Safari will freeze, then "catch up", then freeze, and repeat every 3-5 seconds.
• Apple Music plays for about 3 seconds then goes silent.

I am using a CalDigit TS3+ docking station and the USB device in question is a simple headset/mic adapter branded UGREEN. I bought it from Amazon.

According to Audio MIDI Setup, my present audio configuration for the USB device is 16bit, 2 channel, 48kHz.

So far I have tried:

• Killing the coreaudiod service
• Quitting / relaunching the affected apps
• Unplugging / reconnecting the USB device
• Plugging the USB device directly into the Mac (bypassing the hub)
• Changing the sample rate from 48kHz to 44kHz.

None of these actions improved the behavior.

I made an interesting discovery: every time I killed coreaudiod, my primary external monitor went blank for about two seconds. The primary monitor is a Dell 4K connected via the CalDigit TS3+ hub's DisplayPort output. My secondary external monitor, however, did not go blank when killing coreaudiod. That monitor is also DisplayPort, but connected via a Thunderbolt > DisplayPort adapter on the CalDigit TS3+. I can repeat this behavior with coreaudiod ad nauseam and have been gathering a sysdiagnose as I write this.

The USB audio device in question is an inexpensive UGREEN branded headset/mic adapter that I bought from Amazon. According to System Profiler, the vendor ID is Realtek Semiconductor (0x0bda) and the Product ID is 0x4809. What are your USB audio device's vendor and product IDs? Have we found any in common?

There's a slightly different yet similar error when recording or monitoring audio, even if you're just watching the Input tab in System Preferences:

2023-01-09 15:24:56.298594-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 49, start: 0x1768beb4151d25, duration: 0x5d6, fault address: 0x7fd07175c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4
2023-01-09 15:24:56.298625-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 50, start: 0x1768beb55a781e, duration: 0x178b, fault address: 0x7fd07173b000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4
2023-01-09 15:24:56.298648-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  index: 51, start: 0x1768beb55a9515, duration: 0x6d6, fault address: 0x7fd07174c000, fault pc: 0x7ff80f17f28f, faulting TID: 0x3ee1bb9, fault type: 0x9, PID: 0x296ea4

[...repeated several times...]

2023-01-09 15:24:56.300733-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (CoreAudio)  Audio IO Overload thread: 3ee24c4 inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no
2023-01-09 15:24:56.301066-0800 0x3edf369  Default     0x0                  34738  0    coreaudiod: (libAudioStatistics.dylib) [com.apple.coreaudio:carc]      CAReportingClient.mm:508   message {
    "HAL_client_IO_duration" = 100285;
    HostApplicationDisplayID = "com.apple.systempreferences";
    cause = PageFaultsOffIOThread;
    deadline = 48268;
    "input_device_source_list" = Unknown;
    "input_device_transport_list" = USB;
    "input_device_uid_list" = "AppleUSBAudioEngine:Generic:USB Audio:00:1";
    "io_buffer_size" = 512;
    "io_cycle" = 413;
    "io_cycle_budget" = 5222463225846134107;
    "io_page_faults" = 0;
    "is_prewarming" = 0;
    "is_recovering" = 0;
    "issue_type" = overload;
    lateness = 38718;
    "other_active_clients" = "[ { HostApplicationDisplayID_other_client: com.apple.systempreferences, sample_rate_other_client: 0.000008, io_buffer_size_other_client: 512 } ]";
    "other_page_faults" = 52;
    "output_device_source_list" = "";
    "output_device_transport_list" = "";
    "output_device_uid_list" = "";
    "safety_violation" = 0;
    "sample_rate" = 48000;
    "scheduler_latency" = 54208;
    "smallest_buffer_frame_size": <decode: missing data>

Since this is my work laptop, I filed a case with AppleCare for Enterprise and included a sysdiagnose after the problem was occurring, and also another taken while reproducing the issue, so that the diagnostics will capture memory footprints, spindumps, etc., of the affected process.

I'm hoping we all get to the bottom of this soon.

What about Ventura? Has anyone with this issue seen an improvement there?