Need Help patching AppleHDA for ALC668

[the-darkvoid]

An updated CodecCommander is now available with the functionality to execute custom commands on the following events:

• On Initialization
• On Wake
• On Sleep

Additionally it includes a command line tool hda-verb, which allows executing custom HDA commands from the terminal when CodecCommander is loaded.

It can be downloaded from here:
https://github.com/robvanoostenrijk/EAPD-Codec-Commander/releases

 

[vbo]

vbo,

I did some thinking about the issue, and as per the *nix bug reports you posted it seems we would need to modify the codec state to ensure the white noise disappears.

A sample of the codec verbs (commands) required to do that can be found here:
http://xps13-9333.appspot.com/root/usr/local/bin/white_noise_fix.py

Now obviously we cannot send codec verbs to a sound card in OS X, however CodecCommander can.

I have created a fork of CodecCommander and added the functionality to send custom commands on either:

• Initialization
• Wake up
• Sleep

With the right set of custom commands the headphone issue should be resolvable for ALC668 (and potentially also other codecs with this issue).

If you are interested to test this out I can provide the updated CodecCommander (including source code).

Sorry I missed this post, I must have overlooked the email notification.
I'm happy to help testing anything you have. I was just looking at the changes in your CC fork on github. Did you get any luck solving the static by muting the amp though? I remember trying to do this a while ago by adding the mute commands to the ConfigData in the HDA plist without luck. Since we're passing EAPD init verbs in there, I figured the mute should be sent along and executed too, but that didn't solve the static issue.
After reading some more in the kernel fixes, I was under the impression that the final fix they implemented had to do with modifying the speaker pin config when the headphones are plugged in.

Edit: Just found my old notes on this: https://github.com/vbourachot/Dell-XPS13-9333-DSDT-Patch/blob/master/misc/configdata_worklog.txt#L23

 

[the-darkvoid]

True, but I believe config data is not the right place to add custom verbs.

I read that amps tend to be reset anytime the codec comes out of sleep or initialises.
This is why CodecCommander is required, because otherwise after sleep EAPD is still lost even though its in the pin configuration.

Also we obviously cannot be sure what commands AppleHDA sends in the meanwhile affecting the state of any amps or pin widgets.

Now there is the possibility for us to send custom commands at any moment, long after initialisation is already done, hopefully allowing us to en/disable nodes on the fly and see their effect.

Should we come across a working configuration through commands we can then figure out how to send those at the right moment...

 

[vbo]

True, but I believe config data is not the right place to add custom verbs.

I read that amps tend to be reset anytime the codec comes out of sleep or initialises.
This is why CodecCommander is required, because otherwise after sleep EAPD is still lost even though its in the pin configuration.

Also we obviously cannot be sure what commands AppleHDA sends in the meanwhile affecting the state of any amps or pin widgets.

Now there is the possibility for us to send custom commands at any moment, long after initialisation is already done, hopefully allowing us to en/disable nodes on the fly and see their effect.

Should we come across a working configuration through commands we can then figure out how to send those at the right moment...

^ All very good points.
I compiled your kext earlier and I've been playing with your hda-verb port. No luck with set_amp_gain_mute (but i'm sure you already knew that). I'll keep poking around see if I can come up with something.

 

[the-darkvoid]

Yes, SET_AMP_GAIN did not do what I expected.

Great that you are testing out other combinations (and that hda-verb is working for you).

Maybe its possible to tap some of the Alsa developers for some feedback what over pin widget configuration settings can solve this problem.

 

[the-darkvoid]

Good news, I was contacted on another forum with a solution for the ALC668 headphone issue.
Preliminary testing on my Dell XPS 9530 show that it is working!

Built-in speakers, microphone and headphone are working (including auto-detect switch over).

Since its a patched AppleHDA.kext I am trying to put into a clean AppleHDA_ALC668.kext stub.

I will update here once that is working properly.

 

[stich86]

Good news, I was contacted on another forum with a solution for the ALC668 headphone issue.
Preliminary testing on my Dell XPS 9530 show that it is working!

Built-in speakers, microphone and headphone are working (including auto-detect switch over).

Since its a patched AppleHDA.kext I am trying to put into a clean AppleHDA_ALC668.kext stub.

I will update here once that is working properly.

wow!!! let us know
it the only thing that makes our laptop perfect hack book

 

[the-darkvoid]

Ok, so it seems to work as expected.

First of all the original credits go to Joe82 (on another forum) and forum member Jake Lo over there who brought its existence to my attention.

The original AppleHDA.kext patched by Joe82 for Yosemite 10.10.1 can be found here:
https://db.tt/w0lLdjy7

So far there is one small drawback, you should not boot with the headphones plugged in.

Plugging, unplugging & replugging headphones while booted is working fine though.

What I have not tested yet is:

• Line-In input functionality
• HDMI audio

Current problems:

• Headphone audio does not seem to return after sleep, even with CodecCommand EAPD.
  I believe additional verb commands on wake-up can be sent to rectify this.

This AppleHDA uses layout 3, so ensure the following is present in your DSDT:

Method (_DSM, 4, NotSerialized)
{
    If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
    Return (Package()
    {
        "layout-id", Buffer() { 0x03, 0x00, 0x00, 0x00 },
        "hda-gfx", Buffer() { "onboard-1" },
        "MaximumBootBeepVolume", 0x40,
        "PinConfigurations", Buffer() { },
    })
}

Ensure you have the following kext patches in Clover:

<dict>
    <key>Comment</key>
    <string>Enable Realtek ALC668 #1</string>
    <key>Find</key>
    <data>
    hAjsEA==
    </data>
    <key>Name</key>
    <string>AppleHDA</string>
    <key>Replace</key>
    <data>
    AAAAAA==
    </data>
</dict>
<dict>
    <key>Comment</key>
    <string>Enable Realtek ALC668 #2</string>
    <key>Find</key>
    <data>
    hQjsEA==
    </data>
    <key>Name</key>
    <string>AppleHDA</string>
    <key>Replace</key>
    <data>
    AAAAAA==
    </data>
</dict>
<dict>
    <key>Comment</key>
    <string>Enable Realtek ALC668 #3</string>
    <key>Find</key>
    <data>
    hBnUEQ==
    </data>
    <key>Name</key>
    <string>AppleHDA</string>
    <key>Replace</key>
    <data>
    aAbsEA==
    </data>
</dict>

Personally I like to use an AppleHDA injector kext so that it is (hopefully) future proof with newer OS X versions/updates.

An pre-generated AppleHDA_ALC668.kext injector can be found here:
https://db.tt/nOrHEtHd

The script to generate it is part of my XPS 9530 installation script on Github:
https://github.com/robvanoostenrijk/XPS9530-OSX/

Interesting would be to see exactly what the new pin configuration does and if the issue of booting with headphones plugged in can be resolved.

I would appreciate your insights here vbo!

The pin configuration is:

01271C01 01271D01 01271EA0 01271F90 01471C02 01471D01 01471E17 01471F90 01470C02
01571C03 01571D40 01571E2B 01571F01 01570C02 01671CF0 01671D00 01671E00 01671F40
01871CF0 01871D00 01871E00 01871F40 01971CF0 01971D00 01971E00 01971F40 01A71CF0
01A71D00 01A71E00 01A71F40 01B71C04 01B71D10 01B71E8B 01B71F01 01D71CF0 01D71D00
01D71E00 01D71F40 01E71CF0 01E71D00 01E71E00 01E71F40 01F71CF0 01F71D00 01F71E00
01F71F40 02050011 02040001 02050015 02040D60 020500B7 0204802B 020500C3 02040000
00172000 00172172 0017226B 00172310

 

[the-darkvoid]

Edit... Incorrect assumption

 

[vbo]

Ok, so it seems to work as expected.

First of all the original credits go to Joe82 (on another forum) and forum member Jake Lo over there who brought its existence to my attention.

The original AppleHDA.kext patched by Joe82 for Yosemite 10.10.1 can be found here:
https://db.tt/w0lLdjy7

So far there is one small drawback, you should not boot with the headphones plugged in.

Plugging, unplugging & replugging headphones while booted is working fine though.

What I have not tested yet is:

• Line-In input functionality
• HDMI audio

Current problems:

• Headphone audio does not seem to return after sleep, even with CodecCommand EAPD.
  I believe additional verb commands on wake-up can be sent to rectify this.

First of all, this is great. Thanks for posting this here, and to the person who originally did the patching.
I can confirm the same issue when booting with headphones plugged in -> no sound. However I have a slightly different behavior coming back from sleep: the HP port is working, but with the exact same static as with the old patched HDA.
Interestingly enough, CodecCommander doesn't seem to be required coming back from sleep for neither speakers nor HP out. I removed it because I wanted to see the behavior without it, and to my surprise both speakers and HP out worked?! Maybe it's only because I've only run short sleep durations? I'm running without it for now so I'll test some more and report.

The pin configuration is:

01271C01 01271D01 01271EA0 01271F90 01471C02 01471D01 01471E17 01471F90 01470C02
01571C03 01571D40 01571E2B 01571F01 01570C02 01671CF0 01671D00 01671E00 01671F40
01871CF0 01871D00 01871E00 01871F40 01971CF0 01971D00 01971E00 01971F40 01A71CF0
01A71D00 01A71E00 01A71F40 01B71C04 01B71D10 01B71E8B 01B71F01 01D71CF0 01D71D00
01D71E00 01D71F40 01E71CF0 01E71D00 01E71E00 01E71F40 01F71CF0 01F71D00 01F71E00
01F71F40 02050011 02040001 02050015 02040D60 020500B7 0204802B 020500C3 02040000
00172000 00172172 0017226B 00172310

Dusted off the old intel hda specs All in all, it's a similar pin config to the one used before with the notable difference of line in being defined (wasn't before), and all the input/outputs being grouped together. Here's the breakdown:

01271C01 01271D01 01271EA0 01271F90 		- Internal Mic
01471C02 01471D01 01471E17 01471F90 01470C02	- Speakers (70C02 sets EAPD enabled)
01571C03 01571D40 01571E2B 01571F01 01570C02 	- Headphones (70c02 sets EAPD enabled)
01671CF0 01671D00 01671E00 01671F40
01871CF0 01871D00 01871E00 01871F40 
01971CF0 01971D00 01971E00 01971F40 
01A71CF0 01A71D00 01A71E00 01A71F40 
01B71C04 01B71D10 01B71E8B 01B71F01 		- Line in
01D71CF0 01D71D00 01D71E00 01D71F40 
01E71CF0 01E71D00 01E71E00 01E71F40 
01F71CF0 01F71D00 01F71E00 01F71F40 
02050011 02040001 02050015 02040D60		- Starting here, no idea what the remaining is
020500B7 0204802B 020500C3 02040000 
00172000 00172172 0017226B 00172310

Notes:
Mic (x12) + Speakers (x14) + Headphones (x15) + Line in (x1b) all defined as part of the same group (71c*0*) and sequenced (71c0*1*/2/3/4)

Internal mic and speakers defined as no jack detect (71d0*1*), HP and line in have jack detect.

71e looks clean (default device and connection type). Note that HP connection and line in are set to 'Combination' connection type

71f:
Mic/Speakers: Fixed function connectivity / internal location
HP: Jack connectivity / Rear location (11b would be left)
Line in: Jack connectivity / rear location (same as HP node)

x16 (line out), x18, x19, x1a, x1d, x1e, x1f are disabled as best as I can tell (071F40 means 01b connectivity == No physical connection for Port)

Interestingly enough, there is no difference in behavior if I remove the last 3 lines above, i.e. with ConfigData as follows:

			<key>ConfigData</key>
			<data>
			ASccAQEnHQEBJx6gAScfkAFHHAIBRx0BAUceFwFHH5ABRwwCAVcc
			AwFXHUABVx4rAVcfAQFXDAIBZxzwAWcdAAFnHgABZx9AAYcc8AGH
			HQABhx4AAYcfQAGXHPABlx0AAZceAAGXH0ABpxzwAacdAAGnHgAB
			px9AAbccBAG3HRABtx6LAbcfAQHXHPAB1x0AAdceAAHXH0AB5xzw
			AecdAAHnHgAB5x9AAfcc8AH3HQAB9x4AAfcfQA==
			</data>

The platforms file is slightly different too. It's using different paths compared to the old one, and obviously defines line in which wasn't defined before. From my notes (pathmap starts a line 3421):

• Mic in: 18 7 (0x12 0x07) (identical)
• Line in: 9 34 27 (0x09 0x22 0x1b) (new)
• Speakers: 20 12 2 (0x14 0x0c 0x02) (was 20 13 3)
• HP 21 14 4 (0x15 0x0e 0x04) (was 21 12 2)

Codec graph for reference: https://github.com/vbourachot/Dell-...er/linux_native/linux_sound/card1_codec#0.svg
I haven't seen any glaring differences in the layout file, but I'll look into it further.

Edit: attaching pin config breakdown as text file as the code box is wrapping lines.