Jump to content
Sign in to follow this  
Followers 0
Haive_Music

USB Overload / Dropouts (USB Sound assertion, Overload, Kernel errror, AppleUSBAudioDevice)

6 posts in this topic

Recommended Posts

Hey Guys,

I'm battling my last remaining issue on my Hackintosh build, and it's a puzzling one.

 

I've suspected there's still something just 'not quite right' with my USB for a while now, but I haven't really been able to pinpoint anything specifically, other than having a hunch, ... until now.

 

 

This issue seems to happen when working with audio. It doesn't happen non-stop, but frequently enough that it's annoying. Basically what happens is occasionally, and seemingly randomly, audio just drops out for 1ms, then comes back.

I can't seem to find a correlation of what causes the issue. I've tried different sample rates, as well as different USB Audio Interfaces.  Onboard audio is completely disabled, and BIOS is upgraded to the latest firmware.  Searching around, I've found a lot of issues related to people running into similar issues with on-board audio, but found nothing helpful or relevant specifically to USB audio interface problems (AppleUSBAudioDevice), except for one guy who had his graphics card installed in the incorrect slot (I don't). 

 

I finally managed to capture some logs of this and have attached them below, along with a copy of my Clover config in case it's applicable.

 

 

I'm nearly about ready to try another motherboard, but.... I'd really hard to do that if it won't resolve the issue, especially since everything else seems to be working finally.

 

 

Thanks for any help anyone can offer. 

 

 

error    23:35:13.794035 -0400    coreaudiod    HALS_IOA1Engine.cpp:312:EndReading:  HALS_IOA1Engine::EndReading: got an error from the kernel trap, Error: 0xE00002D7
default    23:35:13.794254 -0400    Live    HALC_ProxyIOContext.cpp:1068:IOWorkLoop:  HALC_ProxyIOContext::IOWorkLoop: skipping cycle due to overload
default    23:35:13.870976 -0400    coreaudiod    HALS_OverloadMessage.cpp:159:perform:  Audio IO Overload inputs: 'AppleUSBAudioEngine:Focusrite:Clarett 8Pre USB:567:1,2' outputs: 'AppleUSBAudioEngine:Focusrite:Clarett 8Pre USB:567:1,2' cause: 'Unknown' prewarming: no recovering: no
default    23:35:13.920695 -0400    kernel    USB Sound assertion (Resetting engine due to immediate error on read) in /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/AppleUSBAudio-312.6/AppleUSBAudioDevice.cpp at line 6199
default    23:35:14.048899 -0400    kernel    USB Sound assertion (Input Fell Behind) in /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/AppleUSBAudio-312.6/AppleUSBAudioDevice.cpp at line 6185


 

config.plist

Screen Shot 2018-09-14 at 1.01.20 AM.png

Screen Shot 2018-09-15 at 1.30.27 AM.png

Edited by Haive_Music

Share this post


Link to post
Share on other sites
Advertisement

Sadly, no.  I take it you must be experiencing the same issue too?  Sad.  I really wish I knew what was causing this issue.

 

I did however, semi-work around this issue (note, semi-workaround).

 

 

I built this machine specifically for audio production, so it sucked dealing with it.  I finally gave up, sold my USB interface, and actually went back to a Thunderbolt interface.  I managed to get a thunderbolt add-on card that was compatible with my motherboard working just well enough to support the Thunderbolt audio interface.  Overall, the problem is resolved to the point where I can actually reliably work in my DAW without experiencing dropouts.  However, often, if I go into any other application while the audio in the DAW is running (say, chrome or something), the audio starts to drop out and have issues.  I'm really not sure what the underlaying problem that causes these types of issues is, but I *never* had these problems on my real mac, working on the exact same thunderbolt interface, on the exact same project files, and sadly, this Hackintosh is far more powerful and in every way superior hardware wise to that of my legit 2013 Mac Pro.  My guess is, there's still some kind of a underlaying driver issue, or perhaps something within Clover that still isn't tweaked properly, although I've tried everything I could think of for months before going back to a Thunderbolt interface.

 

As I said though, it's not without it's issues.  For one, the issue technically still is there when switching apps.  Sometimes audio does weird things on my system.  The other thing is I gave up having hotplug Thunderbolt support AND an otherwise perfectly functioning Sleep.  Both my computer and my audio interface now remain turned on 24/7, which....truly isn't ideal.  However, I'll take those workarounds over going back to older legit Mac Hardware, having the ability to dual boot, and otherwise having a mostly perfectly functioning Hackintosh.

Share this post


Link to post
Share on other sites
On 3/28/2019 at 12:21 AM, tkddkt said:

How about using 10.9.5 AppleUSBAudio.kext ?

 

 

Interesting idea.  I haven't tried this yet and just did.  Initial results are mixed.  

 

It seems that it resolves the audio dropout error issue I was having.  However, it's introduced a side effect in doing so.

 

 

I personally don't notice this issue much anymore after switching to the Thunderbolt Interface, the issue is that it still affects other aspects of the audio sub system.  For instance, if I stream to Twitch using OBS, even though I'm hearing stutter-free audio, the audio feed sent out to Twitch is now (instead of doing random drop outs), it's almost like it records and streams cleanly for 2-3 seconds, and then it starts almost looping/delaying back into it self "click click click click click" and the clicking noises progressively get faster and louder as time goes on.  It's like a backfeed or something.  

 

 

It's interesting.  The problem itself seems directly related to the USB Audio subsystem of OSX.  It's really annoying.

 

Share this post


Link to post
Share on other sites

Today I ended up re-enabling my front case ports (USB 2.0 ones) and trying to use those with the original version of the AppleUSB kext.  Problem definitely seems improved, and I can utilize the USB input.  For some reason, the problem seems to revolve around using the USB 3.0 ports on the board.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.

×