In AppleIntelFramebufferAzul.kext Part I and in AppleIntelFramebufferAzul.kext Part II we discussed a number of new/unknown/changed values (properties) and today I like to inform you about another important change.
In previous framebuffer versions from Apple it was not required to use the correct connector-type, since Apple wasn’t using/checking it, but that has changed with OS X 10.9 aka Mavericks and the release of OS X 10.8.5 so from now on you’ll need to use 8 for HDMI or HDMI audio won’t work.
You can verify this yourself by using the following two patches for Mavericks DP8:
sudo perl -pi -e 's|\x3d\x0c\x0c\x00\x00\x75\x61\xeb\x30|\x3d\x0c\x0c\x00\x00\x75\x61\xeb\x0e|g' /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAController.kext/Contents/MacOS/AppleHDAController sudo perl -pi -e 's|\x3d\x0c\x0a\x00\x00\x74\x07\x3d\x0c\x0d\x00\x00|\x3d\x0c\x0a\x00\x00\x74\x07\x3d\x0c\x0c\x00\x00|g' /System/Library/Extensions/AppleHDA.kext/Contents/Plugins/AppleHDAController.kext/Contents/MacOS/AppleHDAController
This should enable HDMI audio, and if not then your framebuffer data isn’t correct. Patching AppleIntelFramebufferAzul.kext is easy with AIFBAzul2.sh from Resolving The DP4 HDMI Hang. Use that script and start patching your frame buffer data to get HDMI audio going.
Have fun with HDMI audio 😉
Update:
Here is the frame buffer data that works for Toleda:
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
We removed the delay of the third connector (factory data: 0306 1000 0004 0000 1100 0000) to force select port-number 7. Something that is required to get HDMI audio on this connector going. The result is port-numbers: 5 (DP), 6 (DVI) and 7 (HDMI) instead of 5, 6 and 0. We also changed the connector-type from 04 into 08 (see green byte).
The only problem is that your motherboard may use a different layout, and thus you first need to figure out where the connectors show up in IORegistryExplorer. Then you can start making the required changes.
Pike's Universum 
Thank you, Pike, for sharing this solution!
So, I was looking in correct place afterall, but not the correct procedure… bummer.
Though, the patch is nowhere universal, because the binary from 10.8.5 does have a different structure in terms of cmpl, jne opcode sequence for the first one-liner.
Since we are already jumping places, I found it more feasible to just jump all of the checks inside setupHostInterface() procedure (much like Sam was doing, patching the Wolfson codec and jumping right to the spot she needed), this way only a single patch is required and HDMI audio gets enabled properly (if correct igd-platform-id is used of course).
All in all, for 10.8.5 the following needs to be patched:
0f858c01 0000 to 0f848e00 0000,
this way in 0x55aa subroutine we don’t end up getting lost in series of checks, because jne returned false, but instead we go straight to 0x5695 offset.
The sound assertion 599 error that comes from AppleHDA binary itself still persist, but it’s a new one that was introduced with 10.8.5 and up, I hadn’t it on my laptop previously, but after updating to 10.8.5 it popped up. I’ve looked and there are at least 5 subroutines that could return lion 599 assertion, so I’m not really bothered as I know it shouldn’t impact anything, at least not at this point. And your second (the longer one) perl one-liner doesn’t prevent it either.
[img]http://puu.sh/4zNyW.png[/img]
[img]http://puu.sh/4zNzC.png[/img]
Sure no problem. That is after all what this blog is all about. Sharing stuff.
About the jump (address). Use whatever works for you. It doesn’t really matter, as long as it is working.
The address for 10.8.5. is correct. I know because I patched the kext for Toleda, who will soon have more news about this HDMI solution.
I don’t use OS X 10.8.5 myself, but I have seen the 599 error in AppleHDA (I think) and thought about modding translateTagToStatefulTag so have a look at it. With Hopper for example.
Oh and thank you for reporting your success 🙂
Speaking of patching, pikeraplpha, you had originally posted a kernel patch for 10.8.4 to have Haswell cpu enabled. It was to swap eb0a83f83a with eb0a83f83c. For ‘some’ haswell systems, 10.8.5 still does not work, and require cpus=1 boot flag. Obviously, this patch does not work for 10.8.5. How would I go about finding what the equivalent of this patch is for 10.8.5. Thanks…
In that case it is better to wait for Apple to release the source code of 10.8.5 (sorry. I have very little free time left to work on hackintosh stuff these days).
No worries. Thanks anyway.
Heads up on 599 assertion.
It actually comes from AppleHDAEngine::init() procedure and the cause of it is that now AppleHDA checks for MaximumBootBeepVolume device property (possibly MaximumBootBeepVolumeAlt, haven’t dug deep into it), upon initiating the codec to determine the loudness of the POST sound (the *bong* sound volume if you will).
Added it through _DSM to device HDEF like so: http://pastie.org/pastes/8355022/text
Could be simply done via device-properties string as well, but I’m an ACPI kind of guy. The assertion error has vanished from IOLog on both of my machines.
The value could be anything I reckon (well, should be within the range Apple uses), as it doesn’t actually do anything on a hack.
Ah yes now I remember. Sorry. I have written so many patches that it is really hard for me to remember everything.
Oh by the way. Wasn’t it so that the audio volume changes with the level of MaximumBootBeepVolume?
Update:
On a second thought. I have to retract that. I mean. I can confirm that I had seen error 599 (with both properties set, with OS X 10.9) but I cannot remember the exact text of the error and thus I will need to check my notes tomorrow to see if we are talking about the same error 😉
Update-2:
Right. Same error but different line (error code). That was why we added the device-properties (had to check my notes).
Note: The error with 10.9 Developer Preview 8 is now: “Sound assertion in AppleHDAEngine at line 581“.
Thank you for the reminder!
Thanks a lot for fixing the sound assertion, it’s gone.
Pingback: Haswell HDAU solution | Pike's Universum
Ehh well, not everything is so good afteral. I’ve put my computer to sleep today for the first time these past days and upon waking up HDMI sound is not functioning properly. Console spits out:
kernel[0]: Sound assertion in AppleHDAWidget at line 4264
sometimes more than once and HDMI sound doesn’t seem to work, while the main HDA codec resumes from sleep. This assertion seems to be coming from AppleHDAWidget::modifyFormat (unsigned int) procedure that I can’t find any connection with. HDMI monitor remains connected and all the menus report it’s active.. except IOReg doesn’t show that EngienClocIsStable..
Any hints about sleep/wake cycles?
Aheme! Apparently it’s an OSX bug as of 10.8.5, as pointed out to me by toleda. So false alarm there!
I specifically checked sleep/wake before releasing my patch to Toledo, with OS X 10.9 Mavericks only since I don’t have 10.8.5 installed, and not only HDMI audio works after waking up from sleep, but there are no errors whatsoever.
Does it matter what patch you use? Here I also patch the hda-gfx hander and you?
Yeah, me too.. at least now, with the patch I’ve posted over at IM in bcc9’s DP thread.
gfxMatchedHandler, setupHostInterface and activateAudioStreamGated procedures are being patched.
toleda has pointed me here, showing it was a bug in OS X 10.8.5 and it’s expected to be fixed soon: http://9to5mac.com/2013/10/02/new-os-x-10-8-5-itunes-safari-builds-seeded-internally-as-releases-near/
I’m aware about the update, and it may fix your problem with HDMI audio, but I wonder why you run into this problem and others not. What’s the difference?
Who are these *others* ? Based on the feedback in toelda’s thread over at tonymac nobody even tried to make HDMI audio work yet. As there was no official buyers guide for Haswell build from tonymac people are still getting Ivy Bridge machines based on their recommended parts list. I’ve tried the patch you gave to toleda as well as swapped the idg platform id to 0300 220D as suggested (mine requires different connector from it to be patch though) and thre result is the same.
Also, the updated hasn’t resolved anything, but just made it worse somehow, now there’s an extra assertion being produced by HDAEngine.. there are these two after the supplemental update:
AppleHDAWidget::modifyFormat (unsigned int) produces assertion 4264
AppleHDAEngine::getTimeSinceDMABufferWrap() produces assertion 2001
The other people I was referring to are a number of people I work with. They don’t see a single error, and they don’t have issues with HDMI audio after a sleep/wake cycle. I have no idea if that changed with the update, but I will ask around to see if that changed. We might need to check the disassembled code for changes, and see if we can work around it.
I’ve installed 10.9 GM and the issue is not present there, HDMI audio resumes from sleep properly. So it’s still a bug, even after 10.8.5 supplemental 1.
Pingback: Yosemite DP6 with HD4600 | Pike's Universum
Pingback: AppleIntelSKLGraphicsFramebuffer.kext – Pike's Universum