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

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?

Hi, I had the same issues. I have Pioneer console for Serato and one day I got random dropouts when whole computer is stuck having 100% cpu for 1-3s before continuing. There is also "got an error from the kernel trap" error in the console everytime this happens.

I found out that i my case the power connector/socket was the problem. There are pins on the computer side connecting to the magnetic power connector and one of the pins was bent in a way that I think in some cases didnt make correct connection. I assume also dirt or whatevel else blocking good contact can cause this.

I bent the pin to the correct connection and everything is fine now...

Experiencing this issue with a 2021 M1 Pro on Venture 13.2 using a Schiit Modi USB DAC. Every time audio cuts out I see one of these two logs for coreaudiod in Console:

HALS_OverloadMessage.cpp:267   HALS_OverloadMessage: Overload due to HAL client proc exceeding io cycle budget
HALS_IOA1Engine.cpp:439    HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7

Same problem here, for years, on various MacBooks with RME UCX interface over USB. Now using M1 Pro, latest OS, same problem. Can't believe Apple haven't fixed this - my bloody iPad has more reliable audio.

Tried emailing RME support about it but they just say "it's an Apple problem - users on Linux or Windows don't have it". Maddening!

Anyone from Apple actually read these forums? Anyone got anywhere with Apple support? Last time I tried they were all about resetting CMOS or something, but M1 Macs don't even have that!

Here's my log snippet FWIW. Experiencing audio dropouts, seemingly related to USB audio interface.

error 20:32:12.329960-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330010-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330049-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330054-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330077-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330082-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330111-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330113-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330141-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330146-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330171-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330174-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330212-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330215-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee error 20:32:12.330241-0400 kernel AppleUSBXHCIIsochronousTransferRing: AppleUSBXHCIIsochronousTransferRing::enqueueRequest: request <private> link failed with 0xe00002ee error 20:32:12.330245-0400 kernel AppleT6000USBXHCI@00000000: AppleUSBHostController::io: request <private> completed with 0xe00002ee default 20:32:12.396994-0400 kernel + IOAudioEngine[<private>]::pauseAudioEngine()

Same problem here. Constant glitches with usb interfaces. M1 Pro 16'' with 16gb of ram. I have RME UCX, RME UCX II, NI Komplete Audio 2. All interfaces are basically unusable with this computer.

When i use M1 Air base model, no glitches.

So far nothing has worked (tried every solution found from internet)

I hope apple releases some information because so far haven't seen any comments on this issue from them.

Anybody want to take the plunge on macOS 14 DP 1 and see if this issue is resolved?