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: 0xE00002D7default	21:07:04.848855-0500	Music	 HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overloaddefault	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: nodefault	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:54AppleUSBAudio:   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