Dolnor

Some entries in your DSDT patch doesn't make any sense. There's no such property as IOAudioPower state on HDEF. Specifying device-type is not required, HDEF is already treated as being built-in by default and you are missing MaximumBootBeepVolume which will results in sound assertions in your console. Specifying AFGLowPowerState on most codecs (ALC269 most certainly) will result in complete audio loss after first sound is played.

I told you it was a problem with your pinconfig and not the kext itself. To see if jack sense problem would be gone try the following patch with clover (valid for 10.9.4 and 10.9.5): Also, try disabling Generate Stream and set Simulate Headphones to 0. You should see fully working sound before and after with no extra notifications and additional EAPD updates with 30 second delays .. I'm working towards finding a universal solution to this problem, but being alone on this kind of sucks..

Ha, actually with the patch in place popping the bezel to get jack sense working is not required! Which confirms it's not the problem with either the controller or codec (internal connections) itself, but with the way AppleHDA treats power state switching for Intel chipset HDA controller. This jack sense loss issue doesn't exist on MCP chipset. This definitely needs to be looked into ..

Some recent observations about second audio loss (after first PIO completes) - if you don't pop the bezel or play any sound immediately after wake EAPD and audio will continue working without the need for second PIO. However, not popping the bezel at wake results in jack sense loss on Intel chipset controllers. I have looked in AppleHDA binary and the issue appears to be related to AppleHDAFunctionGroup::setPowerState(unsigned int, bool). Removing one of the checks in this procedure causes the codec to work as it worked before 10.9.2 regardless of popping the bezel or not. But one sound assertion is produced when AppleHDAFunctionGroup::performPowerRailSave() is called. The patch can't be made universal, unfortunately.. I have to study this further, but my knowledge is kind of limited here..

CodecCommander does everything as it should. The status reported is also correct, but something is wrong in the configuration. Can you double check that path for Output exists ??? I don't see jack inerstion being simulated in your log.

I see you already had it compiled (ver 2.1.2), just add the profile from the kextI have included.

Try these files: 1. Replace your kext patches in Clover with the ones I have provided 2. Replace your pinconfig injector (I have fixed your pinconfig) 3. Add aml.zlib resources to your AppleHDA Resources replacing the ones your (probably) had 4. Replace your DSDT in /patched folder, I've fixed HDEF and added OEM info to PS2K (hopefully won't break your keyboard prefs) 5. Install CodecCommander (added your OEM profile to test) 6. Remove kernelcache manually and sudo touch /System/Library/Extensions to make sure all the kexts are loaded sherlocks_270_cc_set.zip

First,something is not right with your output number, you shouldn't see this spam. Second, are you using the AFGLowPowetState property in pinconfig/Clover/DSDT? Third, define RM,oem-table-id _DSM property on your PS2K device in DSDT. Use the table ID from DSDT header. The problem can also be related with badly patched kext. I had this happen on my DELL and ASUS, but it was resolved by thoroughly fixing pinconfig .

Happy birthday Dinesh! Unfortunately, your kext fails even at cold boot, with either 3 or 5 sec interval. The log is cold boot + one iteration of LID sleep/wake. No sound before or after sleep. 7/6/14 9:46:53.000 PM kernel[0]: EAPDFix v1.7.1 Final Copyright (c) EMlyDinEsH (OSXLatitude) 2013-2014. 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:46:54.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:48:32.000 PM kernel[0]: EAPDFix: Background status check disabled before sleep. 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:48:51.000 PM kernel[0]: EAPDFix: Background status check enabled after sleep. 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:48:58.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:27.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:33.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Speakers EAPD is down, Trying to power up... 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Current output is Speakers. 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Headphones EAPD is down, Trying to power up... 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Codec verb sent successfully to power up EAPD. 7/6/14 9:49:37.000 PM kernel[0]: EAPDFix: Current output is Speakers. CodecCommander config versus EAPDFix config: CodecCommander debug log. Sound from speaker and headphones before and after sleep. No jack sense issue on MCP79 chipset. 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: commander initializing 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: board make - ASUS 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: board model - 1201N 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: commander probing 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: commander version 2.1.1 starting 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: hi: keyboard device attached 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: hi: keyboard device created 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: infinite workloop requested, will start now! 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: running on MCP chipset, workloop limited to 4 PIOs 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: --> awake 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: --> hda codec power restored 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: hi: keyboard initializing 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: hi: keyboard starting 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1470c02 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: --> PIO event #1 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1570c02 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: --> PIO event #2 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:27.000 PM kernel[0]: CodecCommander: cc: --> workloop started 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: cc: --> audio stream active 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: ICW stored get command 14f0c00 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: ICB was set, sending verb over the link 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: IRR isn't set, EAPD inactive 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: ICW stored get command 15f0c00 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: ICB was set, sending verb over the link 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: r: IRR isn't set, EAPD inactive 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1470c02 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: cc: --> PIO event #3 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1570c02 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: cc: --> PIO event #4 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:00:47.000 PM kernel[0]: CodecCommander: cc: workloop ended after 4 PIOs 7/6/14 10:01:55.000 PM kernel[0]: CodecCommander: cc: --> asleep 7/6/14 10:01:55.000 PM kernel[0]: CodecCommander: cc: --> amp assumed enabled by now 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: cc: --> awake 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: cc: --> hda codec power restored 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1470c02 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: cc: --> PIO event #1 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1570c02 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: cc: --> PIO event #2 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:02:06.000 PM kernel[0]: CodecCommander: cc: --> workloop started 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: cc: --> audio stream active 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: ICW stored get command 14f0c00 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: ICB was set, sending verb over the link 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: IRR isn't set, EAPD inactive 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: ICW stored get command 15f0c00 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: ICB was set, sending verb over the link 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: r: IRR isn't set, EAPD inactive 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1470c02 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: cc: --> PIO event #3 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: ICW stored set command 1570c02 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: ICB was set, sending verb over the link 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: cc: --> PIO event #4 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: w: IRV was set by hardware 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: rw: IRV cleared, allowing new commands 7/6/14 10:03:03.000 PM kernel[0]: CodecCommander: cc: workloop ended after 4 PIOs

Updated to 10.8.5 and it stopped working, same scenario as in 10.9.x ... So I immediately recalled the chit-chatting about this we had with @tluck over at InsanelyMac. His T420 has had the same problem happen after 10.8.5 rolled out. The problem is related to an ACPI bug introduced with 10.8.5, it was discovered by RehabMan and a fix is included in his repository for laptop patches. After implementing the fix EAPD now resumes properly .. the IRR register, like I said, still returns 0 instead of 1, even though EAPD is set high ..

So, just an update to the story .. fighting through the installers with a broken touchpad and thus semi-dead PS/2 controller I managed to jump away from 10.9 for testing. I have installed 10.8.3 for now (had the MAS .app backed up from back in the day and never updated it to 10.8.5) and CodecCommander properly wakes EAPDs after sleep ... not seeing bezel popping though, but I guess I just need a higher stream delay, since it's an Atom-based laptop .. I will update to see if audio breaks somehow (similar to what happens in 10.9) and report once more.. P.S. Even though EAPD is active I'm still getting 0 from IRR register getStatus .. so MCP chipset definitely acts different.

I was swapping my HDDs today to preserve 10.9 and install 10.7 for testing (I didn't want to use USB because laptop can't wake with USB HDDs) and damaged my touchpad flex cable. Now it doesn't work and keyboard is not being initialized by voodoops2 either (at least keyboard works in windows, sigh). Guess I will need to hook up external peripherals now in order to investigate further ... will keep you posted.

No dice... It seems like 0x15 EAPD is just supplemental and is used to prevent audio from popping too loud (which happens on my Dell where there's no EAPD on speaker node). If you don't send verb for 0x15 the audio in headphones works at wake, but is considerably less loud, compared to loudness level at cold boot. Investigating the issue of constantly getting status read 0 from IRR when audio is functional has lead me to finding a piece of information that some codecs may use inverted logic, as in, bit mask 00 enables the amp and bit 01 disabled the amp. I've tried inverting the logic on Asus with no success, unfortunately. There are codecs that use internal pull-down resistor to prevent EAPD from drifting high *by accident*. Some codecs need compliant driver to reset this resistor, but some use additional pull-up resistor, which when codec resets power (power lost -> power restored) pulls EAPD leg on the codec chip high and it can be enabled programmatically. What drives me insane though is that I'm seeing reports from the past that patched IOAudioFamily was working to enable EAPD after sleep in 10.7 ... perhaps I should start there. Or, like I said before, It's the AppleHDA that is improperly patched and does all sorts of random stuff at wake. But I have revised it and found no obvious mistakes, at least from my point of view.

Okay, it seems like consecutively sending multiple verbs to the pipe doesn't work on MCP chipset while it works on Intel and you can spam it heavily. On this Asus you can't be reading the latch response from IRR the moment after you have pushed the verb (so I can't monitor EAPD state and IOAudioEngine state at the same time.. but it looks like its not even needed because audio remains working even after a single PIO). You can't send two consecutive verbs to enable speaker and headphone either.. there has to be a descent pause. The situation is actually kind of funny. I can send a single EAPD enable verb for node 0x15 (headphones) and speaker EPAD gets enabled, but I loose jack sense right away... While sending just the verb for node 0x14 doesn't enable speaker.. Go figure, Asus... send for 0x14 0x15 - no sound from speaker after sleep, because can't send two verbs send for 0x14 - no sound from speaker at boot and working sound from headphones / working sound from speaker and headphones after wake send for 0x15 - sound from speaker at boot, sound from speaker at wake, no sound from headphones.. workaround for fugue sleep when codec looses power: - define 01470c02 in pinconfig to enable EAPD on 0x14 at boot - update 0x15 at fugue wake using CodecCommander ... after machine is properly put to sleep sound doesn't resume... so its either ACPI bug or the kext is very picky and has to be patched in some weird way ...