Contribute
Register

Haswell HDMI Audio (v1 Archive)

Status
Not open for further replies.
Joined
Sep 18, 2011
Messages
190
Motherboard
Vostro 3450 A13C4
CPU
i3-2350M
Graphics
HD 3000
Mac
  1. MacBook Pro
  2. Mac mini
Mobile Phone
  1. Android
Is HDMI audio properly resuming for you after sleep, toleda?
Mine doesn't and comes up with a sound assertion message: Sound assertion in AppleHDAWidget at line 4264
Monitors remains connected properly and codec is attached in IOReg but it feels the same way as EAPD update would have been missing on some mobile codecs (like ALC665 and ALC269).. everything seems to be in order and yet there is no sound coming via HDMI..
 
Haswell HDMI Audio

Sorry! HDMI Audio for Haswell works perfectly, thanks to Pike for finding the cause of the controller initialization fail (Apple purposely failed us?). I had my ways around the audio issue (both the patch and the dsdt edit), so I can't really comment on your particular solutions, I can though say what worked for me (even tough I've mentioned it over at IM already).

1. On my H87-HD3 board with an i5-4570S I didn't have to edit the framebuffer, 160a framebuffer gives me connector-type 8 and signal-type 8 @2 (port 0x6)
2. I had my custom SSDT table coded through scopes (actually before bcc9 suggested it), so I hadn't done any new ACPI edits when Pike proposed his workaround.
Code:
    Scope (\_SB.PCI0)
    {
        Scope (\_SB.PCI0.IGPU)
        {
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package ()
                    {
                        "AAPL,ig-platform-id", 
                        Buffer (0x04)
                        {
                            0x00, 0x00, 0x16, 0x0A
                        }, 

                        "device-id", 
                        Buffer (0x04)
                        {
                            0x16, 0x0A, 0x00, 0x00
                        }, 

                        "graphic-options", 
                        Buffer (0x04)
                        {
                            0x0C, 0x00, 0x00, 0x00
                        }, 

                        "subsystem-id", 
                        Buffer (0x04)
                        {
                            0x1A, 0x01, 0x00, 0x00
                        }, 

                        "subsystem-vendor-id", 
                        Buffer (0x04)
                        {
                            0x6B, 0x10, 0x00, 0x00
                        }, 

                        "hda-gfx", 
                        Buffer (0x0A)
                        {
                            "onboard-1"
                        }
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }

        Scope (\_SB.PCI0.HDEF)
        {
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package ()
                    {
                        "MaximumBootBeepVolume", 
                        Buffer (One)
                        {
                            0x5D
                        }, 

                        "MaximumBootBeepVolumeAlt", 
                        Buffer (One)
                        {
                            0x00
                        }, 

                        "subsystem-id", 
                        Buffer (0x04)
                        {
                            0x70, 0x72, 0x00, 0x00
                        }, 

                        "subsystem-vendor-id", 
                        Buffer (0x04)
                        {
                            0x86, 0x80, 0x00, 0x00
                        }, 

                        "layout-id", 
                        Buffer (0x04)
                        {
                            0x0C, 0x00, 0x00, 0x00
                        }, 

                        "PinConfigurations", 
                        Buffer (Zero) {}, 
                        "PlatformFamily", 
                        Buffer (One)
                        {
                            0x00
                        }
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }

        Scope (\_SB.PCI0.HDAU)
        {
            Method (_DSM, 4, NotSerialized)
            {
                Store (Package ()
                    {
                        "hda-gfx", 
                        Buffer (0x0A)
                        {
                            "onboard-1"
                        }
                    }, Local0)
                DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
                Return (Local0)
            }
        }
    }
And again, I'm proposing you add MaximumBootBeepVolume key to your custom ACPI tables so that users wouldn't get 599 assertion.
3. The patch I've used for HDAController is proven to be universal (at least point in time), details on it are posted in bcc9's thread over IM. Basically it requires the controller to be patch alike AppleHDA for primary codec substitution, but not quite.
0b0c0000 to 0c0c0000 so that the check wouldn't jump to a dead end of the check sequence
0c0a0000 to 0c0c0000 so that our controller would get initialized and not checked for Apple's controller id match.


I've tried your SSDTs from git as well, an what I had issues with was some of your SSDT edits though. Having the checks inside IGPU, HDEF and HDAU that checks the Arg0 value and returns 0x03 as buffer for some reason was preventing the main HDEF codec from starting on board, so I had to just leave the main Buffer that is being returned in the method. The patches to connectors for 0x0d220003 don't seem to work for my board and the screen comes up fuzzy with huge delay, probably it would have if I had DP. The controller kext patch works the same way as the patch I'm proposing, but achieves the controller initialization in a different manner, which will require recalculation with future OSX updates.

Oh, thanks for pointing the image out! I've seen it and skimmed it once already, but haven't noticed it said anything about HDMI non resuming from sleep. I didn't know it was an OSX bug, I somehow thought it was working for me at some point and it got me really mad, you know the feeling when something breaks for no reason and you know you haven't done anything..
 
Haswell HDMI Audio

The patches to connectors for 0x0d220003 don't seem to work for my board and the screen comes up fuzzy with huge delay, probably it would have if I had DP.
In my testing, the 160a framebuffer does not get to the desktop. Additional testing is showing, with one more edit, HDMI, DVI and DP are supported in all combinations. If convenient, attach an IOReg with the HDMI patched 0x0d220003.
 
Haswell HDMI Audio

In my testing, the 160a framebuffer does not get to the desktop. Additional testing is showing, with one more edit, HDMI, DVI and DP are supported in all combinations. If convenient, attach an IOReg with the HDMI patched 0x0d220003.

I don't quite feel like redoing the patch to get you a dump, but I should say that this patch that Pike says worked for you:
Code:
0300 220D 0003 0303 0000 0002 0000 0001
0000 0000 0000 0040 9914 0000 9914 0000
0000 0000 0000 0000 

0105 1200 0004 0000 8700 0000
0204 1400 0004 0000 8700 0000
0306 1000 0008 0000 0000 0000 

FF00 0100 0100 0000 4000 0000 
0200 0000 0101 0000 0400 0000 
0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
Doesn't work on my board. Screen comes on fuzzy after loginwindow starts and stays like that for good 7 to 10 second, then it jumps to a connectors that works I assume and comes on fine, but HDMI audio is not working (connector type not set to8) as it ends up being a DP connector out of the two remaining.

However, this patch, that was also proposed by Pike to resolve HDMI black screen in one of the DPs works a threat! Not sure what the consequence of removing all of the delays might be for people who use multiple displays setup though.
Code:
0300 220D 0003 0303 0000 0002 0000 0001
0000 0000 0000 0040 9914 0000 9914 0000
0000 0000 0000 0000 

0306 1000 0100 0000 0000 0000
0105 1200 0400 0000 0000 0000
0204 1400 0008 0000 0000 0000

FF00 0100 0100 0000 4000 0000 
0200 0000 0101 0000 0400 0000 
0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
So it seems like for H87-HD3 the 0204 connector is recommended for HDMI patch.
 
Haswell HDMI Audio

I'm sorry, but isn't there some kind of mistake in Patch Azul for HDMI on AppleIntelFramebuffer@1 section?
The connector layout in this patch pattern ends up being:
Code:
0105 1200 0004 0000 8700 0000 @0
0204 1400 1200 0008 0000 0600 @1
0306 1000 0008 0000 0000 0000 @2
What's 1200 here anyway? Should it be 0008 0000 and not 1200 0008 for that particular connector?
And shouldn't @2 remain stock, I mean remain type 04 and not 08?
 
Haswell HDMI Audio

I'm sorry, but isn't there some kind of mistake in Patch Azul for HDMI on AppleIntelFramebuffer@1 section?
My mistake. Thanks bringing this to my attention. Post #1 edited.
Code:
@0
0105 1200 0008 0000 0600 0000 
0204 1400 0004 0000 8700 0000
0306 1000 0004 0000 1100 0000 

@1
0105 1200 0004 0000 8700 0000 
0204 1400 0008 0000 0600 0000
0306 1000 0004 0000 1100 0000
 
Haswell HDMI Audio

Updated to 10.8.5 supplemental update, which supposedly had to fix HDMI audio not resuming from sleep.. but it hasn't, there is still kernel[0]: Sound assertion in AppleHDAWidget at line 4264 in IOLog after waking up and sound over HDMI remains muted. Does it also happen with Pike's patch pattern?

AppleHDAWidget::modifyFormat (unsigned int) produces assertion 4264
AppleHDAEngine::getTimeSinceDMABufferWrap() produces assertion 2001
 
Status
Not open for further replies.
Back
Top