Ryzen 5 9600x, gigabyte b650 gaming x ax v2, everything's ok except audio drops and cracklings...

[veda95]

Hello everyone,

I just change my cpu motherboard, ram etc...comming from an old intel hackintosh who was working very well and, after 5 days to make it working, it's almost done, i just have concerns about the sound:

I have an external usb sound card, Focusrite Scarlett Gen 3 and I disabled the internal sound card in the bios but the sound is crackling, audio drops and I think it's cpu management problem because, I make music on this computer and in the music production software I can monitor the cpu usage, and there I seen cpu spikes every seconds, without anything running in background, I can't even listen an mp3 correctly it's ugly.

I tried another usb interface, also using the sound of 2 different screens and that's the same issue...

I'm not an expert in osx installation so, maybe I made something wrong, if someone can take a look, I put here my efi folder and my extracted dsdt and ssdt in one folder.
One important thing, my ssdt patchs in open core / acpi was not made with my exact cpu but by someone with the same motherboard.

Thank you and I hope I describe all of this correctly cause English is not my original language !

 

[Edhawk]

USB issues:

1. The USB Audio issues are more likely to be related to your USBMap.kext not being correct, plus it is disabled in your config.plist.
2. You have the XhciPortLimit quirk enabled in your config.plist, so you aren't likely to be enabling the USB ports correctly for your setup.
3. You seem to have 4 x USB controllers present in your system.
   1. As each USB controller can activate up to 15 x ports (each) you shouldn't need to disable any USB ports in your setup.
   2. As it is unusual for an AMD USB controller to contain more than 15 x ports.
4. Not sure you need the 3 x USB related SSDT's either. Not if your USBMap.kext is set correctly.

Kexts folder:

1. Your /EFI/OC/Kexts folder is a mess, with regards to the Intel & Broadcom WiFi/BT kexts you have added to your setup.
   1. You should only have one WiFi/BT card active in your system, so you don't need both sets of kexts.
   2. If you aren't using the Broadcom Kexts (except for BlueToolFixup.kext) the other Broadcom WiFi and Bluetooth kexts should be removed from your OC setup.
2. Your motherboard will contain either a MediaTek (MT7922A22M) or Intel AX210 card.
   1. Only the Intel WiFi/BT is compatible with macOS.
3. If you have a MediaTek WiFi/BT card in your system, I would recommend disabling it in the bios.
4. Adding a PCIe adapter with a compatible Broadcom or Intel card for use in macOS in place of the MediaTek card.
   1. The Broadcom card would be the better of the two 'compatible' options.
5. You don't need AppleALCU.kext with your motherboard. As the built-in Realtek Audio codec isn't USB based according to your motherboards specification page.
   1. It won't help your Focusrite USB Audio device, as you should have installed the macOS drivers for your USB audio device provided by Focusrite.
6. I would recommend you remove any and all kexts that are not enabled in your config.plist, as all they do is confuse the troubleshooting of your USB issues.

If you are using macOS Ventura, as this thread suggests then you don't need -lilubetaall boot argument.

 

[Edhawk]

I have used the Hackintool ACPI tables you provided in post #1 to generate a number of custom SSDT's and ACPI Patches for your system, using Corpnewt's SSDTTime.

First I deleted the tables corresponding to the SSDT's you have added to your /EFI/OC/ACPI folder from the Hackintool dsdt ssdt folder you provided above. This just left the native AMD system SSDTs and DSDT for SSDTTime to use.

If the non-native SSDT's had been used SSDT-14.aml to SSDT-19.aml inclusive, then SSDTTime would have given false/incorrect results, as these 6 x SSDT's contain fixes that SSDTTime will provide.

I generated the SSDT's and OpenCore ACPI patches using Options 1, 2, 4, 5, 8 9, A & C.

screenshot of SSDTTime options.

The SSDT's and patches are contained in the Results folder attached below and as shown in this screenshot.

screenshot showing contents of Results folder.

Note this folder also contains 2 x screenshots taken during the generation of the SSDT's and patches, as two of the options 8 & 9 provided information that would be lost once the Terminal page had been refreshed. These screenshots relate to the SSDT-USB-Reset.aml and SSDT-Bridge.aml option output.

The SSDT-USB-Reset option told us that 3 x USB controller renames are required for your system.

screenshot showing output from Option 8, USB Reset.

The script automatically generated the 3 x patches required to fix a _STA to XSTA rename issues. These can be seen in the 'patches_OC.plist' along with the patches required for SSDT-HPET.aml and SSDT-XOSI.aml.

View of 3 x APCI _STA to XSTA rename patches from the 'patches_OC.plist' (viewed in ProperTree)

SSDTTime does not automatically generate the USB Controller rename patches your system requires. This is left to the User to generate and add to the config.plist, so any clashes with native Apple USB controllers are not present.


Another issue that arose when generating the custom SSDT's was that SSDTTime says your system doesn't need and SSDT-Bridge or SSDT-BRG0 table for your discrete GPU. See the screenshot below.

Result for using Option #9 from SSDTTime (SSDT-Bridge.png).

VGA is a common ACPI name for a discrete GPU in an AMD system. Most Intel systems use GFX0.

Your SSDT-BRG0.aml table is looking to add 2 x ACPI names to your setup (BRG0 & GFX0), which as far as I can tell are not required.

Screenshot showing contents of SSDT-BRG0.aml table from your /EFI/OC/ACPI folder.

Without seeing the Hacklntool PCIe tab's IOReg Name for the dGPU, it is impossible to say if the information from SSDTTime is 100% correct. But personally I would remove the SSDT-BRG0.aml table from the OC setup and see how the AMD RX 6950 XT discrete GPU works. Simple enough to add it it back if it is required.

I would recommend the following:

1. That you create a copy of your current EFI on a spare USB pen drive.
2. Make the edits recommended in post #2 regarding your USB mapping etc.
3. Delete the current SSDT's from the /EFI/OC/ACPI folder.
   1. Delete the ACPI > Add entries for the old SSDT's.
4. Copy the SSDT-xxxx.aml tables contained in the Results folder to the /EFI/OC/ACPI folder.
   1. Copy and paste the ACPI > Add entries from the patches_OC.plist to your revised config.plist.
   2. Copy and paste the ACPI > Patches from the patches_OC.plist to your revised config.plist.
5. Boot your system using the revised EFI on the USB pen drive.
   1. You will need to use the Gigabyte Boot Menu to select the USB as the boot drive, pressing F12 to bring up the 'one-time' boot menu.
   2. Make sure you use the ResetNvram option from the OC boot screen before booting with the revised EFI, as you need to ensure the old NVRAM entries are deleted before you boot with the new EFI.

Do not replace or overwrite your current working EFI until you are 100% sure that the EFI on the USB works as expected.

 

[veda95]

Hi EdHawk !

Big thank you for all this informations, really !

One more informations, maybe important, maybe not, the SSDT's added to my /EFI/OC/ACPI was not made by me but by someone with the same motherboard so I don't know if he did a good job..

I think now I can progress in the right way and it seems that i have a lot to do
The second part of your answers about dsdt, ssdt etc seems pretty hard, but I will do step by step and you made this easier for me so again, thank you !

 

[Edhawk]

One more informations, maybe important, maybe not, the SSDT's added to my /EFI/OC/ACPI was not made by me but by someone with the same motherboard so I don't know if he did a good job..

That is a common issue. You don’t know if the person who created the EFI is any good, or were they just lucky that the folder worked.

You need to spend some time getting the USB Map.kext right for your system. As USB issues are one of the most common problems that you can face when building a Hackintosh system.

GitHub - corpnewt/USBMap: Python script for mapping USB ports in macOS and creating a custom injector kext.

Python script for mapping USB ports in macOS and creating a custom injector kext. - corpnewt/USBMap

github.com

USB Mapping | OpenCore Post-Install

USB Mapping | OpenCore Post-Install

 

[veda95]

So, I think i made everything, cleaning the mess in kexts, delete ssdt's and replace by those you gave me, apply the patches, make my usbkext with the python script and....no change at all...

I had already everything working intel wifi and bluetooth, gpu still working good without ssdt...Don't really know what to do now to fix this sound issue.

I post my actual efi folder maybe I forget or misunderstood something.

It's really late, I go to bed now

Edit: I tried with no effect to:
(each time, sound is working but with cracklings artefacts)

• use the sound of the screen with hdmi link
• use the sound of the screen with DisplayPort link
• use another usb soundcard
• disable resize bar and expo in bios
• replace virtualsmc.kext by fakesmc.kext

 

[Edhawk]

I will have a look at your revised EFI folder when I am at my desk, later this evening.

 

[veda95]

Thank you!

I look at the console when I read an audio track and this error come over and over:

HALS_OverloadMessage.cpp:644 index: 65, start: 0x9a3ce72b52, duration: 0x154, fault address: 0x10958b000, fault pc: 0x7ff8029c92de, faulting TID: 0x37f3, fault type: 0x1, PID: 0xe8

 

[Edhawk]

Have a read of this page regarding the HALS_OverloadMessage.cpp message.

Diagnosing and managing the dropouts issue in Apple’s CoreAudio (HALS_OverloadMessage)

This article contains troubleshooting information HALS_OverloadMessage.cppHALS_OverloadMessage: Overload possibly due to HAL client proc exceeding io cycle

support.source-elements.com

 

[veda95]

Yes, that's how I find this error, but they don't tell how to fix it, it say that's memory load but this happen as soon I open a user session, I don't have a lot things open. And I uninstalled lot of things to find why it happen.

 

[Edhawk]

Regarding your EFI.

As you are troubleshooting issues and sharing your EFI folder it is best to remove the 'Apple' folder before zipping the EFI folder. The Apple folder can on occasion be quite large, not so in your case but just remember not to include it with any future EFI posts.

Your /EFI/OC/Kexts folder looks a lot better with the unnecessary kexts removed.

The ACPI folder contains 2 x entries that shouldn't be present in this folder. Highlighted in screenshot below.

The 2 x highlighted entries should be deleted.

The patches_OC.plist shouldn't be present in any part of the EFI. It contains patches that are required for the config.plist, nothing more.

The SSDT-CPUR.aml has been replaced by the SSDT-PLUG-ALT.aml table. I should have made this clearer to you when posting the Results folder.

Your /EFI/OC/Drivers folder contains 7 x entries, but only 4 x entries are present and enabled in your config.plist.

Only the highlighted entries are required.

You have both the Acidanthera and BlackOSX theme folders present in the /EFI/OC/Resources/Image folder and are only using the Blackosx theme. The Acidanthera theme folder can and should be removed if not used.

highlighted Acidanthera folder should be deleted.

Your /EFI/OC/Tools folder contains 15 x entries, but only OpenShell.efi is present and enabled in your config.plist.

Only the highlighted entry is required.

Of more concern is the fact that the entries in the /EFI/OC/Tools folder are from a different copy/release of OpenCore. These entries are all set with the date and time stamp 4 May 2024 15:47, while the Drivers and other essential OC elements are all dated 22 August 2025 18:02. This should never be the case. All the Drivers, Tools, OpenCore.efi and Bootx64.efi should all have the same date/time stamp from a single OC release.

So you probably should delete the OpenShell.efi entry from the Tools folder and config.plist. As using it would not be wise.
The alternative is to replace the OpenShell.efi with the one from the OC release that provided the other parts for the EFI folder.


This is what a cleaned up version of your EFI folder would look like, after dealing with the elements listed above.

Cleaned up EFI folder viewed in Finder.



A cleaned up copy of your EFI is attached below.


USB Issues:

I can see you have tried to sort out the USBMap.kext issues as your new USBMap.kext uses the latest USBMap release for Tahoe.

Unfortunately you have failed to correct some issues.

1. None of the ports in the kext are set as 'Internal' with connector type (255).
   1. You must have at least one for system LED's,
   2. Possibly another for a built-in audio device,
   3. Another for any case front USB2 ports connected to a motherboard header and
   4. The Bluetooth module if connected to an internal M.2 port or motherboard header.
2. All bar one of the 26 x ports identified in your kext are set as USB3 with connector type (3).
   1. Having seen the USB configuration for your motherboard I know this is wrong.
   2. The single port has been set as USB2 physical with connector type (0).
   3. This USB2 port is to be found under the MacPRo7,1-XHC2 controller as port HS01.

These are the USB ports available on your motherboard.

CPU:

1. 1 x USB Type-C® port on the back panel, with USB 3.2 Gen 2 support
2. 1 x USB 3.2 Gen 2 Type-A port (red) on the back panel
3. 1 x USB 3.2 Gen 1 port on the back panel

CPU + USB 2.0 Hub:

1. 3 x USB 2.0/1.1 ports on the back panel

Chipset:

1. 1 x USB Type-C® port with USB 3.2 Gen 2x2 support, available through the internal USB header
2. 4 x USB 3.2 Gen 1 ports (2 ports on the back panel, 2 ports available through the internal USB header)
3. 4 x USB 2.0/1.1 ports available through the internal USB headers

WiFi/M.2:

1. 1 x USB 2.0/1.1 port serving Bluetooth module from the M.2 connector

This means your system contains the following USB ports:

• 5 x Internal (255) ports
• 3 x USB2 physical (0) ports
• 6 x USB3 physical (3) ports
• 6 x USB2 virtual (3) ports (served from the physical USB3 ports)
• 1 x Type-C physical port on the rear I/O plate
• 1 x Type-E header, serving any case front Type-C port.

To me this means you should have between 24 and 28 ports available for discovery.
Your USBMap.kext indicates that you can discover 26 x ports.

This means the rear Type-C and Type-E header are providing 6 x ports between them.
One of these two will be a Type-c+sw (9) connector providing 2 x ports (1 x physical & 1 x virtual USB2 port).
The other will be a Type-c (10) connector providing 4 x ports (2 x physical & 2 x virtual USB2 port).

You need to revisit your USBMap.kext and change the connector type for 13 of the 26 ports. As they are currently set incorrectly.

Until you get the USBMap.kext set correctly you won't have a chance of fixing the USB audio issues. As having just one port set with the wrong Connector Type can cause system wide issues.

 

[Edhawk]

This is how I go about configuring the USB ports on my systems.

USB Port Configuration:

USB2 (0) - Physical USB2 ports on rear I/O plate, these ports always have a Black coloured tang.​

​

USB3 (3) - Physical USB3 ports on rear I/O plate, these ports can have a Red, Blue, Cyan coloured tang.​

Virtual USB2 ports - served from physical USB3 ports should be set the same as the physical port​

​

USB3 (3) - Motherboard Header, usually serving the case front USB3 ports.​

Virtual USB2 ports - served from physical USB3 ports should be set the same as the physical port​

​

Internal (255) - Motherboard USB2 header, this will be any device served from a header port, such as Bluetooth module, case front USB2 ports, case front card reader etc.​

​

Internal (255) - Built-in M.2 WiFi/BT connector, motherboard LEDs and CPU Cooler USB connection.​

​

Type-c+sw (9) - will only show two ports being available, 1 x Physical Type-C and 1 x virtual USB2 port.​

​

Type-c (10) - will show 4 x ports being available. This occurs when the Type-C device initially inserted, then removed, the device is flipped 180° and reinserted in the same port, 2 x Type-C and 2 x virtual USB2 ports.​

 

[veda95]

Thank you, I understand the theory but it seems to be very hard to make, I will try anyway, I have to make this computer to work, it's my music production tool under osx since Leopard...

Few questions:
- can I make all the mapping under the python script you sended me or do I have to edit manually something after? (like in the dortania mapping guide)

- I put a picture of my motherboard, the thing is, I don't have physical access on all usb ports cause, my case doesn't have the all the connectors (just 2 different cables, one old usb classics, and one usb 3 with big black plastic connector)
Is that a problem to map correctly the actives ports?

- Yesterday when I tried to map them, I had 17 actives usb ports and the python script told me to let only 15 port at maximum, is that right? (so I disable 2 I'm not a complicate guy)

 

[Edhawk]

Do the Red coloured circles on the motherboard layout image mean the USB2 (F_USB2) & Type-E (F_U320G) headers are not being used?

If you mean you discovered 17 x ports under a single USB controller, then yes you need to not activate two of the ports. As each controller is limited to 15 x ports as a maximum.

Not activating all the ports available is fine.

I think it is best if you don't include them in the USBMap.kext, as getting an inactive port set with the wrong connector type might still have an adverse impact on the whole kext. I am not 100% sure if that is the case but I definitely think it is best to remove/delete any unused ports. Doing this with the option in USBMap script would be best.

These are the options available from the main menu in USBMap.



First you need to use Option 'D' Discover Ports.
Once you have discovered all the ports, or those that are in use.
You then need to return to. the main menu and select option 'P' Edit & Create USBMap.kext
This will show all the ports that have been discovered in your system, including those that are not used.
This is a screenshot showing the options available when editing the USBMap.kext.



You need to use option 'D' Disable All Empty Ports to ensure any ports you don't need are disabled in the kext.
They can be physically removed/deleted from the kext at a later date.

The options highlighted in the magenta rectangle are really helpful and should be used to make sure that the ports are set with the correct connector type.

You should also if possible, use the NickName option to confirm which port is which, and give each port a name that is clear and understandable to you and others that look at your USBMap.

This is an example of the Discovered ports from my Asus X570 motherboard & Factal Design case.

Each port has been identified with a clear and obvious name.

You can also see which devices have been discovered on each port.
This can be used to set a name and to make sure the correct connector type is assigned to the port.

Changing the USB port connector type is pretty easy with this script.

Example
cort#,port#,port#:and then the port type.
c:1,4,5:255

The example above would set ports 1, 4 & 5 with connector type Internal (255).

I would recommend you use option 'K' Build USBMap.kext when you have finished naming and setting the port connector types.

 

[veda95]

Hello,

I spend night on it, I think the mapping is correct now, at least for the controllers I have access to and, nothing change...
(at the end of the process, the script ask me if I want to disable an empty controller or to ignore, I say disable, see capture)

So after that, I thought maybe it's software issue, so I took another hard drive and installed fresh sequoia on it, and...same issue with the sound, so I return to my main Ventura disk with no idea..

I also tried all I can do with the bios, disable acpi patches in open core, nothing worked, then I did going to sleep !

 

[veda95]

BIG IMPROVEMENT !

I just tried this: https://github.com/astrihale/speedkeeper

And it's working ! It's weird because I read everywhere that we doesn't need this anymore since the 6 or 8 core patch in opencore exist but it's working nice now !

Maybe my patch isn't good?

 

[Edhawk]

I noticed you had removed a few of the early CPU patches, but assumed you did this for a reason, following a guide or someone else's instructions. Not using those versions of macOS.

I don't mess with the AMD Vanilla patches. I change the CPU cores as needed, leave all the rest set at their default settings. If I have any graphics performance issues I might try switching between the Algrey and Shaneee 'Fix PAT' patches (patches 21 to 24), to see if anything changes.

It is never a good idea to mess with the AMD Kernel patches, not unless you know exactly what you are doing, know how to reverse any changes you make if the changes don't work as expected.

 

[veda95]

I didn't remove the patch, I thought this : "algrey | Force cpuid_cores_per_package to constant (user-specified) | 13.3+" was the one I need to make what is explain here: https://github.com/AMD-OSX/AMD_Vanilla

But obviously this patch doesn't make his job in my case, I miss something else.
(What I did with the patchs section; after reading the guide of OpenCore is to replace the fix pat of Shaneee by the Aley's one for more stability and to be sure noise on music didn't come to that)

 

[veda95]

Hi!!!

I come back to know if someone have an idea why I still need speedkeeper apps with my cpu to avoid having sounds cracklings on usb audio or, hdmi and DisplayPort audio? (I have cpu core numbers patches in open core)

Thank you.

 

[Edhawk]

What Speedkeeper apps are you using in macOS?

I thought they were Android applications!