Audio is not working: Mojave 10.14 + ALC236

[RehabMan]

here it is

Your native device-id is 0xa348 (you can see it in "compatible" under HDEF).
You're injecting 0x48a3 (you byte reversed native).
As we already discussed, injecting a value different from native prevents AppleGFXHDA from loading.
You could just as well use valid HDEF device-id such as 0xa170 (would be <70a10000>).
Either way will keep AppleGFXHDA from loading.
Some other users have reported that using FakePCIID.kext+FakePCIID_Intel_HDMI_Audio.kext (current versions) also prevent AppleGFXHDA from starting.

If you wanted to be clear about using a bogus id, you might as well use 0x1234 (device-id=<34120000>).

 

[bahha]

Your native device-id is 0xa348 (you can see it in "compatible" under HDEF).
You're injecting 0x48a3 (you byte reversed native).
As we already discussed, injecting a value different from native prevents AppleGFXHDA from loading.
You could just as well use valid HDEF device-id such as 0xa170 (would be <70a10000>).
Either way will keep AppleGFXHDA from loading.
Some other users have reported that using FakePCIID.kext+FakePCIID_Intel_HDMI_Audio.kext (current versions) also prevent AppleGFXHDA from starting.

If you wanted to be clear about using a bogus id, you might as well use 0x1234 (device-id=<34120000>).

what I was Injecting was 0xa3480000 and audio worked .
I tried 70a10000 also and it worked .
I don't see where the problem is .

 

[RehabMan]

what I was Injecting was 0xa3480000

No.
You're actually injecting 0x48a3.
Perhaps you should read up on Intel byte order/endianess/byte reversing.

 

[bahha]

No.
You're actually injecting 0x48a3.
Perhaps you should read up on Intel byte order/endianess/byte reversing.

I actually know how to code in Assembly for intel x86 and AVR . I know about endianess.
audio works.
when I changed it to 0x48a3 and other bogus ids it doesn't .
what I don't know is, , should the AppleGFXHDA be loaded or no . if yes, what is the issue if it doesn't ?
in the picture below I only changed A3488086 to A3480000
doing the opposite audio doesn't work.

 

[RehabMan]

I actually know how to code in Assembly for intel x86 and AVR . I know about endianess.
audio works.
when I changed it to 0x48a3 and other bogus ids it doesn't .
what I don't know is, , should the AppleGFXHDA be loaded or no . if yes, what is the issue if it doesn't ?
in the picture below I only changed A3488086 to A3480000
doing the opposite audio doesn't work.

You want to prevent AppleGFXHDA from loading.
Look at the Info.plist for details on what device-id/vendor-id it will load against.
Any id you use that does NOT match AppelGFXHDA will prevent it from loading.
And since AppleHDA.kext matches on class-code, the device-id you choose to inject simply does not matter as long as it does not match those in the Info.plist. When lookin at the Info.plist, keep in mind that IOPCIMatch is a specification for match against device-id and vendor-id (device-id is in MSW, vendor-id in LSW).

But for clarity of communication, injecting an arbitrary id should probably not use a byte reversed native device-id, as it makes what your intention is unclear.

Hence my suggestion to use something like 0x1234 (coded as <34120000> in Devices/Properties).

Of course, with a native device-id of 0xa348, injecting a byte reversed value 0x48a3 (coded as <a3480000>, will also prevent AppleGFXHDA from loading. It just makes the intent unclear... as if you mean to inject 0xa348 (would be coded as <48a30000) but made a mistake.

Also, your image above shows a basic misunderstanding about what device-id is. It does NOT include the vendor-id (you are confusing vendor-id/device-id injection and Clover's FakeID setting (which puts both in the same value). So, when you inject device-id=<a3488086>, you're actually injecting 0x868048a3, which of course will also prevent AppleGFXHDA from loading, just as using something that represents the intent a bit better, such as 0x1234 (<34120000>) or 0x11112222 (<22221111>).

 

[muchmore]

You want to prevent AppleGFXHDA from loading.
Look at the Info.plist for details on what device-id/vendor-id it will load against.
Any id you use that does NOT match AppelGFXHDA will prevent it from loading.
And since AppleHDA.kext matches on class-code, the device-id you choose to inject simply does not matter as long as it does not match those in the Info.plist. When lookin at the Info.plist, keep in mind that IOPCIMatch is a specification for match against device-id and vendor-id (device-id is in MSW, vendor-id in LSW).

But for clarity of communication, injecting an arbitrary id should probably not use a byte reversed native device-id, as it makes what your intention is unclear.

Hence my suggestion to use something like 0x1234 (coded as <34120000> in Devices/Properties).

Of course, with a native device-id of 0xa348, injecting a byte reversed value 0x48a3 (coded as <a3480000>, will also prevent AppleGFXHDA from loading. It just makes the intent unclear... as if you mean to inject 0xa348 (would be coded as <48a30000) but made a mistake.

Also, your image above shows a basic misunderstanding about what device-id is. It does NOT include the vendor-id (you are confusing vendor-id/device-id injection and Clover's FakeID setting (which puts both in the same value). So, when you inject device-id=<a3488086>, you're actually injecting 0x868048a3, which of course will also prevent AppleGFXHDA from loading, just as using something that represents the intent a bit better, such as 0x1234 (<34120000>) or 0x11112222 (<22221111>).

Hi RehabMan - per post #13, I have changed my layout-id to 0F000000, and my audio started working on my laptop (though it seemed a bit low volume). I am concerned however that I have not listed the correct value (per your posts) and am not sure what the correct value should be for my setup. In DPCIManager the audio device is listed as 0x80869D71 (for Realtek ALC236). I found on GitHub acidanthera/AppleALC the list of supported codecs, and for ALC236 it lists 0x100001, 0x100002 layout 3, 11, 13, 15. Should I use one of the values there (0x100001, 0x100002)?

I have attached the problem reporting files and I hope you may be able to help with this particular value.

On an aside - thank you so much for your work with laptops. I have avoided building a laptop for a long time due to the high difficulty, and would not have been able to get this Lenovo 330S going if it wasn't for your hard work and assistance to others with similar laptops.