Headphone jack issue about t480-opencore-hackintosh HOT 48 OPEN

Yeah, the problems are probably similar, but in different, bad codecs. If the codec-configs are of bad quality, thats not really a bug in the appleALC-"core"

from t480-opencore-hackintosh.

Reposting required steps by fewtarius here.

@benbender Removed ALCPlugFix and tested your AppleALC, no problems so far after 3-4 sleep cycles. I think after a few more days, it'll be safe to say that the changes can be made into a PR upstream. Meanwhile I'll push your kext into the repo and advise to remove existing ALCPlugFix.
Thank you @fewtarius for helping out!

If you're curious, as to how we resolved this, here's what we did.

We started by downloading the AppleALC source code and making sure we could do a test build. Next we looked at your codec dump, specifically your headphone jack input and output and your internal speaker out. We wanted to verify that the output supported EAPD, and the input supported JackSense. We confirmed both. The outputs supported EAPD (EAPD Detect), and the jack mic supported JackSense (In Detect).

Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Speaker Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x00 0x00]
  Pincap 0x00010014: OUT EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x90170110: [Fixed] Speaker at Int N/A
    Conn = Analog, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 1
     0x02

Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0001001c: OUT HP EAPD Detect
  EAPD 0x2: EAPD
  Pin Default 0x04211020: [Jack] HP Out at Ext Right
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=01, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0
  Connection: 2
     0x02* 0x03

Node 0x19 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
  Amp-In vals:  [0x00 0x00]
  Pincap 0x00003724: IN Detect
    Vref caps: HIZ 50 GRD 80 100
  Pin Default 0x04a11040: [Jack] Mic at Ext Right
    Conn = 1/8, Color = Black
    DefAssociation = 0x4, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

Once we had this data, we inspected the pin config data in AppleALC for ALC285 layout 21 (AppleALC/Resources/PinConfigs.kext/Contents/Info.plist) with ProperTree and learned that the EAPD signal was only being sent to the internal speakers, and no pin widget control signal was being sent to the jack mic. This means the jack was not being put into the proper state after a wake event. To remedy this we needed to update the ConfigData and the WakeConfigData to send the proper signals.

Original ConfigData:

01271C10 01271D01 01271EA6 01271F90 01471C30 01471D01 01471E17 01471F90 01971C00 01971D10 01971E8B 01971F04 02171C20 02171D10 02171E2B 02171F04 01470C02

Original WakeConfigData:

01470C02

Each of the bytes above represent a pin complex, you can break the pin complex down like this:

  0  19 707  25
  │ └┬┘ └┬┘ └┬┘
  │  │   │   │
  │  │   │   │
  │  │   │   │
  │  │   │   └───── Instruction
  │  │   └────── Verb
  │  └─────── Node Location
  └──────── Codec # (Usually 0)

Each of the verbs that can be sent to the codec are documented in the Intel HDA specification manual, but we know that the EAPD verb is 70C and the Pin Widget Control verb is 707.

Looking at the data above we can quickly see that we're missing both the pin widget control verb and EAPD on the headphone switch. To correct this we simply add the verbs to the configuration data, and recompile AppleALC.

To correct EAPD, we add 02170C02 which sends the EAPD enable signal to node 21. To correct the jack mic, we add 01970725 which sends the Pin Widget Control signal to node 19. We add the EAPD verb to both the ConfigData, and the WakeConfigData and the Pin Widget Control signal to the WakeConfigData. ConfigData is used by AppleALC on initialization, and WakeConfigData is used on each wake event. We used ProperTree to update the data.

Corrected ConfigData:

01271C10 01271D01 01271EA6 01271F90 01471C30 01471D01 01471E17 01471F90 01971C00 01971D10 01971E8B 01971F04 02171C20 02171D10 02171E2B 02171F04 01470C02 02170C02

Corrected WakeConfigData:

01470C02 02170C02 01970725

After we've updated the pin config for this codec and layout, we simply compile and test to ensure everything works on wake. We also want to make sure that we remove VerbStub, CodecCommander, ALCWakeFix, and any other helper that may be installed as those helpers can clobber the fix.

from t480-opencore-hackintosh.

@zombillano It doesn't seem to be a bug in AppleALC but rather incomplete/bugged codec-configs. So there are separate issues for both machines as they are using different codecs. But I may have learned enough tonight to port the proposed fix from the X1C6 over to the T480. I'll try if it shows to be stable.

from t480-opencore-hackintosh.

Hey, I've tried to do the fix and have a testbuild for you. As always: feedback welcome!

                                        <key>AFGLowPowerState</key>
                                        <data>AwAAAA==</data>
                                        <key>Codec</key>
                                        <string>Armênio - Realtek ALC257 - Lenovo T480</string>
                                        <key>CodecID</key>
                                        <integer>283902551</integer>
                                        <key>ConfigData</key>
                                        <data>
-                                       ASccEAEnHQEBJx6gAScfkAGXHCABlx0wAZce
-                                       gQGXHwEBRxwwAUcdYQFHHhABRx+QAUcMAgIX
-                                       HEACFx1wAhceIQIXHwECFwwC
+                                       ASccEAEnHQEBJx6gAScfkAGXHCABlx0QAZce
+                                       iwGXHwQBRxwwAUcdAQFHHhABRx+QAUcMAgIX
+                                       HEACFx0QAhceKwIXHwQCFwwC
                                        </data>
                                        <key>FuncGroup</key>
                                        <integer>1</integer>
                                        <key>LayoutID</key>
                                        <integer>86</integer>
                                        <key>WakeConfigData</key>
-                                       <data>AUcMAg==</data>
+                                       <data>AScMAAGXDAABRwwCAhcMAg==</data>
                                        <key>WakeVerbReinit</key>
                                        <true/>

AppleALC-1.5.4-RELEASE-T480-Fix-BetaBuild.zip

from t480-opencore-hackintosh.

@zombillano here is my latest (beta) T480 OC-folder. May contain bugs but should be good enough to verify if the problem is config-relatd: T480-Latest-OC-063.zip

from t480-opencore-hackintosh.

@zombillano Hmm, tbh, if you have to ask such a question, you maybe shouldn't use my zip. Its straight from my hdd and you'll have to adapt and there will be errors quite surely... Don't want to be rude or so, but it may be better to leave it alone. But to answer your question: Yes, sure, you have to compile them - and there is an update.sh inside for convenience. But it's generally not complete for filesize reasons and, as I said, needs adaption.

from t480-opencore-hackintosh.

More native, better abstraction & more flexibility.

We don't need to be afraid of a few lines dsl-code. While it is true that less code contains less bugs, in those cases it doesn't hurt and, f.e., benefits testing or completeness.

from t480-opencore-hackintosh.

In your case I don't wanted to be rude - as I said above. It was more like a hint with good intentions. And sorry if you are pissed, but what should I say if you ask if you need to compile the sources? It will break most likely for you and will cause more problems as it solves. Nothing more or less.

And yes, I can be rude from time to time. Especially if people don't provide logs, context or info. Or jumping topic x-times per issue. Or don't even try to understand the basics. I try to share, help, and give directions but for certain behavior my time is too precious.

from t480-opencore-hackintosh.

Hi there, I will see if I can reproduce your problem. I'll come back in a few hours

from t480-opencore-hackintosh.

I was able to reproduce your problem, but solved just by unpluging and pluging the headphone jack. Otherwise I get the same behaviour than you. Must be a problem with AppleALC.kext

from t480-opencore-hackintosh.

I tried unplug & re-plug but it was not working. Can you try plug the headphone in, sleep, unplug, wake, plug? Will it work? Someone said somewhere the state needs to be the same before and after sleep (plug before sleep, and still plug upon wake, or vice versa) would work fine.

from t480-opencore-hackintosh.

@tienhuynh5312 @zombillano

Because of macOS 11, I have migrated repository to the development releases of OpenCore and needed Acidanthera kexts. It is really bleeding edge now compared to other configs over the internet. Does this happen with AppleALC 1.5.1 ? If yes, try to downgrade to the lower version. Otherwise please try latest changes. You can also try to change layout-id from 86 ( Used for T480 since AppleALC 1.5.0 ) to more generic layout-id 11. I would like to publish new 4.0.0 release preview as soon as I compile latest itlwm, HeliPort and VoodooRMI and all reports would be really welcome.

from t480-opencore-hackintosh.

What is wrong with my my alc-layout-id?

from t480-opencore-hackintosh.

@tienhuynh5312

layout-id is defined in config.plist as a Number 86. If you translate 86 from decimal to text, output is V.

But that V there is definitively not correct, it should be in 4 byte HEX - 56000000 ( i think? )

Note that AppleALC can accept both Decimal/Number and Hexadecimal/Data, generally the best method is Hex as you avoid any unnecessary conversions. You can use a simple decimal to hexadecimal calculator to find yours. printf '%x\n' DECI_VAL:

Try replacing it in ProperTree with Data 56000000

from t480-opencore-hackintosh.

Try replacing it in ProperTree with Data 56000000

@EETagent
Yeah, I was expecting a HEX display but "V" is a little odd. I did what you recommended but it still displays "V".

from t480-opencore-hackintosh.

Audio_Fix.zip
Can someone try this out? Add CodecCommander and SSDT-AppleALC.aml. It fixes the problem. I have tried it on different pairs of headphone.
I made some changes to the CodecCommander.

1. Add layout for realtek alc257.
2. add custom commands (just like ALCPlugFix does) for the layout.

from t480-opencore-hackintosh.

Can someone try this out? Add CodecCommander and SSDT-AppleALC.aml. It fixes the problem. I have tried it on different pairs of headphone.

Is SSDT-AppleALC.aml really needed? With Sniki's changes definitively not. I do not think, that Rehabman version would be long-term compatible with the latest AppleALC versions. Also please test layout-id 11 and if that would not work too, then layout-id 18.

from t480-opencore-hackintosh.

Also please test layout-id 11 and if that would not work too, then layout-id 18.

Layout 11 is not good; the problem still exists. I am trying to stick with the official layout (86) for future reference and upgrade. This fixes my headphone problem, but I need to plug and replug if I switch to different audio output device after sleep. It is better than small volume and static noise that I previously had.

Is SSDT-AppleALC.aml really needed?

I saw the change log on it. However, I saw someone had the same issue, and RehabMan did recommended him to include the SSDT and see whether it would work or not. I like to include it in case of anything coming up because we are testing it right now.

from t480-opencore-hackintosh.

I am using the lastest Lilu and WEG kext, and I disabled the fix that I did. The issue is gone. It might be related to the sleep issue #20 .

from t480-opencore-hackintosh.

@tienhuynh5312 Please test latest few commits. I temporary removed HibernationFixup.kext to fix #20 and compiled latest Lilu, WEG, VirtualSMC, AppleALC, OpenCore and NoTouchID ( Brings Big Sur support, how come I didn't notice newer version of it? ). When I tested 3.5mm jack with headphones I did not hear any static noise.

from t480-opencore-hackintosh.

There's certainly a problem with our audio config. I'm on latest 4.0.0 release and sometimes I lost audio output spontaneously. I'm still trying to find how to reproduce this issue. It isn't critical but kind of anoying. It has an easy fix, I just need to open system preferences and select any INPUT device, which is kind of strange. As soon as I close system preferences I lost audio output.

This is happening while using internal speakers. The other day I tried to use some headphones while having this issue and I got that it was changing that output too, making everything sound kinda strange.

from t480-opencore-hackintosh.

Lol this sounds like what I stated in the OP. I did experience this here and there. It is ghosting around. The problem wont happen if you dont ever open the sound pref pane. Once you open the sound setting pane, it will started to happen.
The easiest way to fix is you have to wake up the laptop immediately right after you put it in the sleep mode.

from t480-opencore-hackintosh.

Lol this sounds like what I stated in the OP. I did experience this here and there. It is ghosting around. The problem wont happen if you dont ever open the sound pref pane. Once you open the sound setting pane, it will started to happen.
The easiest way to fix is you have to wake up the laptop immediately right after you put it in the sleep mode.

Kinda like that, but not the same issue because my problem happens with internal speakers, the headphone jack issue is another one that happened to me once a couple of days ago.

What I meant is that for some reason sometimes the audio decides to stop working with the internal speakers (and nothing else connected neither via Bluetooth or headphone jack) and won't recover until I open system preferences and do what you stated on the OP. A different problem, same solution

from t480-opencore-hackintosh.

Lol this sounds like what I stated in the OP. I did experience this here and there. It is ghosting around. The problem wont happen if you dont ever open the sound pref pane. Once you open the sound setting pane, it will started to happen.
The easiest way to fix is you have to wake up the laptop immediately right after you put it in the sleep mode.

That might be reason why I was unable to reproduce problem. I will try it again with audio settings opened

from t480-opencore-hackintosh.

Really weird, I use 3,5" jack rarely but I tested it intensively and did not encounter it. I use internal speakers pretty often though and problem is not there too. Do you use latest AppleALC and Lilu?

from t480-opencore-hackintosh.

Really weird, I use 3,5" jack rarely but I tested it and did not encounter it. I use internal speaker pretty often though and I did not encountered it there too. Do you use latest AppleALC and Lilu?

I use 4.0.0 release kexts. It happens to me every now and then. I think it happens after leaving the computer to lock screen and then login in back. Is it a normal behaviour that my T480 never enters on sleep mode if I leave it with the lid open for lets say a couple of hours?

from t480-opencore-hackintosh.

Nope, check your power settings

from t480-opencore-hackintosh.

Just wanted to check if this issue still exist in 5.0.1. I was still unable to reproduce it.

from t480-opencore-hackintosh.

Just wanted to check if this issue still exist in 5.0.1. I was still unable to reproduce it.

I will test with this release, but with releasee 4.0 still happens. Do you restart your thinkpad very often? I've noticed that it happens when I keep mine without restarting. Then if you get up your T480 from a long sleep you'll trigger this issue. I use youtube a lot and I have videos running at the background very often, so it is pretty clear to me when the audio stops working.

from t480-opencore-hackintosh.

@tienhuynh5312 @EETagent This issue happens on the X1C6 too: tylernguyen/x1c6-hackintosh#75

This gives me some hope, the more people affected, the more attention we can get from acidanthera's group.

from t480-opencore-hackintosh.

@zombillano It doesn't seem to be a bug in AppleALC but rather incomplete/bugged codec-configs. So there are separate issues for both machines as they are using different codecs. But I may have learned enough tonight to port the proposed fix from the X1C6 over to the T480. I'll try if it shows to be stable.

Notthebee has a X1C6 and he has the same issues as me. I'm looking forward for any fix on this issue.

from t480-opencore-hackintosh.

At the end of this issue you can find instructions to fix the problem: tylernguyen/x1c6-hackintosh#75. I would appreciate if someone else would get their hands dirty as I probably wont come back to that topic in the near future.

from t480-opencore-hackintosh.

Reposting required steps by fewtarius here.

I will be trying to fix our issue this next weekend (I hope), since you were unable to reproduce the problem. I'll let you know how it goes.

from t480-opencore-hackintosh.

Sorry for keep you waiting. I tried it and it still keeps stop working after sleep. I only replaced the AppleALC kext, do I need to modify anything else?

from t480-opencore-hackintosh.

@zombillano Remove any ALCPlugFix and similar tools, rebuild kextcache + do a cold reboot (wait 10-20sec after shutdown)

from t480-opencore-hackintosh.

@zombillano Remove any ALCPlugFix and similar tools, rebuild kextcache + do a cold reboot (wait 10-20sec after shutdown)

We don't have any ALCPlugFix on this repo as far as I know. I've rebuilt kextcache and done a cold reboot, but the problem is still there. Don't worry if you don't have time to give it a look, I'll do it as soon as I get a little bit of time. Right now I'm pretty busy with school.

from t480-opencore-hackintosh.

@zombillano can you describe what "stops after wake" means concrete and post logs from when the bug happens (log show --last 5m > audio-defect-after-wake.log)?

PS: you are using layout-id 86 aka "Realtek ALC257 by bb" (check with Hackintool), right?

from t480-opencore-hackintosh.

@zombillano can you describe what "stops after wake" means concrete?

Ok, I'll try to explain myself as good as possible:

• Audio input and output works just fine after a fresh boot, I can use speakers and integrated mic without any issues.
• After waking up from sleep it works fine for about a couple of minutes, and then it stops making sound through the speakers. Whenever I try to get the volume up or down I only get a strange sound. Also the mic stops working.
• One solution is to keep System Preferences -> Input -> Line-in selected and the app open. It solves only output, cause even if I select "Internal Microphone" I'm only able to use it for like 1 minute before it stops working again (the mic).
• Definitive solution is to restart the system.

Quick note: I'm getting static noise at the Jack output. It also solves when I select "Line In" at the Input submenu.

I decided to record a video to show this.Sorry for the bad quality, I recorded it using my smartphone which in fact doesn't have neither a good camera or mic. Either way, I think it should be enough to clarify the issue. I must clarify that the logs posted below have been taken just after I stopped recording.

Video: https://we.tl/t-CUp8qPXusq

post logs from when the bug happens?

Here you have them:
audio-defect-after-wake.log

PS: you are using layout-id 86 aka "Realtek ALC257 by bb" (check with Hackintool), right?

Of course, look over here:

from t480-opencore-hackintosh.

@zombillano are you on the latest version of this repo? did you change anything?

from t480-opencore-hackintosh.

@zombillano are you on the latest version of this repo? did you change anything?

I'm on the latest release, but not on the latest commit. I didn't change anything but the serial number. Did you find anything useful on the logs?

from t480-opencore-hackintosh.

@zombillano not on the first look. I'll provide you with my EFI-folder as soon as I've finished the porting of my BATX-patch to dual-battery-support. I haven't had any glitches since my fix for ALC.

from t480-opencore-hackintosh.

@zombillano here is my latest (beta) T480 OC-folder. May contain bugs but should be good enough to verify if the problem is config-relatd: T480-Latest-OC-063.zip

I'll give it a try and let you know if I find any improvement or any bug. Thanks for your help!

from t480-opencore-hackintosh.

@benbender I'm quite confused, should I compile the .dsl files in order to get the .aml ones? Because as I understand I'll need them in my ACPI folder in order to be able to use your config.plist file, am I right?

from t480-opencore-hackintosh.

@zombillano here is my latest (beta) T480 OC-folder. May contain bugs but should be good enough to verify if the problem is config-relatd: T480-Latest-OC-063.zip

Really interesting.

Just one question, why you load com.apple.driver.AppleSMBusController? As far as I know it has a collision with VoodooSMBus

from t480-opencore-hackintosh.

@EETagent SMBus is involved in much more (SMC, Battery, PCI...) and it is only specific parts of the OSX-driverstack for SMBus which interfere with VoodooSMBUS. These parts are "blocked" by VoodooSMBUS itself anyway.

I'm not strictly sure though if those SMBus-patches are really needed, but they don't hurt and as I'm trying to have as few (invisible) failure-points as possible, I left them in.

from t480-opencore-hackintosh.

Also, why you use OSDW? Why not just directly If (_OSI ("Darwin"))? Thanks

from t480-opencore-hackintosh.

@zombillano Hmm, tbh, if you have to ask such a question, you maybe shouldn't use my zip. Its straight from my hdd and you'll have to adapt and there will be errors quite surely... Don't want to be rude or so, but it may be better to leave it alone. But to answer your question: Yes, sure, you have to compile them - and there is an update.sh inside for convenience. But it's generally not complete for filesize reasons and, as I said, needs adaption.

I won't use it then. I haven't got time to study ACPI source language and I'm still unfamiliar with the ACPI of this machine. You are rude man, I'm quite unsure if it is because maybe english isn't your native language (isn't mine either) or because that's how you are. I mean, yeah, you are for sure the most knowledgeable over here, but I have the feeling that you go around making everyone feeling as a fool. I know it isn't personal, I saw the same kind of answers to the questions of some other people over here and gitter.

I want to learn for sure, that's why I asked you before (over gitter) if you had any good source to learn about this topics. I don't want to start a discussion, I just wanted to let you know my point of view. Of course I'm pretty glad with all the help you've been giving over here and other related projects as well. I know you were trying to help so please don't misunderstand my words.

Right now I'm a little pissed off with your answer, and I think I'll get away for some time, since I don't think I can contribute anything to this repo atm 'cause I'm still too noob. If I find the solution to the problem I'll post it. Until then, I wish the best luck to all of you.

from t480-opencore-hackintosh.

Hi y'all, I had this issue as well, but it seems to be mostly resolved as of 3e9bc18. The headphone jack and the built-in microphone seem to be working fine, even after sleep, and the audio doesn't do that weird distortion that it did before. However, very rarely (only happened twice in two days) the headphones just stop working with a loud "pop". Simply the act of opening the Sound preferences window gets them going again.

I'd be happy to provide logs and help test this issue, I just don't know what sort of logs I need to provide.

from t480-opencore-hackintosh.