Contribute
Register

Need Help patching AppleHDA for ALC668

Status
Not open for further replies.
Let me try and remove CodecCommander here also and see what that gives.

Update:

Sleeping without CodecCommander kills the speaker and headphone noise comes back.


Sleeping with default CodecCommander restores speakers, but headphones are non-functional (total silence)

Sleeping with modified CodecCommander which does not do a full codec reset, restores speakers but headphones are with whitenoise.

I am seeing if we can not reset the codec and have CodecCommander re-configure the pins on wake-up.
 
So it gets more interesting.

I modified CodecCommander.kext so that it does not issue a codec reset, speakers return from sleep correctly.

Now the headphones will give white noise. However if you go into sound preferences and select "Line-Out", the white noise disappears and all works properly... for about 30 seconds.

Clearly we need to look into how the line-out interferes with the headphone connector that seems to be the key.

Update: If you keep the sound preferences panel open, the sound actually keeps working fine.
So we need to figure out what the input sound preferences is doing, so CodecCommander can do it automatically.

Although as a work around its possible to keep it open in the background.
 
the-darkvoid said:
So it gets more interesting.

I modified CodecCommander.kext so that it does not issue a codec reset, speakers return from sleep correctly.

Now the headphones will give white noise. However if you go into sound preferences and select "Line-Out", the white noise disappears and all works properly... for about 30 seconds.

Clearly we need to look into how the line-out interferes with the headphone connector that seems to be the key.

Update: If you keep the sound preferences panel open, the sound actually keeps working fine.
So we need to figure out what the input sound preferences is doing, so CodecCommander can do it automatically.

Although as a work around its possible to keep it open in the background.
Click to expand...

Interesting/puzzling indeed.. I can reproduce everything you say above, except for me it's not line out but line in..

So my 'symptoms' are:
  • Before sleep, everything works fine
  • After sleep, switching inputs in sound prefs from mic to line in removes the white noise
  • If I close the sound prefs, the white noise comes back after ~30s
  • If I keep the sound prefs open, the white noise does not come back

Anecdotally, I've been running without CodecCommander for the past few days - both speakers and HP come back after sleep.

Do you actually have a line out jack on your laptop? I do not, but after reading your post, I modified the ConfigData and platforms to enable the line out at 0x16. Based on my codec graph, it should be 0x16 -> 0x0d -> 0x03. However, line out doesn't show up as a possible output in my sound prefs; only Speakers or Headphones show up, depending on whether HP are plugged in or not. I'm not sure if it's because I made a mistake in my implementation or because there is no actual line out jack on my laptop and OSX doesn't show the bogus entry.
 
Oops, totally my bad.

I meant to say "line in" but something in my brain short circuited.
It all works when selecting "line in" on the "inputs" of sound preferences.

I will see about using the layout 1 you just pushed.

However my sound is definitely not coming back after sleep, but I will double-check that.

The method I use for testing sleep is:
- Click sleep in the Apple menu
- Wait until the laptop power light goes off (20 to 30 seconds)
- Press power button

I am using the stripped pin configuration as given by you earlier, with the unknown verbs removed.
What I can think of now, is that the sound preferences panel does something with either the "line in" or "microphone" amp.

We can try and use CodecCommander to send some verbs to the amp widget in the "line in" pathmap to see if we can replicate the effect.
 
the-darkvoid said:
Oops, totally my bad.

I meant to say "line in" but something in my brain short circuited.
It all works when selecting "line in" on the "inputs" of sound preferences.

I will see about using the layout 1 you just pushed.

However my sound is definitely not coming back after sleep, but I will double-check that.

The method I use for testing sleep is:
- Click sleep in the Apple menu
- Wait until the laptop power light goes off (20 to 30 seconds)
- Press power button

I am using the stripped pin configuration as given by you earlier, with the unknown verbs removed.
What I can think of now, is that the sound preferences panel does something with either the "line in" or "microphone" amp.

We can try and use CodecCommander to send some verbs to the amp widget in the "line in" pathmap to see if we can replicate the effect.
Click to expand...

Oh ok, that makes sense. I'd say don't bother with the stuff I pushed wrt line out - I don't think it works or does anything since we see the same thing with and without it.

That's a good idea with codecommander. I also want to try disabling the mic path completely, just to see what happens.. I'll keep you posted.

As far as sleep.. for some reason the speakers come back fine after sleep for me.. Definitely confirmed sleep, either via apple menu or lid close. I don't understand why to be honest :)

Update: Exact same behavior with mic completely removed from configdata/layout/platforms. Whatever voodoo having the sound preferences opened is doing must be the key to solving the white noise after sleep.
I also nuked the commit with the line out stuffs on github.
 
Having the line out defined clearly solves the issue with white noise on the combo jack.
Now we just need to figure out how to replicate the start boot-up situation.

I was thinking of using CodecCommander custom commands to read the pin widget / amp settings of the amps on the path maps when it works and when it does not work.

That would potentially allow us to map out the differences and replicate them if necessary.

Also, I am thinking your sleep is maybe not deep enough due to DSDT/SSDT?
When I get home I will check it again as mentioned, but I am pretty sure EAPD amps are switched off when the codec is put to sleep and speaker/headphone give no output.
 
Ok so I triple checked. CodecCommander is required on the Dell XPS 9530 to restore sound after sleep.

I even reverted to the layout 1 published on vbo's repository to confirm.
 
Ok, so it took some head-scratching...
But I figured out what is happening regarding the white noise on the headphone connector.

The problem lies in widget 0x1b:

Code: 
Node 0x1b [Pin Complex] wcaps 0x40048b: Stereo Amp-In
 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 0x411111f0: [N/A] Speaker at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=00, enabled=0
  Power states:  D0 D1 D2 D3 EPSS
  Power: setting=D0, actual=D0

When restoring from sleep, its pin widget controls are no longer 0x20.
Clicking line-out in sound preferences restores the 0x20, but closing the preferences removes it again (after 30+ seconds).

As per the HDA specifications 0x20 means "In Enable", which allows the widget output path to be shut off.
So it allows AppleHDA to actually stop the static.

Using a CodecCommander kext with CustomCommand configured, after wake-up the pin widget control is restored and headphones work without noise.

Note that opening the sound preferences and selecting line-in, and subsequently closing the preferences will still cause noise to appear after 30 seconds.
Waking up again from sleep resolves that.
However I see that as a minor problem only, since its unlikely someone will regularly update the line-in input settings.

It might be interesting to put the same verb in the pin configuration data, and see how that behaves.
Update: Same verb through pin configuration does not work.

The AppleHDA_ALC668 and CodecCommander kexts I am using can be found here:
https://dl.dropboxusercontent.com/u/13972199/audio/AppleHDA_ALC668_CodecCommander.zip

Install them to /System/Library/Extensions and rebuild the kext cache.

Give this a test for XPS 9333 vbo :shifty:
 
This is great, thanks for the investigation! I'll try it out and report back.

Edit: Nevermind - just saw the commits in your MMIO branch.
Edit 2: Removed a bunch of nonsense from this post after I looked at my codec dump more closely :)

Edit 3: Your custom CodecCommander attached above fixed the issue for me too. HP out is now perfect on wake! Good stuff!

FYI - not sure if this is on purpose (doesn't seem like it based on the Info.plist where On Sleep is set to false) but the custom verb is sent both on sleep and on wake:
Code: 
[B]Jan 27 22:42:56 mba kernel[0]: CodecCommander: --> asleep[/B]
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: node 0x14, verb 0x00070c, payload 0x00.
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01470c00
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: node 0x15, verb 0x00070c, payload 0x00.
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01570c00
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000
[COLOR="#FF0000"]Jan 27 22:42:57 mba kernel[0]: CodecCommander: --> custom command 0x01b70720[/COLOR]
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01b70720
Jan 27 22:42:57 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000

[B]Jan 27 22:43:40 mba kernel[0]: CodecCommander: --> awake[/B]
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: node 0x14, verb 0x00070c, payload 0x02.
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01470c02
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: node 0x15, verb 0x00070c, payload 0x02.
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01570c02
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000
[COLOR="#FF0000"]Jan 27 22:43:41 mba kernel[0]: CodecCommander: --> custom command 0x01b70720[/COLOR]
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (w) --> 0x01b70720
Jan 27 22:43:41 mba kernel[0]: CodecCommander::SendCommand: (r) <-- 0x00000000

Thanks so much for fixing this (along with thanks for FakePCIID and BrcmPatchRam)!
 
Yes, I have noticed the configuration for custom commands is not properly interpreted at the moment.I will look into this. However in this case it does not affect the outcome.
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top