(Sonoma 14.4) App containing media (Videos, audio, images), takes time to open or is extremely slow

[OneDriftMan95]

Hello everyone,

I've had a problem with my Hackintosh for a while since I moved to Sonoma and it got worse when I did the 14.4 update

applications using audio or videos take forever to open or are super slow and unusable

For example, when I receive a FaceTime call, it takes at least 10 minutes before it opens or crashes.

in chrome the app opens quickly but as soon as I try to start a video or audio, I have to wait at least 2 minutes for the media to load (same for Spotify, Logic Pro X, Apple Music etc etc...)

and now with Sonoma 14.4 when I use chrome or safari, when a page loads the application becomes super slow, and often freezes.

at first I thought it was my audio drivers or my Kext, I updated OpenCore twice, I reconfigured my bios to be sure, look at OpenCore Legacy patcher (I need it to patch my Wifi card /Bluetooth BCM43xx) but nothing changes.

the interface and the rest of the Hackintosh work normally and are perfectly fluid.

here is my configuration:

CPU, RAM, SSD Work just fine (no anormal utilisation)

here is my configuration:

Asus Rampage Hero VIII
Intel Core i7 6700k (OC 4.6Ghz 1.42V)
AMD RX Vega 56 (Stock)
24gb ram (Downvoltage 1.25V after the problem start to appear)
1tb Nvme WD storage (not full and not slow)
PCI adapter with TI chipset for FireWire
Broadcom BCM 43xx (don't remember the exact model)
OpenCore 0.9.8
MacOS 14.4

 

[Feartech]

Hello everyone,

I've had a problem with my Hackintosh for a while since I moved to Sonoma and it got worse when I did the 14.4 update

applications using audio or videos take forever to open or are super slow and unusable

For example, when I receive a FaceTime call, it takes at least 10 minutes before it opens or crashes.

in chrome the app opens quickly but as soon as I try to start a video or audio, I have to wait at least 2 minutes for the media to load (same for Spotify, Logic Pro X, Apple Music etc etc...)

and now with Sonoma 14.4 when I use chrome or safari, when a page loads the application becomes super slow, and often freezes.

at first I thought it was my audio drivers or my Kext, I updated OpenCore twice, I reconfigured my bios to be sure, look at OpenCore Legacy patcher (I need it to patch my Wifi card /Bluetooth BCM43xx) but nothing changes.

the interface and the rest of the Hackintosh work normally and are perfectly fluid.

here is my configuration:

CPU, RAM, SSD Work just fine (no anormal utilisation)

here is my configuration:

Asus Rampage Hero VIII
Intel Core i7 6700k (OC 4.6Ghz 1.42V)
AMD RX Vega 56 (Stock)
24gb ram (Downvoltage 1.25V after the problem start to appear)
1tb Nvme WD storage (not full and not slow)
PCI adapter with TI chipset for FireWire
Broadcom BCM 43xx (don't remember the exact model)
OpenCore 0.9.8
MacOS 14.4

open up hackintool -> USB and take a screen shot and upload it here

you have a boot argument and also PciRoot(0x0)/Pci(0x2,0x0) for your audio, you can remove your boot argument

good chance you don't need all those Drivers in your config.plist

normally you would only really need:
HfsPlus.efi
OpenRuntime.efi
ResetNvram.efi (not present but is handy to have when making any EFI/BIOS changes)
AudioDxe.efi (only if you want boot chime)
OpenCanopy.efi (only if you have a pretty bootloader)

 

[OneDriftMan95]

Thank you for your answer I will look straight away, here is the photo as well as a video to better describe the problem :

 

[Feartech]

Thank you for your answer I will look straight away, here is the photo as well as a video to better describe the problem :

it is strange not to see any SS ports in your USB setup

check over:

The New Beginner's Guide to USB Port Configuration

Important Update: June 2023 From Big Sur 11.3 on the built-in OpenCore XhciPortLimit quirk no-longer worked as described. This became a known "bug", though in reality it was Apple changing their internal code, making a simple "peek and poke" to keep it operating, a difficult task. However, with...

www.tonymacx86.com

and re do your USB setup

 

[OneDriftMan95]

I just saw that in the guide it is written :

"From Big Sur 11.3 on the built-in OpenCore XhciPortLimit quirk no-longer worked as described. This became a known "bug", though in reality it was Apple changing their internal code, making a simple "peek and poke" to keep it operating, a difficult task. However, with the release of OpenCore 0.9.3 the XhciPortLimit Quirk has now been fixed.

I have tested it on the limited hardware at my disposal and all seems fine. Glad to get any feedback from other builders to confirm on their hardware."

So should I remove USBMap and only use "XHCIPortLimit Quirk"?

 

[Feartech]

I just saw that in the guide it is written :

"From Big Sur 11.3 on the built-in OpenCore XhciPortLimit quirk no-longer worked as described. This became a known "bug", though in reality it was Apple changing their internal code, making a simple "peek and poke" to keep it operating, a difficult task. However, with the release of OpenCore 0.9.3 the XhciPortLimit Quirk has now been fixed.

I have tested it on the limited hardware at my disposal and all seems fine. Glad to get any feedback from other builders to confirm on their hardware."

So should I remove USBMap and only use "XHCIPortLimit Quirk"?

use opencore 0.9.3 or newer

remove your usb kexts

enable XHCIPortLimit

reboot, reset nvram

re do the USB setup guide

copy over new USBPorts.kext to EFI

disable XHCIPortLimit

reboot, reset nvram

 

[jaymonkey]

@OneDriftMan95,

This looks like a hardware codec decode issue ....

Having taken a look at your EFI I can see that you are using the iMacPro1,1 SMBIOS.

The iMacPro uses a workstation class CPU that has no IGPU so it uses the dGPU for all hardware codec decode/encode.

However in your config.plist you have the device properties for ig-platform-id defined so I assume that you have the IGPU enabled in the BIOS ?

If so then this is is not a valid hardware configuration for the iMacPro1,1 SMBIOS and might the cause of the issue in that the SMBIOS is telling MacOS one thing but the hardware config is saying otherwise.

I would try disabling the IGPU in the BIOS and removing/disabling the device properties for ig-platform-id, this will force MacOS to only use the dGPU for hardware codec encode/decode, keep the WhatEverGreen kext as this does do some patching for the AMD dGPU.

If you want to specifically use the IGPU as a compute device (mainly for Intel QuickSync) then you need to use a standard iMac SMBIOS (usually iMac19,X or iMac20,X if you want to keep running Sonoma).

Cheers
Jay

 

[OneDriftMan95]

It seems to me that I disabled IGPU in the bios a long time ago because it was causing me a lot of problems but I admit I didn't think to remove "ig-platform-id"

@OneDriftMan95,

This looks like a hardware codec decode issue ....

Having taken a look at your EFI I can see that you are using the iMacPro1,1 SMBIOS.

The iMacPro uses a workstation class CPU that has no IGPU so it uses the dGPU for all hardware codec decode/encode.

However in your config.plist you have the device properties for ig-platform-id defined so I assume that you have the IGPU enabled in the BIOS ?

If so then this is is not a valid hardware configuration for the iMacPro1,1 SMBIOS and might the cause of the issue in that the SMBIOS is telling MacOS one thing but the hardware config is saying otherwise.

I would try disabling the IGPU in the BIOS and removing/disabling the device properties for ig-platform-id, this will force MacOS to only use the dGPU for hardware codec encode/decode, keep the WhatEverGreen kext as this does do some patching for the AMD dGPU.

If you want to specifically use the IGPU as a compute device (mainly for Intel QuickSync) then you need to use a standard iMac SMBIOS (usually iMac19,X or iMac20,X if you want to keep running Sonoma).

Cheers
Jay

 

[OneDriftMan95]

I just removed "ig-platform-id" I have to reboot, check the bios and see if it works, thank you very much

edit : iGPU is disabled and "ig-platform-id" removed and same problem /:

 

[Edhawk]

I've reviewed your Skylake OpenCore EFI folder and taken a screenshot of the EFI folder contents.

Your current EFI folder contents.
When I compare this to a Skylake system I own there are a number of obvious differences.
My Skylake EFI folder contents.

Your ACPI folder contains a pair of Generic SSDT's, which is fine for installing macOS on the system. However they should be replaced with custom SSDT's using your system DSDT.aml and Corpnewt's SSDTTime python script shortly after installing macOS. Here is a guide on how to create the SSDT's.

Custom SSDT's using Corpnewt's SSDTTime

Creating custom SSDT's for your system should be done using Corpnewt's SSDTTime python Script and the system DSDT.aml table. First thing you need to do is get a hold of your system DSDT.aml. The easiest way to do this is to use Hackintool. Download and copy the Hackintool app to the...

www.tonymacx86.com

Your Drivers folder contains a number of non-essential and unused entries that your Skylake system simply doesn't need. I would edit your Drivers folder as shown below.

Current Drivers folder

Revised Drivers folder

I would do the same with your Tools folder:

Current Tools folder

Revised Tools folder.

As you don't have ResetNvramEntry.efi in your Drivers folder, the use of the ClearNvram.efi and ResetSystem.efi entries in the Tools folder will undertake the same task, if used one after the other from the OC boot screen.

To access these Drivers and Tools, simply press the spacebar while on the OC boot screen. This will unhide any Drivers and Tools present in your OC setup. They can be selected and actioned from the boot screen.

Your Kexts folder looks fine considering your system components and need to use the Broadcom Root Patches from OCLP for your WiFi card.

Sonoma 14.4 has been a pain for real Mac's not just Hack's. It is the reason why Apple have released Sonoma 14.4.1 so soon after 14.4, as they didn't do the full Quality Checks required.

A number of WiFi/BT kexts have been problematic in Sonoma 14.4, or when updating the system from a previous release. These include the OCLP kexts - IO80211FamilyLegacy.kext and IOSkywalkFamily.kext. I believe the OCLP developers have released a fix for this issue, which you may need to apply, including new kexts.

IF you decide to update to 14.4.1, which I would recommend, I would suggest removing or disabling the three WiFi related kexts in your /EFI/OC/Kexts folder before attempting the update.

You may also need to change Kernel > Quirks > SecureBootModel to 'Disabled', if you currently have it set as 'Default'.

Looking at the DeviceProperties in your config.plist, I believe you have the properties for the Audio device and IGPU mixed up.

Current DeviceProperties.

According to the Dortania OC guide, PciRoot(0x0)/Pci(0x2,0x0) is the IGPU and PciRoot(0x0)/Pci(0x1b,0x0) is the Audio Device. You have the AAPL,ig-platform-id entry under the Audio device and the layout-id for the audio device under the address for the IGPU. Neither will work and both should be removed with your current setup using iMacPro1,1 SMBIOS.

You might want to look in to adding AMFIPass.kext to your setup and removing the amfi_get_out_of_my_way=1 boot argument.

Good of you to share your SMBIOS data with everyone, NOT!

I would recommend your do the following:

1. Sign out of any Apple Services you use.
2. Generating a new SMBIOS for your Hack using Corpnewt's GenSMBIOS, link below. https://github.com/corpnewt/GenSMBIOS
3. Update your config.plist with the new SMBIOS data.
4. Reboot your system making sure you use the ClearNvram and ResetSystem Tools when you first boot with the new SMBIOS.
5. The system should automatically reboot, the next time you reach the OC boot screen select your macOS icon.

Plenty for you to get on with, don't you think?