AppleALC — dynamic AppleHDA patching

[KNNSpeed]

Hi,

 

Has anyone figured out what the 0x0100 part of MuteGPIO does?

I mean specifically this part:

 

Vref      ????   Node ID

0x50    0100      0D

 

Details:

I have an ALC298 that I have managed to get the combo jack working as line-in (not TRRS/headset; for some reason I can set the right pathmap but get no response from mic--just noise if I raise the sensitivity all the way up), and along the way I found that to remove distortion from the headphone jack the TRRS/headset mic pin needs to be set as "input" whenever a headphone is plugged in. I can do this manually, but in order to make it automatic I think I need to know what the 0100 does. I'm thinking that, if the 0100 is indeed a bitmask and one of the bits is "input enable," then I should be able to make this jack a real stereo line-in/line-out combo jack with manual switching via SysPrefs. EDIT: I think I'm actually wrong about MuteGPIO's being able to control the "input" bit; it only seems to be able to do the VREF bits in my experiments. Maybe DetectDelegates can be repurposed...

 

Any ideas?

 

EDIT: I should note that I got this to work entirely by creating a new platform and layout for AppleALC for my machine (XPS 9560). Managed to fix all the sound assertions without any patches, too! I'll gladly release it once it's done.

[En0r1m]

@KNNSpeed,

Maybe this helps: http://www.insanelymac.com/forum/topic/127819-how-to-patch-applehda-knowledge-base/page-15?do=findComment&comment=1115530

 

[KNNSpeed]

Thanks, though it didn't directly answer my question, some of those pages did help a bit.

 

Now I just need to figure out why I get white noise whenever I enable the external mic ("headset mic," as Realtek calls it)...

I know it's not the headset itself, since I can plug in a dummy cable (i.e. a TRRS plug with RCA connectors on the other end) and it still just gives me noise.

[insanelyDeepak]

Hi,

 

Has anyone figured out what the 0x0100 part of MuteGPIO does?

I mean specifically this part:

 

Vref      ????   Node ID

0x50    0100      0D

 

Details:

I have an ALC298 that I have managed to get the combo jack working as line-in (not TRRS/headset; for some reason I can set the right pathmap but get no response from mic--just noise if I raise the sensitivity all the way up), and along the way I found that to remove distortion from the headphone jack the TRRS/headset mic pin needs to be set as "input" whenever a headphone is plugged in. I can do this manually, but in order to make it automatic I think I need to know what the 0100 does. I'm thinking that, if the 0100 is indeed a bitmask and one of the bits is "input enable," then I should be able to make this jack a real stereo line-in/line-out combo jack with manual switching via SysPrefs. EDIT: I think I'm actually wrong about MuteGPIO's being able to control the "input" bit; it only seems to be able to do the VREF bits in my experiments. Maybe DetectDelegates can be repurposed...

 

Any ideas?

 

EDIT: I should note that I got this to work entirely by creating a new platform and layout for AppleALC for my machine (XPS 9560). Managed to fix all the sound assertions without any patches, too! I'll gladly release it once it's done.

hi

did you try layout 13  with codecCommander SSDT298 ?

[KNNSpeed]

I did, and it does work for headphones only, but not for line-in. I'm trying to get ExtMic and Line-In working, in addition to headphones. I can manually remap the paths with hda-verbs to get line-in to work, and I've discovered the root cause of what causes distortion on the headphone output (it's the "headset mic" that needs to be set as an input with 80% reference voltage triggering, which is what VREF 80 actually means and what MuteGPIO 0x50 0100 [NodeID] does, otherwise the signal voltage interferes with the output causing distortion).

 

However, I am finding that for some reason I have white noise when I manually set the input paths to "headset mic." Manually configuring the paths to line-in works fine, though unfortunately having anything plugged into the audio jack disables the speakers and I can't get them to power back on when a line-in device is plugged in (looks like headphone jack override)...

 

Would be awesome if the white noise problem could be solved, though. Then the jack would basically be perfect.

 

EDIT: Here's an image of the overall pathmap. Among the Pin Complexes, Node 0x1A is Line-In, 0x21 is Headphone, 0x17 is Speakers, 0x12 is Internal Mic, and 0x18 is External Mic/headset mic. Mixer 0x0b seems like it might be important, but I can get line-in to work without it by just modifying the selector (0x22), so maybe it's not necessary. (Capture.PNG attached)

 

EDIT 2: Here's an image of how I have it currently configured in the OS X pathmap (Note: some of the orange arrows are extra). (Capture2.PNG attached)

[En0r1m]

Thanks, though it didn't directly answer my question, some of those pages did help a bit.

 

It is part of learning read a few pages and 

Documentation of developers of the old school hackintosh

Would be awesome if the white noise problem could be solved, though. Then the jack would basically be perfect.

 

Have you ever looked closely at the properties in your LayoutID? well, I may be talking nonsense because I'm no expert, but here are the highly-skilled people that can help you.

greetings!

[KNNSpeed]

Yeah, I've been doing pretty much nothing for the past 2 weeks (probably longer now, honestly I'm losing track of time) except reading the Realtek Codec specifications, the Intel HDA specifications, and as much stuff as I can find on the Internet about it. Unfortunately, there seem to be some things that either nobody knows or those who know never wrote anything down. I've been able to determine that MuteGPIO, for example, applies the last nibble of "Pin Controls," and you can use IOMux in the layout XML to create a switch that lets you change the audio jack function from output to input (there's a corresponding platform XML value called "RetaskDetectDelegate" that tells the OS "enable this path when the direction of this other pin complex has changed"), and that "DetectDelegate," which is normally reserved for SPDIF audio detection, looks like, in theory, it does the same thing except automatically and without any dependence on IOMux.

 

I've also read through *all* of the comments in the AppleHDA platforms.xml (Apple left an entire "how to make a codec" example in there!) and the only property not really explained is MuteGPIO. The table you linked to is incomplete, by the way: 0x64 at the front corresponds to Vref 100%, 0x01 at the front corresponds to Vref GND, and 0x00 at the front is HiZ.

 

I'm not sure if MuteGPIO of 0 means something special, because there's no node in it. I've also seen some Headphone entries take a value of 0x01000001, though node 0x01 is the AFG node... :/

 

MuteGPIO 262144 is only used on ExtMic, and on my real machines the path map for the ExtMic leads to a node that isn't actually there on any of my MBPs (0x16).

 

Another thing I haven't found written anywhere is that you can intentionally put MuteGPIO on a different device than what its nodeID references and in that way you can cause a change in another device's property (something I have to do to get this jack to better behave the way I want it to).

 

BTW, I also know why newer Audio IDs have I2C & TDM entries in their layouts:

http://www.analog.com/media/en/technical-documentation/data-sheets/SSM3515.pdf

 

If only AppleHDA were open-source... -\_(ツ)_/-

 

EDIT: Meant Intel HDA not AppleHDA, lol

 

EDIT 2: Meant "Pin controls," not "Pin Caps."

[insanelyDeepak]

I did, and it does work for headphones only, but not for line-in. I'm trying to get ExtMic and Line-In working, in addition to headphones.

 

I really worked hard to make comboJack working for ALC298 

use AppleALC(layout 13) + SSDT298 (codec commander) + ALCFix 

 

use ALCFix from below link 

https://github.com/insanelydeepak/cloverHDA-for-Mac-OS-Sierra-10.12/blob/master/Laptop/ALC298.zip 

 

EDIT: Here's an image of the overall pathmap. Among the Pin Complexes, Node 0x1A is Line-In, 0x21 is Headphone, 0x17 is Speakers, 0x12 is Internal Mic, and 0x18 is External Mic/headset mic. Mixer 0x0b seems like it might be important, but I can get line-in to work without it by just modifying the selector (0x22), so maybe it's not necessary. (Capture.PNG attached)

 

I still remember in linux behaviour where it used 1a as HeadsetMic and 19 as Headphone Mic. (combojack) 

but we can't use as like linux after doing long work I we (me and Goodwin_C ) found node 18 perfect for External Mic , we got it working but still too many distortion in headphone wich can only remove through CC an alcfix 

 

PS: I didn't look into your codecdump 

[KNNSpeed]

This is a custom version of the ALC298; Dell calls it "ALC3266." I was using "AlcFix" and layout 13 for a while, and it worked for headphones only. Didn't need the SSDT (it just does a double reset and sets unsolicited response, and I wasn't having the problems that those addressed because the OS seemed to be doing it correctly anyway).

 

I'm not sure what you mean by "we can't use as like in Linux," because in Linux I made several dumps and saw that there were differences that when I matched... Worked (for line-in). Except for this white noise.

 

Also what do you mean by "working" combojack? Do you mean it worked as stereo Line-IN, too, or just Headphone + headset mic?

 

Here are all the dumps I made. "Pure" means "nothing plugged in."

EDIT: I should also mention that I noticed that if I had 0x1A properly enabled AND 0x21 enabled, the laptop was recording what was going out the headphone jack (as we would expect). I also noticed something funny: It started using the headphone part of my iPhone headset as a microphone--NOT the microphone part of the headset. I mean, a microphone is basically a backwards speaker, but I didn't realize the iPhone headphones were that sensitive, haha.

codec0.zip

[En0r1m]

@KNNSpeed,

Try to contact Mirone,
Although "Retired" he could help you
Somehow.

[insanelyDeepak]

@KNNSpeed,

Try to contact Mirone,

Although "Retired" he could help you

Somehow.

 

Hello 

any of above post says I'm not trying to help him. ? 

 

what I want is @KNNSpeed should enjoy fruit instead of plant tree and try use my work bcoz it took too much time to fix ALC298 wich is not one day(week) work 

it took approx one year (exactly don't remember ) me and Goodwin_c (who has this codec ) work hard and made progress its working for him and many of other user who are using this (check my git repo )

 

This is a custom version of the ALC298; Dell calls it "ALC3266." I was using "AlcFix" and layout 13 for a while, and it worked for headphones only. Didn't need the SSDT (it just does a double reset and sets unsolicited response, and I wasn't having the problems that those addressed because the OS seemed to be doing it correctly anyway).

AppleALC Layout 13 => is specifically for Realtek ALC3266 (which is alc298) for Dell laptops 

 

I'm not sure what you mean by "we can't use as like in Linux," because in Linux I made several dumps and saw that there were differences that when I matched... Worked (for line-in). Except for this white noise.

 

exactly don't remember but there was a reason behind why we can't use it as Linux do 

 

 

EDIT: I should also mention that I noticed that if I had 0x1A properly enabled AND 0x21 enabled, the laptop was recording what was going out the headphone jack (as we would expect). I also noticed something funny: It started using the headphone part of my iPhone headset as a microphone--NOT the microphone part of the headset. I mean, a microphone is basically a backwards speaker, but I didn't realize the iPhone headphones were that sensitive, haha.

 

this thread is only for AppleALC related issue like appleALC not working blah blah ... we can discuss minor AppleHDA tweak too 

 

 

 

Also what do you mean by "working" combojack? Do you mean it worked as stereo Line-IN, too, or just Headphone + headset mic?

  yes combJack as Line-In + Headphone 

 

PS: it's better to discuss and fix your codec (if it really needs) either in PM or my git Repo 

[KNNSpeed]

Yeah, sorry, didn't think this would tangent so far. The only issue I have with my codec is white noise on the headset mic input (there are no other issues with it). If that can be ironed out, it will be suitable for release. I also wanted to post general HDA information that I couldn't find had been posted anywhere, which seemed relevant for people trying to make XMLs for AppleALC (IOMux, for example, is really cool but nobody's written anything useful on it that I've been able to find).

 

Your layout does NOT give me stereo line-in, or even headset mic in (these are two different things, just to make sure we're on the same page), to be clear. Your path defines 8->35->24 for the input, which does not work for my version of ALC3266. We can move to PMs if that would be better.

[wern apfel]

IOMux, for example, is really cool but nobody's written anything useful on it that I've been able to find.

With IOMux you can use a single TRS Jack for input and output, but the node should be IN OUT capable.

Pincap 0x00003734: IN OUT Detect 

Or to switch manually, look at the animated gif here.

[insanelyDeepak]

Yeah, sorry, didn't think this would tangent so far. The only issue I have with my codec is white noise on the headset mic input (there are no other issues with it). If that can be ironed out, it will be suitable for release. I also wanted to post general HDA information that I couldn't find had been posted anywhere, which seemed relevant for people trying to make XMLs for AppleALC (IOMux, for example, is really cool but nobody's written anything useful on it that I've been able to find).

great , I appreciate 

 

 

 

Your layout does NOT give me stereo line-in, or even headset mic in (these are two different things, just to make sure we're on the same page), to be clear. Your path defines 8->35->24 for the input, which does not work for my version of ALC3266. We can move to PMs if that would be better.

I didn't said its suitable for you , but it working good for most, may be for too 

sure we can fix it too 

With IOMux you can use a single TRS Jack for input and output, but the node should be IN OUT capable.

Pincap 0x00003734: IN OUT Detect 

Or to switch manually, look at the animated gif here.

thanks , I never noticed it in Desktop .

[KNNSpeed]

With IOMux you can use a single TRS Jack for input and output, but the node should be IN OUT capable.

Pincap 0x00003734: IN OUT Detect 

Or to switch manually, look at the animated gif here.

 

There's more: Using RetaskDetectDelegate in the platform XML as I mentioned assigns which path belongs to the IOMux, and which [pin complex] node it is shared with. E.g. Putting RetaskDetectDelegate on Node ID 0x24, which is the pin complex for Line-In for mine, and giving it a value of 33 (0x21, the headphone pin complex) informs the OS that the IOMux switches headphone path and line-in path via the switch in SysPrefs. Though, really it's not just headphone pin complex, it's more like the "pin sense capable" pin complex.

 

It's very useful for laptops like mine where the pin sense is only for headphone out, and line-in and headset mic do not have their own pin sense. It can be used, for example, to remove the need for AlcFix entirely if you're OK with going into SysPrefs every time you plug in a headphone and switching to "Input."

 

EDIT: The only values Apple gives IOMux are 0 and 2, and "2" is used in layout ID 28, which is used on the Late 2011 13" MBP (the one with the super combo jack that does SPDIF In/Out, Line-in/out, and extmic). Haven't been able to figure out what the value actually means.

 

EDIT 2: In that GIF, how are you getting the switch to enable the speakers on input?? I'd love to get mine to do that! Lol

[insanelyDeepak]

It can be used, for example, to remove the need for AlcFix entirely if you're OK with going into SysPrefs every time you plug in a headphone and switching to "Input."

ALCFix don't do much it do same as CC do , only when output/input changed (now CC Fails here )

 

 

 

There's more: Using RetaskDetectDelegate in the platform XML as I mentioned assigns which path belongs to the IOMux, and which [pin complex] node it is shared with. E.g. Putting RetaskDetectDelegate on Node ID 0x24, which is the pin complex for Line-In for mine, and giving it a value of 33 (0x21, the headphone pin complex) informs the OS that the IOMux switches headphone path and line-in path via the switch in SysPrefs. Though, really it's not just headphone pin complex, it's more like the "pin sense capable" pin complex.

 interesting 

[KNNSpeed]

I FIXED IT!

 

hda-verb 0x20 SET_COEF_I 0x4f /* Realtek control widget control register */

hda-verb 0x20 SET_PROC_C 0xd400 /* This is what linux does for headset mic on my version of ALC3266 */

 

It works now 

 

What this also means is that, by using AlcPlugFix, we now have a way to exert complete control over audio codecs and can do things just like Linux. For ALC298, there is a control widget on 0x20 that has a TON of configuration registers, and we can set them just like Linux drivers do. I think this means we can pretty much port drivers from Linux now into just a simple shell script like AlcPlugFix and hda-verb, and expose the minimum we need to the OS through AppleALC. All we need are the control registers for each codec. I am soooo happy right now. :DDDDDDD

 

So, here's an idea: With AppleALC and ALCPlugFix, it should now be possible to make a little pop-up menu when something gets plugged in that asks "What did you just plug in?" and then you can pick Headphone, Headset, or Line-In, exactly like how Windows does it.

The key to making drivers is in this line in the codec dump:

(Example: Cirrus 4208)

 

Node 0x24 [Vendor Defined Widget] wcaps 0xf0e2c1: 16-Channels Digital

  Unsolicited: tag=00, enabled=0

  Processing caps: benign=0, ncoeff=128

 

This is the control register, which you can tell by the "ncoeff" part.

 

For the ALC298:

 

Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono

  Processing caps: benign=0, ncoeff=150

 

Etc.

 

So now I should be able to make a perfect audio setup for my ALC3266 by using hda-verb and referencing these linux drivers:

https://github.com/torvalds/linux/blob/28cbc335d272f293c4368abd4ac2e17e36805b79/sound/soc/codecs/rt298.h /* this has the list of registers */

https://github.com/torvalds/linux/blob/master/sound/soc/codecs/rt298.c /* the full codec of the alc298 */

https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c /* implementation-specific quirks, e.g. specific fixups and workarounds for custom Realtek codecs */

 

And I bet you could do it for your own codecs, too. 

[ammoune78]

@insanelyDeepak

 

Please can you help me for each Layout ID can i use for my board and best patch for it, i have some sound assertion seen if I boot in verbose! 

 

Currently i'm using Layout ID 1 and here's Autogenerated Info.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Author</key>
	<string>musismo</string>
	<key>CodecID</key>
	<integer>2183</integer>
	<key>CodecName</key>
	<string>0x10ec0887 Rev:0x100302</string>
	<key>Files</key>
	<dict>
		<key>Layouts</key>
		<array>
			<dict>
				<key>Id</key>
				<integer>1</integer>
				<key>Path</key>
				<string>layout1.xml.zlib</string>
			</dict>
		</array>
		<key>Platforms</key>
		<array>
			<dict>
				<key>Id</key>
				<integer>1</integer>
				<key>Path</key>
				<string>Platforms.xml.zlib</string>
			</dict>
		</array>
	</dict>
	<key>Patches</key>
	<array>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcYGAEmLvCQ=
			</data>
			<key>MaxKernel</key>
			<integer>13</integer>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcYGAUmLvCQ=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcYGAEiLu2g=
			</data>
			<key>MinKernel</key>
			<integer>14</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcYGAUiLu2g=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcaGQwEAAAA=
			</data>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcaGQwEAAAE=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>2</integer>
			<key>Find</key>
			<data>
			ixnUEQ==
			</data>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			hwjsEA==
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>2</integer>
			<key>Find</key>
			<data>
			gxnUEQ==
			</data>
			<key>MinKernel</key>
			<integer>15</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			AAAAAA==
			</data>
		</dict>
	</array>
	<key>Revisions</key>
	<array>
		<integer>1049346</integer>
	</array>
	<key>Vendor</key>
	<string>Realtek</string>
</dict>
</plist>

And best patch for it please!

 

Thanks

 

 

 

[wern apfel]

thanks , I never noticed it in Desktop .

Not sure what you mean, IOMux for desktops?

 

In that GIF, how are you getting the switch to enable the speakers on input?? I'd love to get mine to do that! Lol

I've tested it on a laptop, not tested yet on my desktop. 

 

You can try it by adding IOMux to the layoutXX.xml

<key>Headphone</key>
			<dict>
				<key>IOMux</key>
				<integer>0</integer>

Change the pin config for speaker and line-in, connection type to B (combination), and port connectivity location to 0E for headphones, and 0F for line-in. Make speakers and headphones auto switchable, microphone and line-in too. At the moment I have no access to that laptop and not sure if these are all the necessary changes.

[En0r1m]

 

I FIXED IT!

 

hda-verb 0x20 SET_COEF_I 0x4f /* Realtek control widget control register */

hda-verb 0x20 SET_PROC_C 0xd400 /* This is what linux does for headset mic on my version of ALC3266 */

 

It works now 

 

What this also means is that, by using AlcPlugFix, we now have a way to exert complete control over audio codecs and can do things just like Linux. For ALC298, there is a control widget on 0x20 that has a TON of configuration registers, and we can set them just like Linux drivers do. I think this means we can pretty much port drivers from Linux now into just a simple shell script like AlcPlugFix and hda-verb, and expose the minimum we need to the OS through AppleALC. All we need are the control registers for each codec. I am soooo happy right now. :DDDDDDD

 

So, here's an idea: With AppleALC and ALCPlugFix, it should now be possible to make a little pop-up menu when something gets plugged in that asks "What did you just plug in?" and then you can pick Headphone, Headset, or Line-In, exactly like how Windows does it.

The key to making drivers is in this line in the codec dump:

(Example: Cirrus 4208)

 

Node 0x24 [Vendor Defined Widget] wcaps 0xf0e2c1: 16-Channels Digital

  Unsolicited: tag=00, enabled=0

  Processing caps: benign=0, ncoeff=128

 

This is the control register, which you can tell by the "ncoeff" part.

 

For the ALC298:

 

Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono

  Processing caps: benign=0, ncoeff=150

 

Etc.

 

So now I should be able to make a perfect audio setup for my ALC3266 by using hda-verb and referencing these linux drivers:

https://github.com/torvalds/linux/blob/28cbc335d272f293c4368abd4ac2e17e36805b79/sound/soc/codecs/rt298.h /* this has the list of registers */

https://github.com/torvalds/linux/blob/master/sound/soc/codecs/rt298.c /* the full codec of the alc298 */

https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_realtek.c /* implementation-specific quirks, e.g. specific fixups and workarounds for custom Realtek codecs */

 

And I bet you could do it for your own codecs, too. 

 

Congratulations on your hard work, 

maybe vit9696 can do a deployment in AppleALC 

but before the users of Laptops would have to test your method

and make sure that it works with more codecs since 

that each case is unique and specific.

[insanelyDeepak]

@insanelyDeepak

 

Please can you help me for each Layout ID can i use for my board and best patch for it, i have some sound assertion seen if I boot in verbose! 

 

Currently i'm using Layout ID 1 and here's Autogenerated Info.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Author</key>
	<string>musismo</string>
	<key>CodecID</key>
	<integer>2183</integer>
	<key>CodecName</key>
	<string>0x10ec0887 Rev:0x100302</string>
	<key>Files</key>
	<dict>
		<key>Layouts</key>
		<array>
			<dict>
				<key>Id</key>
				<integer>1</integer>
				<key>Path</key>
				<string>layout1.xml.zlib</string>
			</dict>
		</array>
		<key>Platforms</key>
		<array>
			<dict>
				<key>Id</key>
				<integer>1</integer>
				<key>Path</key>
				<string>Platforms.xml.zlib</string>
			</dict>
		</array>
	</dict>
	<key>Patches</key>
	<array>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcYGAEmLvCQ=
			</data>
			<key>MaxKernel</key>
			<integer>13</integer>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcYGAUmLvCQ=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcYGAEiLu2g=
			</data>
			<key>MinKernel</key>
			<integer>14</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcYGAUiLu2g=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>1</integer>
			<key>Find</key>
			<data>
			QcaGQwEAAAA=
			</data>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			QcaGQwEAAAE=
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>2</integer>
			<key>Find</key>
			<data>
			ixnUEQ==
			</data>
			<key>MinKernel</key>
			<integer>13</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			hwjsEA==
			</data>
		</dict>
		<dict>
			<key>Count</key>
			<integer>2</integer>
			<key>Find</key>
			<data>
			gxnUEQ==
			</data>
			<key>MinKernel</key>
			<integer>15</integer>
			<key>Name</key>
			<string>AppleHDA</string>
			<key>Replace</key>
			<data>
			AAAAAA==
			</data>
		</dict>
	</array>
	<key>Revisions</key>
	<array>
		<integer>1049346</integer>
	</array>
	<key>Vendor</key>
	<string>Realtek</string>
</dict>
</plist>

And best patch for it please!

 

Thanks

there is bunk of layouts for ALC887 = layout 1, 2, 3, 5, 7, 11, 13, 17, 18, 33, 99 

 

11 ,13,17 are mine 

suggestion try all wich suites you best till , if none works I'm here 

Congratulations on your hard work, 

maybe vit9696 can do a deployment in AppleALC 

but before the users of Laptops would have to test your method

and make sure that it works with more codecs since 

that each case is unique and specific.

I dont think this possible from kext side otherwise CC can do it 

me and Goodwin did all try that's why ALCPlugFix is exist 

 

PS: who know everything is possible in development 

[KNNSpeed]

Here's some more information on processing coefficients:

 

From here (Audio debugging techniques):

http://voices.canonical.com/david.henningsson/2011/12/08/audio-debugging-techniques/

 

The information coming from the codec is usually correct. One problem we have from time to time is though, is that sometimes chip vendors add features which they choose not to document in this graph (and not in any other way either). There is a mechanism called “processing coefficients” in the specification, where the vendor can add its own functionality without telling anyone. When that happens, and it is required to use these undocumented “processing coefficients” to enable all inputs and outputs, we usually run into difficult problems that require vendor support to resolve.

 

ALSA in linux can dump the coefficients (which do change depending on whether things are plugged in or not, and whether they are line-in, line-out, etc.):

http://mailman.alsa-project.org/pipermail/alsa-devel/2014-January/071874.html

I asked RehabMan if it would be possible to add headphone jack detection to CodecCommander, but he hadn't found a method of doing that and recommended continued use of ALCPlugFix.

 

I guess we can't just add ALCPlugFix's code to CC? (I'm not terribly familiar with what a kext can/can't do, and I know Windows & Linux drivers can do stuff like this.)

Actually, can we turn ALCPlugFix into a proper .app that has a menubar icon? Then it should be able to prompt for things like "What did you just plug in?" for jacks that don't support headset mic autodetection (like mine).

[insanelyDeepak]

 

I guess we can't just add ALCPlugFix's code to CC? (I'm not terribly familiar with what a kext can/can't do, and I know Windows & Linux drivers can do stuff like this.)

 

I dont think this possible from kext side otherwise CC can do it 

me and Goodwin did all try that's why ALCPlugFix is exist 

 

like you did now , we were same situation , we found sometimes (most of times) CC fails bcoz CC works only when system starts or Sleep , it don't detect jack retask (plug and unplug) 

it was not possible for kext , so goodwin_C made ALCPlugFix which works awesome  

[SavageAUS]

 

 

I FIXED IT!

 

So, here's an idea: With AppleALC and ALCPlugFix, it should now be possible to make a little pop-up menu when something gets plugged in that asks "What did you just plug in?" and then you can pick Headphone, Headset, or Line-In, exactly like how Windows does it.

 

 

+1 for a popup.

I have alc3236 (using layout id 4) on my laptop and would love to do some testing if need be.

 

Sent from my SM-G930F using Tapatalk

[insanelyDeepak]

 

I've tested it on a laptop, not tested yet on my desktop. 

 

correct 

 

as you already mentioned its for TRSS jack