El Capitan AppleHDA HDMI Audio

[Alby128]

10.11.1, yes

GT240, special edit required.

 

 

I have done this yesterday, it works with latest Enoch and edited DSDT. It did not work in the first place because I was using GraphicsEnabler=Yes and none of the DSDT GPU parameters was actually injected.

 

Thanks,

Alberto

[toleda]

v1.3: 4/8/16 - Skylake/HD5x0 HDMI audio support (cloverHDMI, ssdt or Bootloader/Clover)

See Post #1.

[G.com]

X - Problem Reporting (post to this thread with requested information attached)

1.     1.  Description of HDMI audio problem 

          > No HDMI Device or Sound over HDMI

1.     2.  OS X version/motherboard model/BIOS version/processor/graphics

          > 10.10.5 (14F27), Gigabyte Z97X Gaming GT, AMI Alaska UEFI, i7-4790K,EVGA GTX970 AAC+ 2,0 SC

1.     3.  Procedure/Guide used

          > CloverALC.Command

1.     4.  Installed S/L/E/AppleHDA.kext

          > Vanilla

1.  
2.  
3. Copy of IOReg - IOReg_v2.1/File/Save a Copy As…, verify file (Tools 1.)
4. Screen shot/DPCIManager/Status (Tools 2.)
5. DPCIManager/Misc/Boot Log
6. MaciASL/File/Export Tableset As... (Tools 3.)
7. Terminal/Shell/File/Export Text As. . . /audio_cloverHDMI-110.command
8. EFI/CLOVER/config.plist
9. DPCIManager/Misc/Boot Log
10. EFI/CLOVER/ACPI/Patched/ssdt.aml

Archive.zip

[toleda]

         > No HDMI Device or Sound over HDMI

Motherboard has a pci multiplexer, special edits required

Replace EFI/ACPI/patch/SSDT-HDMI-NVIDIA-PEG0.aml with attached

Reply with new files.

SSDT-HDMI-NVIDIA-PEG0+.aml.zip

[G.com]

Thanks Toleda! Still does not work. Files attached. Others remain the same.

 

 

Archive.zip

[toleda]

Still does not work.

My mistake, try attached

Issue is _ADR, your card is a different slot.  

            Device (PLX0)
            {
                Name (_ADR, 0x00011000)

SSDT-HDMI-NVIDIA-PEG0+.aml.zip

[G.com]

Unfortunately still does not work. 

 

Just to be sure. I am using a fresh and Vanilla OS X (from Time Machine just after installation), even used Kext Utility installing the AppleHDA.kext from the Installation.App to be absolutely sure. Removed AppleALC.kext and restart. Run the script and failed, now changed the .ssdt twice without any change.

 

Thanks for all your help, really appreciate it! What can make it so complicated? Others have this card OOB, I read.

 

I have no DSDT, I am not using any other HDMI stuff.

 

Start to worry if it may work at all

 

Even more strange, when putting back the ALC.kext - it is not showing up under kextstat anymore, don´t know if that means anything.

 

Meanwhile, I rebuild my system again, used the piker alpha script, got the applehda8series.kext, audio enable. Then used the ssdt you sent = no hdmi audio. 

 

Do you have any idea?

Archive.zip

[toleda]

still does not work. 

The problem is the address of you graphics card, Clover:

0:100  0:000  PCI (00|02:11.00) : 10B5 8747 class=060400

Try attached.

SSDT-HDMI-NVIDIA-PEG0+.aml.zip

[G.com]

0:100  0:000  PCI (00|05:00.00) : 10DE 13C2 class=030000

0:100  0:000  Found NVidia model=EVGA GeForce GTX 970 family #x

0:100  0:000  PCI (00|05:00.01) : 10DE 0FBB class=040300

 

Checking that - this seems to be the entries for my GFX as to DPCI. 

 

The SSDT leads to a black screen - no not really black, I can see the backlight in the corners on but no picture.

 

Could this be related me copying the AGPM values from AGPM.kext to my Fake SMC? --> guess not, just checked really only AGPM related data, should not influence the address.

[G.com]

P.S. Tried to play around with the ADR Values but without luck. Please tell me if I can do/prepare anything to make it easier for you helping. 

[toleda]

 

Checking that - this seems to be the entries for my GFX as to DPCI. 

The SSDT leads to a black screen - no not really black, I can see the backlight in the corners on but no picture.

Could this be related me copying the AGPM values from AGPM.kext to my Fake SMC? --> guess not, just checked really only AGPM related data, should not influence the address.

 

Not correct, the multiplexer is before the graphics card, the injection bridges graphics and audio.

0:100  0:000  PCI (00|02:11.00) : 10B5 8747 class=060400
0:100  0:000  PCI (00|05:00.00) : 10DE 13C2 class=030000

IORegs are the only way to see what has happened.  Without IOReg, no idea.

AGPM has no effect on ACPI edits.

Other users have success when graphics is installed in the IOReg/@10 slot (first + ssdt)

Try other addresses; PLX replaces pci-bridge when it is working.

[G.com]

Tried out with several dresses, but got a step further - this time he did the boot into OS X with your ssdt. But I can see in IOREG, PLX not added. Even tried to address of pcibridge-1ß which should also work, right? It did not. Does it make sense to swap the card at this point? I can try that tomorrow. Other than that - is there any BIOS setting that could prevent this from happening?

[toleda]

Even tried to address of pcibridge-1ß which should also work, right? It did not. Does it make sense to swap the card at this point.

It is hardware,specifically, the PLX PEX 8747 pci multiplexer.  If you moved the card to @10, a different address is needed; see below. Perhaps, the correct ACPI/address edit will be found.  In the meantime, the only solution is a different motherboard.

                    Device (PLX0)

                    {

                        Name (_ADR, 0x00100000)

[G.com]

OK,

 

what I understood so far:

 

DSDT defines:

 

Device (PEG0)

         {

         Name (_ADR, 0x00010000)  // _ADR: Address

         Device (PEGP)

          {

                   Name (_ADR, Zero)  // _ADR: Address

           }

 

Clover Boot says: 

 

0:100  0:000  PCI (00|00:00.00) : 8086 0C00 class=060000 = pci8086,  c00@0

0:100  0:000  PCI (00|00:01.00) : 8086 0C01 class=060400 = PEG0

0:100  0:000  PCI (00|01:00.00) : 10B5 8747 class=060400 = PEGP

0:100  0:000  PCI (00|02:08.00) : 10B5 8747 class=060400 = pci-bridge 8

0:100  0:000  PCI (00|02:10.00) : 10B5 8747 class=060400 = pic-bridge 10

0:100  0:000  PCI (00|04:00.00) : 10DE 13C2 class=030000 = GTX970 

0:100  0:000  Found NVidia model=EVGA GeForce GTX 970 family #x

0:100  0:000  PCI (00|04:00.01) : 10DE 0FBB class=040300 = GT970 HDA

 

From not knowing better I would say the addresses of PEG0 vary?

 

Further examination, using some of your files, I can only make anything happen when having this initialise in the SSDT.

 

I will experiment a bit more and come back with results. It can´t be true that this is impossible.

 

[G.com]

Hi Toleda

 

Hoping you are still up for helping me. I really tried to get something going and realised a fact that might be part of the truth. Only problem is me not understanding all this coding. I got the logic and I understand what is happening but I do not really see through the jungle.

 

Nevertheless, difference between your file PEG0 and PEG0+ is one specific command:

 

External (_SB_.PCI0.PEG0.PEGP._ADR, IntObj)

.

.

.

Method (_INI, 0, NotSerialized) // _INI: Initialize

{

Store (0x0F, \_SB.PCI0.PEG0.PEGP._ADR)

}

.

.

.

Putting this as:

 

External (_SB_.PCI0.PEG0.PEGP._ADR, IntObj)

.

.

.

Device (PEGP)

{

Name (_ADR, Zero) // _ADR: Address

Method (_INI, 0, NotSerialized) // _INI: Initialize

{

Store (0x0F, \_SB.PCI0.PEG0.PEGP._ADR)

}

.

.

.

This makes the difference that now in IOReg the first device "PEGP" can be renamed to e.g. "GFX0". Somehow I even managed to make something wrong so system called it pci-bridge@something.

 

This leads me to the conclusion there must be a correlation between request for rebranding of pci-bridge@10 or @11 and this initialising procedure. I am just lacking understanding how to assign the correct object and initialise it correctly.

 

Does this all make sense to you? Any idea of how to solve it?

Archive.zip

[toleda]

Any idea of how to solve it?

Native dsdt does not have PEGP, reason INI is not present.

IOReg/GFX0 is on the wrong device suggesting, the original ssdt w/INI has not been removed

For pci-bridge@10, edit Post #29 ssdt to:

            Device (PLX0)
            {
                Name (_ADR, 0x00100000

Reply with IOReg, edited ssdt and clover boot log.

[G.com]

Here we go. I hope I did not miss any edit I should have done. 

 

 

Archive.zip

[toleda]

Here we go 

ssdt is loading.

edit _ADR as shown

            Device (PLX0)
            {
                Name (_ADR, 0x02100000)

[G.com]

I will give it a try but I did this without luck before. Will let you know.

 

---

 

Update : Tried - no luck.

 

Today I tried all variants and various addresses. I understood checking the boot.log for ssdt loading and ioreg to confirm if it works. I played around with various of your ssdt´s and the only one doing anything was the one attached. From all experiementing I understood the initialising does the trick.

 

If I understand right the logic, your text in the ssdt from pos #29:

 

Scope (\_SB.PCI0.PEG0)

    {

        Device (PEGP)

        {

            Name (_ADR, Zero)  // _ADR: Address

 

changed to this

 

Scope (\_SB.PCI0.PEG0)

    {

        Device (GFX1)

        {

            Name (_ADR, Zero)  // _ADR: Address

 

should show PEGP as GFX1 in IOReg - right? 

 

In my case it does not, only if I add the initialise. This is what I tried to say.

 

In fact I thought if this does not work without, how should it work dding the PLX0 without initialise?

 

Again, this is only sticking in the dark. I have no experience like you.

 

Will it be impossible that this leads use somewhere. 

 

Could it be a try to add an initialise for the PLX0? What would be the correct code?

 

 Attached the IOReg after the last edit and the only SSDT that changes anything in my system. You´ll see nothing happens.

 

 

Archive.zip

[G.com]

Just for curiosity, you realised I use the AppleHDA1150.kext? I just saw that the pikeralpha script added a clover patch. Think this is not related to the prob but just saying. 

 

<dict>

<key>Comment</key>

<string>t1-10.9-10.11-AppleHDA/Realtek ALC1150</string>

<key>Disabled</key>

<false/>

<key>Find</key>

<data>

ixnUEQ==

</data>

<key>Name</key>

<string>AppleHDA</string>

<key>Replace</key>

<data>

AAnsEA==

</data>

</dict>

 

Not that we are playing around not getting there because of something stupid like this.

[toleda]

 

Attached the IOReg after the last edit and the only SSDT that changes anything in my system. You´ll see nothing happens.

 

No true. Post #42 IOReg, shows the ssdt working.  Post #44 IOReg does not consider the multiplexer and will never work in your system. Again, the only problem is the address for the multiplexer, everything else is unrelated. Test only with SSDT-HDMI-NVIDIA-PEG0+.aml from Post #42.

 

Regarding config.plist, pikeralphaALC script does the edits you see.  There is no dependency for working onboard audio and non working Nvidia HDMI audio.  

 

[G.com]

 Hi Toleda, 

 

really tried all relevant addresses with no luck, changed the ports etc. It seems the difference to other systems with this PLX is that mine does not have a PCI-e that is bypassing it. Even the unsupported tool does only make it happen to get the HDAU set in IOReg but still the bridge is not renamed and no HDMI Audio.

 

I assume this leads to your earlier statement: Only solution is a new mainboard. Is it really not possible?

 

Could you maybe enlight me what you see that IOReg in post #42 works? What are we looking for? For me both seems the same in the display area.

I would love to dig deeper.

 

I will carry on investigating and let everybody know if I found a solution.

[toleda]

Is it really not possible?

Attach native dsdt and ssdts, use MaciASL/File/Extract Tableset..

[G.com]

Attached. Additionally, a DSDT I edited based on some threads at TM where you seem to helped some guy with the PLX0 issue on his PEX8747. It does not work.

Archive.zip

[toleda]

does not work.

Expected. Nothing in the acpi tables.