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

I have a USB audio interface that is causing kernel traps and the audio output to "skip" or dropout every few seconds. This behavior occurs with a completely fresh install of Catalina as well as Big Sur with the stock Music app on a 2019 MacBook Pro 16 (full specs below).

The Console logs show coreaudiod got an error from a kernel trap, a "USB Sound assertion" in AppleUSBAudio/AppleUSBAudio-401.4/KEXT/AppleUSBAudioDevice.cpp at line 6644, and the Music app "skipping cycle due to overload."

I've added a short snippet from Console logs around the time of the audio skip/drop out. The more complete logs are at this gist:

https://gist.github.com/djflux/08d9007e2146884e6df1741770de5105

I've also opened a Feedback Assistant ticket (FB9037528):

https://feedbackassistant.apple.com/feedback/9037528

Does anyone know what could be causing this issue?

Thanks for any help.

Cheers,
Flux aka Andy.



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.80.3.0.0 (iBridge: 18.16.14347.0.0,0)

System Software Overview:

System Version: macOS 11.2.3 (20D91)
 Kernel Version: Darwin 20.3.0
 Boot Volume: Macintosh HD
 Boot Mode: Normal
 Computer Name: mycomputername
 User Name: myusername
 Secure Virtual Memory: Enabled
 System Integrity Protection: Enabled

USB interface: Denon DJ DS1


Snippet of Console logs

Code Block
error 21:07:04.848721-0500 coreaudiod HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7
default 21:07:04.848855-0500 Music HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload
default 21:07:04.857903-0500 kernel USB Sound assertion (Resetting engine due to error returned in Read Handler) in /AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/AppleUSBAudio-401.4/KEXT/AppleUSBAudioDevice.cpp at line 6644
...
default 21:07:05.102746-0500 coreaudiod Audio IO Overload inputs: '<private>' outputs: '<private>' cause: 'Unknown' prewarming: no recovering: no
default 21:07:05.102926-0500 coreaudiod   CAReportingClient.mm:508  message {
  HostApplicationDisplayID = "com.apple.Music";
  cause = Unknown;
  deadline = 2615019;
  "input_device_source_list" = Unknown;
  "input_device_transport_list" = USB;
  "input_device_uid_list" = "AppleUSBAudioEngine:Denon DJ:DS1:000:1,2";
  "io_buffer_size" = 512;
  "io_cycle" = 1;
  "is_prewarming" = 0;
  "is_recovering" = 0;
  "issue_type" = overload;
  lateness = "-535";
  "output_device_source_list" = Unknown;
  "output_device_transport_list" = USB;
  "output_device_uid_list" = "AppleUSBAudioEngine:Denon DJ:DS1:000:1,2";
}: (null)

I see the exact same thing over here, it's maddening.
I guess it’s good to hear it’s not just me having the issue.

My Feedback Assistant ticket got a reply last week and I have submitted some kernel traces to the ticket per request. I consider that progress. I’ll post any updates I receive as replies to this thread.

Thanks for the reply.
I'm experiencing the exact same issue and error code. It's driving me insane..
I've also opened a Feedback (FB9084336) regarding this.
I have a feeling there are many experiencing this issue. Again, glad to see it's not just me. I added your FB number in as a comment to my FB case.

For anyone reading, if you have a Feedback Assistant case open, please post it here and I'll add it to my case.

Thanks for the reply.
For those having similar issues to this one, it appears that Big Sur 11.3 (or a change to the Boot ROM/iBridge, or something else) has lessened the frequency of drop outs for my hardware. It's still not perfect, but a little better. The drop outs only occur for about 0.03 secs where before they were much longer.

Connection path:

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

Here's my config:

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

Hi guys, I'm having the exact same problem:

 HALS_IOA1Engine::EndWriting: got an error from the kernel trap, Error: 0xE00002D7

I'm using the new MBA M1 2020 and a Presonus Audiobox Studio 24c USB interface.

The stutter it's driving me crazy, I don't know what to do.

My FA number is this: FB9099507
Ok, the audio seems to work fine using an USB cable directly to the interface, I was using a USB hub before.
NVM, it keeps happening but less often directly through USB.
@rafablues94 same with me. The dropouts are less frequent and for a shorter duration with 11.3 and newer iBridge firmware, but they are still occurring.

Not sure if it’s good, but interesting to know that this item is not just happening on Intel Macs.

Thanks for the reply. Cheers.

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!

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