HDMI Audio with new UEFI BIOS? How to would be helpful...

[wenstinator]

The dsdt patch file is not for the UEFI dsdts. It is for the Award BIOS. There may be something useful in the patch file for the AMI UEFI but I don't know. If you are up for an experiment. Read on. Otherwise, reply with not interested.

Download the attachment.

Some notes
1. You cannot use the patch file more than once on a dsdt. If problems, start over with recovery file.
2. The HDMI audio dsdt edits are for AMI UEFI Sandy Bridge only (GA and Asus)
3. You must use the MultiBeast/With DSDT/ALC 8__/AppleHDA_v2.2.0 (10.7.4)
4. Installs both integrated and discrete graphics HDMI audio; you can use one or the other or both.

Use your native dsdt. Fix any errors you want.
Run DSDT Editor/Patch/Open ami_clean_compile.txt, Apply, Compile and Save.
Hopefully there are no errors.
The saved file is your recovery dsdt.

If you want HD3000 HDMI audio set layout-id to 0x85, 0x01, 0x00, 0x00
If you want Nvidia HDMI audio set layout-id to 0x79, 0x03, 0x00, 0x00
if you want both, use HD3000 HDMI audio layout-id

TextEdit Open/Downloads/hd3000_hdmi_audio_dsdt_editing_kit/hdmi_audio_ami_sandy_bridge.txt
Edit HDEF/layout-id to the above.
Save

Run DSDT Editor/Patch/Open hdmi_audio_ami_sandy_bridge.txt, Apply, Compile and Save.
Hopefully there are no errors.
Save

Install dsdt.aml to Extra/dsdt.aml

Restart. Verify HDMI dsdt edits in IOReg.

More Info: Downloads/hd3000_hdmi_audio_dsdt_editing_kit/-read_me_first-hd3000_hdmi_audio.pdf

View attachment 28978

Hi toleda, I ran this exact process above on my DSDT extract. I didn't get any errors. I have an 889 and an AMD card, so I am using 0x85, 0x01, 0x00, 0x00. I rebooted and still cannot find HDAU in IOReg. Can you take a look at my files when you have a chance? Thanks!

 

[coelo]

are you using UEFI?
what is your board and your BIOS?

That info was particular to a AMI UEFI Gigabyte board.

Just trying to help.

 

[wenstinator]

are you using UEFI?
what is your board and your BIOS?

That info was particular to a AMI UEFI Gigabyte board.

Just trying to help.

I have a GA-Z68MX-UD2H-B3 board running UEFI bios U1c.

 

[chrizk]

UEFI does not change the architecture of the system. A dsdt is still required. What has changed is the native dsdts are more OS X friendly.

Hi Toleda
Thanks for the reply and explanation.
Could you answer one more thing before I go down the dsdt route?
I have a pretty good system without a modified dsdt, ie full HD, sleep working etc.
If I create a dsdt, can I assume I will not have to add any patches for it to work in the same manner as it is now?
ie I extract it, clean up the errors, and add it to /Extra, my system will work as it does now.

Sorry, one more question . Can you confirm I can simply copy a modified dsdt to /Extra and it will be picked up?
NB I used MultiBeast UserDSDT as my 'base post install' tasks.

Many thanks
CK

 

[toleda]

Hi toleda, I ran this exact process above on my DSDT extract. I didn't get any errors. I have an 889 and an AMD card, so I am using 0x85, 0x01, 0x00, 0x00. I rebooted and still cannot find HDAU in IOReg. Can you take a look at my files when you have a chance? Thanks!

Delete the S/L/E/HDAEnabler889.kext, fix permissions and cache. HD3000 does not show up in IOReg, why are you using 185 instead of 379?

 

[toleda]

ie I extract it, clean up the errors, and add it to /Extra, my system will work as it does now.

Sorry, one more question . Can you confirm I can simply copy a modified dsdt to /Extra and it will be picked up?
NB I used MultiBeast UserDSDT as my 'base post install' tasks.

Yes. Yes. Why did you use UserDSDT when you didn't have a dsdt?

 

[chrizk]

Yes. Yes. Why did you use UserDSDT when you didn't have a dsdt?

The UserDSDT option in MultiBeast 5.0.2 is "UserDSDT or DSDT-Free Installation"

I have attempted to create a DSDT and failed.
I'm not sure if "no patches" also includes the omission of the 'board specific patch' from olarila.com - would you mind confirming?

I have attempted with and without the board specific patch.
Would you mind having a look as the errors have me stumped?
I have looked for answers on the internet but cannot find specific fixes, and DSDTFixer cannot resolve them.

• "extracted dsdt.dsl" is the initial extract using DSDT Editor after an attempt to compile and fix errors, still leaving one error.

{10878 Error _HID suffix must be all hex digits}

• "z68ap with errors.dsl" is my extracted dsdt with the board specific (GA-Z678AP-D3) patch from olarila AFTER running Fix Errors, with 3 errors

{2763 Error Object Does not Exist (ATT3) / 4051 Error Name already exists in scope (LPC0) / 10668 Error _HID suffix must be all hex digits (GH) }

• "my attempt with error.dst" is my attempt to resolve some errors (NOTE: no errors were identical to those detailed in DSDTSE and so they are my 'best guess')

***First time I have attempted to use Archive in OSX, hopefully the attachment is OK.

Many thanks, I really appreciate your help as I am so close after many weeks of trying different versions of OSX and troubleshooting.

CK

 

[toleda]

View attachment ami_clean_compile.txt

The UserDSDT option in MultiBeast 5.0.2 is "UserDSDT or DSDT-Free Installation"

I have attempted to create a DSDT and failed.
I'm not sure if "no patches" also includes the omission of the 'board specific patch' from olarila.com - would you mind confirming?

The motherboard patch assumes you are on the old Award BIOS. I would not use them on the new AMI UEFI.

Use the attached patch to fix the compile error.
View attachment ami_clean_compile.txt

 

[chrizk]

View attachment 29094
The motherboard patch assumes you are on the old Award BIOS. I would not use them on the new AMI UEFI.

Use the attached patch to fix the compile error.
View attachment 29094

Toleda
Thank you very much for a really quick reply (wasn't expecting that and didn't check till late!).
It is really great to get quick authoritative answers.

For the benefit of others, can you say if the supplied patch is for all UEFI AMI dsdts, all Gigabyte/AMI or just Z68?
If this is specific rather than general, is it the result of your hard work and knowledge or do you know a resource? This may help people find their own answers rather than knock on your door

Further information,
I extracted my dsdt once more and applied the patch. This resulted in the following compile errors;

• Error Invalid Object type for reserved name (found ZERO, requires Buffer)
• Warning Not all control paths return a value (_HID)
• Warning reserved method must return a value (Integer/String required for _HID)

Fix errors resolved the Error but not the warnings. Is this a problem?

It appears to dislike the following code;
Method (_HID, 0, NotSerialized)
{
If (TCMF) {}
Else
{
Return (0x0201D824)
}
}

The following resolves the compilation warning, is it correct/suitable?
If (TCMF) {Return (0x00)}
the method is defined under Device (_SB.PCI0.LPCB.TPM). The only reference to TPM on LPC bus I can find is Trusted Platform Module which appears to be a device for generating cryptographic keys. I'm not sure how this is used, but I guess it could be important.

I have attached the result prior to the change above in case you have the time to help further.

Many thanks once more.
CK

 

[toleda]

Toleda
Thank you very much for a really quick reply (wasn't expecting that and didn't check till late!).
It is really great to get quick authoritative answers.

For the benefit of others, can you say if the supplied patch is for all UEFI AMI dsdts, all Gigabyte/AMI or just Z68?
If this is specific rather than general, is it the result of your hard work and knowledge or do you know a resource? This may help people find their own answers rather than knock on your door

I have attached the result prior to the change above in case you have the time to help further.

This patch is for Sandy Bridge motherboards with Sandy Bridge processors with the AMI EFI BIOS (Asus 3K/6 series chip set, GA UEFI/6 series chip set and any other AMI EFI BIOS/6 series chipset). The first post of most threads includes Credit to people that helped me.

A dsdt with warnings is no problem. Please attach the native version of your dsdt. The clean_compile patch was supposed to resolve that warning.

The fix looks like this:

[TABLE]
[TR]
[TD][COLOR=#006600][FONT=Monaco][TABLE]
[TR]
[TD][TABLE]
[TR]
[TD]   Device (_SB.PCI0.LPCB.TPM)
    {
        Method (_HID, 0, NotSerialized)
        {
            If (TCMF) {}
            Else
            {
                Return (0x310CD041)
            }
            Return (Zero)
        }[/TD]
[/TR]
[/TABLE]
    }[/TD]
[/TR]
[/TABLE]
[/FONT][/COLOR][/TD]
[/TR]
[/TABLE]