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 ...

Hey, long time not spoken to you. I'm trying to resolve EAPD issues on an Asus 1201N laptop, which has ALC269. It has EAPD on 0x14 (sp) and 0x15 (hp).. but as I have discovered EPAD on 0x15 powers on by itself .. I can just use AppleHDA with no extra verb in pinconfig and it gets enabled. Speakers on 0x14 on the other hand refuse to start regardless of timing and other stuff I have played with. What I have discovered is that querying response from IRR register always return 0 (even when audio is playing and sound works!), no matter how long you wait. By the way, the Asus has MCP79 nvidia chipset, so HDEF device location is @8, no default @1B. I was wondering if you could add the ability to specify device address (location) and not just say "HDEF not found". I bet you this would come handy for someone at one point ... I'm just curious to try your kext, because with my Commander that properly works on my Dell I can't seem to make this Asus work. It works at cold boot, but not after fugue sleep or actual sleep .. I recall I had similar issues when I had taken your AppleHDA from your Asus and adapted it for my Dell.. I had constant problems with enabling EPAD on speaker node. I then have taken my kext from 10.7 and repatched it to 10.9 and it worked a treat and still does .. flawlessly. Now, this Asus is really and I mean really stubborn.

Try this instead (sorry to hijack the thread, heh) .. make sure to configure it in plist accordingly. Sources and readme: https://github.com/Dolnor/EAPD-Codec-Commander CodecCommander.kext.zip

dupe

Yeah, thats an expected, needless to say, odd behavior. Itš not Kext Utility, it's just that for some reason unknown the kext is properly included in kernelcache only upon second installation.

Sure, I've also tossed in a DELL Confidential Datasheet for ALC269VB revision of the codec (obtained at wenku baidu for looooots of credit) so that you could see how crippled it is. By the way, this subtle difference in microphone nodes comes from this Dell proprietary change to the codec. for_osxlat_alc269.zip

Now, that is odd .. I re-did the entire kext and the loss of audio still happens, I wonder if antipop is the one to blame now, because the exact same thing now happens on my desktop, where EAPD is not present at all. UPDATE: There, spot 10 differences .. except your mic is on node 0x19, mine is on node 0x12, the rest is absolutely the same .. and yet the audio is not resuming properly. I got rid of antipop and com.apple.audio.ServerSettings script to no avail .. ALC269VB_DELL.zip UPDATE2: I see in the log the following line with 10.9.2: PM kernel[0]: Sound assertion in AppleHDAFunctionGroup at line 1042 Which I traced back to the function called AppleHDAFunctionGroup::setPowerState(unsigned int, bool) Therefore I can assume it's a bug in the kext that only shows up for certain *blessed* people out there...

Same behavior observed with build C39, which makes me believe we will see same kind of problem when release update hits. Bummer. I've tried looking around for 25000ms delays in all the binaries but locating the culprit does not appear to be easy ...

Things are not looking good for future OSX releases... updated to 10.9.2 build C32, it has AppleHDA of version 2.6.0 Even though you can make an audio stream start by some means (antipop, NX keypress for sound conrtrol or just general F-key press to trigger a *bonk* sound) the audio will be suppressed again after exactly 25 seconds. I've timed it hitting the F10 key after waking the machine up... hitting it every 24 seconds produces a *bonk*, but miss a second and audio stream is gone. It was working flawlessly prior to 10.9.2 beta update though.. so something has clearly changed in the big picture. Edit: It actually makes me think that due to the nature of audio stream's passthrough to speakers via EAPD there is some sort of checks involved after sleep in one of the binaries inside AppleHDA (either the main binary itself or one of the plugins, perhaps DspLib) that have this 25000ms delay defined after which audio stream to the respective node gets cut and codec just stalls now knowing what to do, hence jack sensing breaks. And with version 2.6.0 these checks have gotten much more severe.. perhaps our codec won't return some kind of response that the kext expects to get so it just shuts it off after 25 second. And what previously was just a one time deal now became a routine in a form of loop or something... Any thoughts ?

I've noticed that with version 1.2 upon wakeup when volume control bezel appears an extra character is being typed into the password field as if the volume control key press is not the only key that is being emulated upon wakeup. I'd suggest to emulate a mute/unmute event instead of volume up or down event. Also, oddly enough, even though the bezel comes up there is no *pop* sound being emitted from the speaker, which in hand means that audio stream is not enabled. With version 1.0 everything happens as expected.

To try and help you need to study Intel High Definition Audio specification as well as codec datasheet for some variations of ALC269 (modification VB perhaps) to be able to know how verbs are sent to controller and what verbs handle what on the codec nids. I've tried manually (by sending verbs) rerouting widget, i've tried forcing widget to be unmuted and i've tried toggling jack insertion for hp socket .. all to no avail. FreeBSD guys have figured the reason for it, but the fix with AppleHDA is not really coming to me .. Here are the details link