Jump to content

USB Sound Assertion/Overload


i0ntempest
 Share

42 posts in this topic

Recommended Posts

Guest 5T33Z0

I am using a Focusrite USB Audio Interface and never had any issues with it. That's the benefit of using gear from proven brands who specialize in Pro Audio.

Link to comment
Share on other sites

Well I’m no audio engineer or producer or anything, I just want a decent DAC so I can drive my headphones and enjoy my music. IMHO FiiO has a decent rep in the HiFi world.

Link to comment
Share on other sites

@5T33Z0

OK, I took the time to remap my USB ports, but nope... still have overloads. I'm going to install a fresh copy of macOS on another partition and test there. In the mean time... any other ideas? I've seen other people having similar mentioning disabling the serial port, but there's no option in my BIOS to do that. Maybe you could help me creating an SSDT to do it?

Updated EFI attached.

EFI.zip

Edited by MisakaMikoto0
Link to comment
Share on other sites

Guest 5T33Z0

If you use the Advanced View the setting should be located under Peripherals -> Super I/O. My guess is, if this port would be enabled, macOS wouldn't even boot.

Link to comment
Share on other sites

There isn't even a Peripherals tab in my BIOS... I've checked under Settings -> I/O ports section and it's not there. Pictures in the motherboard manual is showing that tab (must be an older version) but in that tab there's no Super IO.

In ioreg there's also no UAR*, so maybe Z390 Aorus Pro just doesn't have a serial port?

Link to comment
Share on other sites

Guest 5T33Z0

Possible. But I don't know the hardware ID (HID) used in the DSDT to find the serial port to deativate it (if there is one)

 

As far as settings go, open Audio-MIDI-Setup App and change the sample rate from 192 kHz to something more reasonable for consumer audio, such as 48 kHz. If it's a USB 2 Interface, 192 might be too high to be manageably by the bus. Play with the buffersize as well. Maybe lower works better, maybe higher.

 

I don't know much else. With these asian products it's always hard to tell if they were designed to be fully class compliant.

 

Maybe @MacPeet has more insight on the matter.

Edited by 5T33Z0
Link to comment
Share on other sites

I’m no audio expert but this does look like audio buffer size being constantly blown. Is there a way I could adjust audio buffer size systemwide?

Link to comment
Share on other sites

@5T33Z0Turns out the USB audio overload issue is an adverse effect of the new GPU driver bug in macOS 12.3 (discussion). I patched my screen buffer and have not logged any overloads since. Not sure about assertions though, I'll keep observing.

Link to comment
Share on other sites

Okay, still having assertions but the frequency it occurs seems much lower.

default	22:14:01.754849-0400	powerd	Process coreaudiod.273 TurnedOff PreventUserIdleSystemSleep "com.apple.audio.AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14820000:1.context.preventuseridlesleep" age:00:11:15  id:4295006265 [System: PrevIdle DeclUser kDisp]
default	22:14:01.754193-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 920 AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14820000:1 (AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14820000:1): stopping with error 0
default	22:14:01.756069-0400	coreaudiod	[Detector.cpp:85    rtaid::Detector:0x7fa334cacd00] Node usb |900|Output|0 with nodeID 0 already present, replacing it
default	22:14:01.756200-0400	coreaudiod	[Detector.cpp:119   rtaid::Detector:0x7fa334cacd00] Created node usb |900|Output|0 with nodeID 0 - reporting period = 10.000000, sample rate = 192000.000000
default	22:14:01.758234-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 920 AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14820000:1 (AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14820000:1): starting
default	22:14:01.759741-0400	kernel	+- IOAudioEngine[<private>]::resetStatusBuffer()
default	22:14:01.990030-0400	kernel	USB Sound assertion (Resetting engine due to immediate error on feedback) in /AppleInternal/Library/BuildRoots/b19089b6-9308-11ec-ba99-4e67803e3fd9/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/KEXT/AppleUSBAudioDevice.cpp at line 6724

 

Link to comment
Share on other sites

Guest 5T33Z0

Ok. Weird that a GPU driver affects core audio in that way. But at least now you know the reason. You could try to rebuild caches and see if it changes anything. If not, I guess you have to wait for a fix by Apple.

Link to comment
Share on other sites

Alright, I think I should summarize this whole adventure for future reference and in case other people are having the same issues. In the end I was not able to completely eliminate overloads, but now it's rare enough that it doesn't bother me. Assertions seems to be completely gone. These are the things I've done:

1. Manually patched USBX and EC SSDTs

2. Remapped USB ports

3. Used a USB isolator (with an optional power port) to isolate ground noises and also provide more power to the DAC

4. Worked around the new bug in macOS 12.3 that affects 5700/6700/6800/6900 GPUs, this was causing sluggish GUI and HUGE amounts of overloads.

5. Moved some USB devices into other ports. This one is a bit tricky, devices under heavy load can cause problems with USB audio, and some devices seem to cause more overloads than others. In my case it's USB HDDs, especially externally powered ones. Bad power supply giving dirty power can cause more overloads. Devices constantly connecting and disconnecting will also cause overloads and assertions.

 

Again thanks to @5T33Z0 for all the help, I consider this case closed.

Link to comment
Share on other sites

  • 1 month later...

macOS 12.4 seems to have fixed this for good. Maybe they changed something in the audio backend but I can't find any detailed info on it. I can only hope the problem doesn't come back later......

  • Like 1
Link to comment
Share on other sites

  • 2 months later...

I think I have found a way... but it's definately not for everyone and might not even be possible. You'll want to ensure that your USB DAC is the ONLY deviece on a USB controller. In my case I have a Inateck KU5211 PCIe USB card installed in my system, it has two controllers and 5 ports, 4 ports are connected to one controller and the bottom port is connected to the other controller. By connecting my DAC to that port (effectively wasting 9.5Gbps of bandwidth) I was able to reduce the overload and dropout to minimum, not sure if it's eliminated entirely yet. I'll update if it does.

Link to comment
Share on other sites

  • 1 year later...

I’m on the same boat as you… I build my hackintosh a year ago and I can’t get around that issue in any way.

 

Have you solved it or you gave up on hackintosh because of that? I’m like a hair away from selling my hardware and add some money to get a Mac Studio and forget about problems as such. 
 

I have a topic here

Link to comment
Share on other sites

2 minutes ago, panosru said:

selling my hardware and add some money to get a Mac Studio and forget about problems as such.

I’ve done exactly that a year ago. x86 is being ditched by Apple anyways.

Though this audio cutout problem still very occasionally happens, even on real Apple hardware. But it’s rare enough to not bother me.

Link to comment
Share on other sites

I see, yes it is very frustrating… it started to happen like every few seconds for me and became unbearable. Previously it was like once every hour or so. Now I’m thinking how to get 5k for a Mac Studio M2 Ultra 64GB with 1TB of storage. 

Link to comment
Share on other sites

 Share

×
×
  • Create New...