EMlyDinEsH Posted January 16, 2014 Author Share Posted January 16, 2014 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 ? No idea, but i have not tested this version of AppleHDA yet in my notebook. Will give it a try today and let you know if i find anything useful. Link to comment Share on other sites More sharing options...
Dolnor Posted January 17, 2014 Share Posted January 17, 2014 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 ... Link to comment Share on other sites More sharing options...
EMlyDinEsH Posted January 17, 2014 Author Share Posted January 17, 2014 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 ... I have tested 2.6.0 AppleHDA from 10.9.2beta today and found no problems like you explained. Its working fine to me after 30 sec from sleep in both Jack sense and audio with my EAPDFix like before. I'm attaching my patched kext for your reference, so you can get some idea from my patched files. AppleHDA_ALC269_Patched_2.6.0.zip 1 Link to comment Share on other sites More sharing options...
Dolnor Posted January 17, 2014 Share Posted January 17, 2014 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... Link to comment Share on other sites More sharing options...
EMlyDinEsH Posted January 20, 2014 Author Share Posted January 20, 2014 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... Can i take a look at your codec dump and patched AppleHDA? So i can see the differences between yours and me to understand this better in order to look for any solutions. Link to comment Share on other sites More sharing options...
Dolnor Posted January 20, 2014 Share Posted January 20, 2014 Can i take a look at your codec dump and patched AppleHDA? So i can see the differences between yours and me to understand this better in order to look for any solutions. 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 Link to comment Share on other sites More sharing options...
lassard Posted January 28, 2014 Share Posted January 28, 2014 My codec is ALC269VC, already tried EAPD Fix and EAPD Codec Commander, but on both I lose sound after sleep (instantly). According to EAPD Codec Commander readme, I'm on the case mute=1 on node 0x0f. Curiously, I've installed EAPD Fix via Kext Utility while I was without sound (after a sleep), and then during the installation (caches regeneration, etc.) the sound started to work again. edit: this same curiosity happens for CodecCommander! Link to comment Share on other sites More sharing options...
Dolnor Posted January 28, 2014 Share Posted January 28, 2014 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. Link to comment Share on other sites More sharing options...
lassard Posted January 28, 2014 Share Posted January 28, 2014 Just wanted to add one more thing I noticed: the audio loss happens after sleep only if I wake the PC right after sleeping it. If I let it completely sleep (you know, the Mavericks delay it takes until the PC really sleeps), then the audio is fine. Link to comment Share on other sites More sharing options...
liaobamboo Posted February 23, 2014 Share Posted February 23, 2014 I am using VIA VT1802P. Can i try your kext? I have a problem of no sound after wake up from sleep. Link to comment Share on other sites More sharing options...
Recommended Posts