Jump to content

USB Sound Assertion/Overload

i0ntempest

By i0ntempest,
in OSx86 12.0 (Monterey)

 Share
42 posts in this topic

Recommended Posts

i0ntempest
i0ntempest
Posted
Posted

Hi all,

I have been using my hackintosh for about a year and there's one issue I haven't been able to solve: when using a USB DAC audio occationally drops for half a second and then resumes. This is what appears in the log: 

default	00:22:58.381993-0400	Boom 3D	 HALC_ProxyIOContext::ResumeIO: <- 1 0 id:349
default	00:22:58.454016-0400	kernel	USB Sound assertion (Output Fell Behind) in /System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/AppleUSBAudio-412.8/KEXT/AppleUSBAudioDevice.cpp at line 6767
default	00:22:58.454025-0400	kernel	USB Sound assertion (Resetting engine due to immediate error on feedback) in /System/Volumes/Data/SWE/macOS/BuildRoots/b8ff8433dc/Library/Caches/com.apple.xbs/Sources/AppleUSBAudio/AppleUSBAudio-412.8/KEXT/AppleUSBAudioDevice.cpp at line 6794

and: 

default	00:22:58.321002-0400	coreaudiod	     CAReportingClient.mm:508   message {
    HostApplicationDisplayID = "com.globaldelight.Boom3D";
    cause = PageFaultsOnIOThread;
    deadline = 225790675;
    "input_device_source_list" = "";
    "input_device_transport_list" = "";
    "input_device_uid_list" = "";
    "io_buffer_size" = 512;
    "io_cycle" = 440984;
    "io_page_faults" = 2;
    "is_prewarming" = 0;
    "is_recovering" = 0;
    "issue_type" = overload;
    lateness = 143;
    "other_page_faults" = 0;
    "output_device_source_list" = Unknown;
    "output_device_transport_list" = USB;
    "output_device_uid_list" = "AppleUSBAudioEngine:FiiO:K3:0:1";
    "sample_rate" = 192000;
    "smallest_buffer_frame_size" = 512;
}: (
    1120986464258
)

I have read multiple posts describing similar or identical issues but there's no definitive solution. I found suggestions to disable serial port (Super IO) in BIOS, but the current BIOS of the Gigabyte MB I'm using has no such options, so I'm not sure if it is enabled or even exist on my system. I have attached the complete log, and my DSDT extracted using SSDTime, if needed I'll attach my full EFI folder. Thanks for any help!

 

Complete parts list: https://pcpartpicker.com/list/s36V6r

USB audio shit.log DSDT.aml

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted
8 minutes ago, 5T33Z0 said:

Uninstall Boom3D. Use this tool to do it:

https://www.globaldelight.com/boom3d/mas-content/uninstall.php

 

Restart. Monitor the behavior.

 

If you need to boost the audio output, you can use rogue amoeba sound source instead.

 

 

Ah you reached me before I try contacting you… thanks.

Actually Boom 3D was the first thing I suspected when I discovered this problem, and I tried removing it a few months ago, it didn’t fix anything. But I’ll try again now and report back.

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

Seems that it is still active. That's why the uninstaller is necessary. Tools like Boom 3D usually install additional files on the system.

 

I used Boom 3D a long time ago on my MacBookPro and busted one of the speakers.

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted (edited)
20 hours ago, 5T33Z0 said:

Seems that it is still active. That's why the uninstaller is necessary. Tools like Boom 3D usually install additional files on the system.

 

I used Boom 3D a long time ago on my MacBookPro and busted one of the speakers.

No I mean I did use the uninstaller last time, but since nothing changed I installed it back. I’ll try the software you recommended and see if it offers comparable boost.

Edited by MisakaMikoto0
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

I got something new. This seems to be related to CPU usage as well, when the CPU is under heavy load the audio goes completely crackeled the console gets flooded with: 

     CAReportingClient.mm:508   message {
    HostApplicationDisplayID = "com.apple.WebKit.GPU";
    cause = PageFaultsOffIOThread;
    deadline = 31765835;
    "input_device_source_list" = "";
    "input_device_transport_list" = "";
    "input_device_uid_list" = "";
    "io_buffer_size" = 512;
    "io_cycle" = 16707;
    "io_page_faults" = 0;
    "is_prewarming" = 0;
    "is_recovering" = 0;
    "issue_type" = overload;
    lateness = 387;
    "other_page_faults" = 12;
    "output_device_source_list" = Unknown;
    "output_device_transport_list" = USB;
    "output_device_uid_list" = "AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:000:1";
    "sample_rate" = 192000;
    "smallest_buffer_frame_size" = 512;
}: (
    1125281431557
)

The weird thing is this only occur with Safari.

This is with Boom3D disabled (though still installed). I'll try uninstalling it now.

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted (edited)

Captured it happening with Apple Music as well: 

     CAReportingClient.mm:508   message {
    "HAL_client_IO_duration" = 34390;
    HostApplicationDisplayID = "com.apple.Music";
    cause = PageFaultsOffIOThread;
    deadline = 26905719;
    "input_device_source_list" = "";
    "input_device_transport_list" = "";
    "input_device_uid_list" = "";
    "io_buffer_size" = 512;
    "io_cycle" = 2;
    "io_cycle_budget" = 2713522;
    "io_page_faults" = 0;
    "is_prewarming" = 0;
    "is_recovering" = 0;
    "issue_type" = overload;
    lateness = 409;
    "other_page_faults" = 9;
    "output_device_source_list" = Unknown;
    "output_device_transport_list" = USB;
    "output_device_uid_list" = "AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:000:1";
    "safety_violation" = 0;
    "sample_rate" = 192000;
    "scheduler_latency" = 2750146;
    "smallest_buffer_frame_size" = 512;
}: (
    1125281431556
)

@5T33Z0, got any other ideas?

Seems that this becomes less likely to happen if I lower the sample rate. I also tried with another DAC (FiiO KA3) and the problem persists... so definitely a problem in my system.

Edited by MisakaMikoto0
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted (edited)

More information: the overloading problem and the sound assertion problem seems to be separate. By adjusting CPU voltage and load line I was able to reduce the chance of a overload happening. But USB sound assertions, on the other hand, still happens. It seems to be related to which USB port I connect the DAC to but I'm not sure. The symptom is different as well: overload would be audio becoming crackled, assertions would just stop the output for half a sec and resume like normal. 

Logs from console: 

default	00:36:41.031421-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 3610 AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1 (AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1): starting
default	00:36:41.032093-0400	kernel	+- IOAudioEngine[<private>]::resetStatusBuffer()
default	00:37:54.078242-0400	powerd	Process coreaudiod.255 TurnedOff PreventUserIdleSystemSleep "com.apple.audio.AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1.context.preventuseridlesleep" age:00:01:13  id:4295001416 [System: PrevIdle PrevDisp DeclUser IntPrevDisp kDisp]
default	00:37:54.077944-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 3610 AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1 (AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1): stopping with error 0
default	00:37:54.079777-0400	coreaudiod	[Detector.cpp:85    rtaid::Detector:0x7feedd11f0f0] Node usb |68|Output|0 with nodeID 0 already present, replacing it
default	00:37:54.080231-0400	coreaudiod	[Detector.cpp:119   rtaid::Detector:0x7feedd11f0f0] Created node usb |68|Output|0 with nodeID 0 - reporting period = 10.000000, sample rate = 192000.000000
default	00:37:54.081810-0400	coreaudiod	 HALS_IOContext_Legacy_Impl::IOThreadEntry: 3610 AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1 (AppleUSBAudioEngine:GuangZhou FiiO Electronics Co.,Ltd:FiiO K3:14520000:1): starting
default	00:37:54.083127-0400	kernel	+- IOAudioEngine[<private>]::resetStatusBuffer()
default	00:37:54.313067-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
default	00:37:58.720578-0400	runningboardd	Acquiring assertion targeting [app<application.com.apple.Console.1152921500311973674.1152921500311973679(501)>:1271] from originator [daemon<com.apple.WindowServer(88)>:196] with description <RBSAssertionDescriptor| "FUSBFrontmostProcess" ID:253-196-1878 target:1271 attributes:[
	<RBSDomainAttribute| domain:"com.apple.fuseboard" name:"Frontmost" sourceEnvironment:"(null)">,
	<RBSAcquisitionCompletionAttribute| policy:AfterApplication>
	]>
default	00:38:05.330770-0400	runningboardd	Acquiring assertion targeting [app<application.com.apple.SafariTechnologyPreview.182684918.184090757(501)>:1335] from originator [daemon<com.apple.WindowServer(88)>:196] with description <RBSAssertionDescriptor| "FUSBFrontmostProcess" ID:253-196-1895 target:1335 attributes:[
	<RBSDomainAttribute| domain:"com.apple.fuseboard" name:"Frontmost" sourceEnvironment:"(null)">,
	<RBSAcquisitionCompletionAttribute| policy:AfterApplication>
	]>
default	00:38:07.214283-0400	runningboardd	Acquiring assertion targeting [app<application.com.apple.Console.1152921500311973674.1152921500311973679(501)>:1271] from originator [daemon<com.apple.WindowServer(88)>:196] with description <RBSAssertionDescriptor| "FUSBFrontmostProcess" ID:253-196-1902 target:1271 attributes:[
	<RBSDomainAttribute| domain:"com.apple.fuseboard" name:"Frontmost" sourceEnvironment:"(null)">,
	<RBSAcquisitionCompletionAttribute| policy:AfterApplication>
	]>

EDIT: Turns out CPU voltage has nothing to do with this. I started my testing right after reboot and the problem would not start in the first a few minutes, so it gave me the false impression that adjusting BIOS settings worked.

Edited by MisakaMikoto0
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

@5T33Z0, notice that I have both SSDT-EC and SSDT-USBX, made using SSDTime following dortania's guide, in order to replace the SSDT-EC-USBX inside AudioGod's Z390 Aorus Pro EFI which I think is the bloated prebuilt one here. Is that not enough and I should use your manual guide to create a SSDT-EC-USBX? I see you're also referening SSDTime but using that again would just results in the same SSDTs.

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

Yeah, well you have both, but only SSDT-EC is active. And it does not contain a USBX device…

 

 

AND: don't use prebuilt Dortania SSDTs, because they try to cover all sorts of possible ACPI paths to device and are therefore a full of unnecessary code.

 

 

ALSO: VirtualSMC.kext should be in 2nd Position after Lilu, because most other kexts rely on it. Therefore it should be loaded before the rest. Which is not the case in your config.

 

 

Read my guide. It contains correct voltage settings used by the selected SMBIOS.

 

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted (edited)

@5T33Z0

Uh, what do you mean it's "not active"? It is enabled in my config. 

"They try to cover all sorts of possible ACPI paths to device and are therefore a full of unnecessary code", which is why I disabled it and replaced with my two SSDTs. I'll try following your guide now.

Also for USBX, I assume I need to fill the current values that matches my SMBIOS into my SSDT?

LBNL thx for the kext tip.

Edited by MisakaMikoto0
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted (edited)

@5T33Z0

Just making sure I'm making the right changes:

In my SSDT: 

Scope (_SB.PCI0.LPCB)
    {
        Device (H_EC)
        {
            Name (_HID, EisaId ("PNP0C09") /* Embedded Controller Device */)  // _HID: Hardware ID
            Name (_UID, One)  // _UID: Unique ID
....

So I do the following:

1. `External (_SB_.PCI0.LPCB, DeviceObj)`: No need to change (changing _SB_ to _SB just gets reverted)

2. Uncomment the block that disables onboard EC, and inside it:

change `External (_SB_.PCI0.LPCB.EC0, DeviceObj)` to `External (_SB_.PCI0.LPCB.H_EC, DeviceObj)`

change `Scope (\_SB.PCI0.LPCB.EC0)` to `Scope (\_SB.PCI0.LPCB.H_EC)`

3. Scroll down past the USBX block, `Scope (\_SB.PCI0.LPCB)` above EC block : no need to change

Is this correct?

 

EDIT: after rebooting there's no EC devices in ioreg... which I think is not right?

Edited by MisakaMikoto0
Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

705794749_Bildschirmfoto2022-03-16um13_44_02.png.cbf8d08c68fe6f42d32b531f3279213f.png

 

Enabled: false

 

AGAIN: This is not about SSDT-EC. It's about  "Device (USBX)" Missing in the enabled SSDT-EC....

 

Just generate SSDT-EC-USBX using SSDTTime based on your system's unpatched DSDT and it fixes the EC und USB Power issues.

 

And then see if the issue is gone or not.

 

- Why are you usin GPRW.aml?

- Why are you using SSDT-DMAR.aml? If you do so, you also need tho drop the original DMAR table. Otherwise it makes no sense. But there's no delete rule in your config to drop it.

 

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

705794749_Bildschirmfoto2022-03-16um13_44_02.png.cbf8d08c68fe6f42d32b531f3279213f.png.eea3586f3ea2ae12c38fd75617f42ef1.png

I meant this one. That SSDT-EC-USBX above is the bloated one with all the devices from AudioGod's EFI which is why it's disabled.

BUT, following your guide now I have my own SSDT-EC-USBX. Unfortunately I'm still having problems, both overload and assertion events can be seen in console. Updated EFI folder attached.

 

GPRW was made following this because I have instant wake problems.

DMAR - my bad, I went back to the guide and found out I didn't follow the guide all the way. Thanks for caching it.

 

EFI.zip

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted
8 minutes ago, 5T33Z0 said:

Upload your DSDT please.

Already uploaded in my first post.

Sorry for double posting, not sure if you’re getting the message without quoting.

Link to comment
Share on other sites
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted (edited)

Use this instead and delete the other EC/USBX related .aml files.

 

What it does:

 

- Deactivates original EC in macOS

- Adds a fake one for macOS

- Adds USBX Device.

 

As explained in my guide…

SSDT-EC-USBX.aml

Edited by 5T33Z0
Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

Thanks @5T33Z0... Unfortunately it still happens. Just to make sure I rebooted twice, I logged assertions in the 1st reboot and overloads in both. I found out that if I lower the sample rate it would stop the overloading, but that just defeats the purpose of a DAC.

Also, might be unrelated but is there a way to change global buffer size in macOS? I'm no audio expert but this looks like audio buffer being constantly blown.

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

I also remembered back in clover days there are fields for CPU and bus speeds, and filling those in allowed me to eliminate or at least reduce this behavior (or a similar audio problem) a lot. Now with OC there seems to be no such fields.

Link to comment
Share on other sites
i0ntempest
i0ntempest
Posted
  • Author
Posted

@5T33Z0Alright I’ll try remapping and report back. Not sure it will make a difference though because I have a USB add in card and a Thunderbolt add in card, and the issue occurs regardless of what usb bus I connect the DAC to.

I use the FiiO K3s with this system, but I’ve also tried KA3 and Q3 from the same brand. K3 and KA3 have the same ES9038Q2M chip, the Q3 has an AK4462, and they all have XMOS USB chip iirc. Overload occurs on all of them. 

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...