Jump to content

AppleALC — dynamic AppleHDA patching

vit9696

By vit9696,
in AppleALC

 Share
5,371 posts in this topic

Recommended Posts

lihuachuan
lihuachuan
Posted
Posted

Well… This information is more or less enough for us. I had a talk to Vandroiy, and we agreed to include the patch for your 20712/2 codec starting with 10.10+. It is now present in trunk.

Thanks for your work.In fact, my wish is not  only add it to my own using CX20751/2 codec.It is a samall fix,but it is useful.I believe that is a common patcht for conexant codec. Wern apfel maybe know more about it.I must answer you truthfully, because of I am only using cx20751/2 ant not more test. It may be useful for other users of conexant codec after I post #1261  codec Finally, thanks again for @vit9696, @Vandroiy2012 @ wern apfel, etc.

Link to comment
Share on other sites
lihuachuan
lihuachuan
Posted
Posted

Well… This information is more or less enough for us. I had a talk to Vandroiy, and we agreed to include the patch for your 20712/2 codec starting with 10.10+. It is now present in trunk.

Hi，@vit9696， I am very sorry. I made a mistake on post #1271. It should be CX20751/2.

Link to comment
Share on other sites
vit9696
vit9696
Posted
  • Author
Posted

@lihuachuan, mhm… Ok. Added for 20751/2 and 20724 (it was mentioned in this thread) as well. We will remove the change for 20712 if it breaks anything I guess. I asked Wern Apfel to give us some details regarding the change, hopefully he will find some time to do it.

 

@Andrw0380 speaking of HDMI patches I bet Vandroiy knows better about it, so it is better to wait for him. Speaking of 92HD91BXX changes, I guess we could apply the changes, but ideally Rehabmann also merges them, since it is always easier to update from a centralised place. Could it negatively affect any other devices (i.e. not HP Envy it was originally designed for)? If it could, they should probably go as a custom layout, if not, why not then.

 

@El Capitan, merged this.

  • Like 1
Link to comment
Share on other sites
lihuachuan
lihuachuan
Posted
Posted

@lihuachuan, mhm… Ok. Added for 20751/2 and 20724 (it was mentioned in this thread) as well. We will remove the change for 20712 if it breaks anything I guess. I asked Wern Apfel to give us some details regarding the change, hopefully he will find some time to do it.

 

@Andrw0380 speaking of HDMI patches I bet Vandroiy knows better about it, so it is better to wait for him. Speaking of 92HD91BXX changes, I guess we could apply the changes, but ideally Rehabmann also merges them, since it is always easier to update from a centralised place. Could it negatively affect any other devices (i.e. not HP Envy it was originally designed for)? If it could, they should probably go as a custom layout, if not, why not then.

 

@El Capitan, merged this.

Thanks very much. I hope so.

Link to comment
Share on other sites
Andrw0380
Andrw0380
Posted
Posted

@lihuachuan, mhm… Ok. Added for 20751/2 and 20724 (it was mentioned in this thread) as well. We will remove the change for 20712 if it breaks anything I guess. I asked Wern Apfel to give us some details regarding the change, hopefully he will find some time to do it.

 

@Andrw0380 speaking of HDMI patches I bet Vandroiy knows better about it, so it is better to wait for him. Speaking of 92HD91BXX changes, I guess we could apply the changes, but ideally Rehabmann also merges them, since it is always easier to update from a centralised place. Could it negatively affect any other devices (i.e. not HP Envy it was originally designed for)? If it could, they should probably go as a custom layout, if not, why not then.

 

@El Capitan, merged this.

Ok no problem regarding IDT92HD91BXX as I understand if it can have a negative affect on other people who have a different revision of this codec, then it's best not to merge it. I can't give a 100% Yes or No whether it will break other users but I could always talk to Rehabman to see if he can update it. Question I did mention to him a couple days ago about this patch

<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> 

as this patch on your repo seems to fix headphone switching on the IDT codec, but Rehabman asked me about it and I was wondering how you found it?

Regarding HDMI, I will wait for the HDMI patches as that is the only thing that I still have to add a Clover patch for.

Link to comment
Share on other sites
pico joe
pico joe
Posted
Posted

Hi all

Honestly, I didn't understand how both kexts  (AppleALC and Lilu.kext) can worked .. donwload from repository AppleALC v 1.1.0 or build AppleALC v 1.1.1 

put in .../kexts/other but still can't get the audio

with v 1.0.19 normal

 

thanks

Link to comment
Share on other sites
MaLd0n
MaLd0n
Posted
Posted

Hi all

Honestly, I didn't understand how both kexts  (AppleALC and Lilu.kext) can worked .. donwload from repository AppleALC v 1.1.0 or build AppleALC v 1.1.1 

put in .../kexts/other but still can't get the audio

with v 1.0.19 normal

 

thanks

i put lilu in plugin folder and work

AppleALC.kext.zip

  • Like 1
Link to comment
Share on other sites
vandroiy2012
vandroiy2012
Posted
Posted

I was trying out HDMI while using AppleALC and I could not get the output device to show in Sound. I looked and found out even though AppleALC has 0c0c device IDs in Controllers.plist, this important patch is missing

<dict>
				<key>Comment</key>
				<string>HDMI-audio, port 0204, 0x0a260005 0x0a260006</string>
				<key>Disabled</key>
				<false/>
				<key>Find</key>
				<data>AgQJAAAEAACHAAAA</data>
				<key>Name</key>
				<string>com.apple.driver.AppleIntelFramebufferAzul</string>
				<key>Replace</key>
				<data>AgQJAAAIAACHAAAA</data>
			</dict>

I re-enabled this patch from Clover as I used this patch along with the FakePCIID_Intel_HDMI_Audio.kext previously but had to remove that kext to not interfere with AppleALC. I now get sound when my TV is connected, but wanted to let you know since in Controllers.plist, I see other Intel 4600 HDMI patch and this one listed above is not listed for laptop.

 

I am not trying to be difficult as I appreciate all the hard work you guys put into it. I am just mentioning something I found.

 

The only patch for HDMI Audio for HD4600 is desktop ig-platform-id 0x0d220003. For other ig-platform-id's use Clover KextToPatch section because most of laptop/desktop HD4600 ig-platform-id's needs custom port patching. So we decided leave them as is. If you need HDMI audio on other ig-platform-id's use custom Clover patches. 

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Hi guys,

 

I tried release 1.1.0 on a Skylake 6600 build aaand I got no sound. Worked fine with 1.0.17, 1.0.19 but no sound with 1.1.0. Not sure why. I saw something related to a Lilu.kext...? What's that? And is this the reason why 1.1.0 doesn't work for this build anymore?

Link to comment
Share on other sites
vandroiy2012
vandroiy2012
Posted
Posted

Hi guys,

 

I tried release 1.1.0 on a Skylake 6600 build aaand I got no sound. Worked fine with 1.0.17, 1.0.19 but no sound with 1.1.0. Not sure why. I saw something related to a Lilu.kext...? What's that? And is this the reason why 1.1.0 doesn't work for this build anymore?

 

From version 1.1.0 AppleALC is a plugin for Lilu.kext. Kernel patcher now in Lilu so without it AppleALC won't work.

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

From version 1.1.0 AppleALC is a plugin for Lilu.kext. Kernel patcher now in Lilu so without it AppleALC won't work.

 

 

Thank you for your reply. :)

 

One thing is not very clear to me. Should I use Lilu.kext from now on to have working sound? And if so, can I take version 1.0.0 from Lilu release page here? Oor...I need to somehow use both AppleHDA and Lilu? It's not very clear to me how should I use this if I previously used AppleALC.

 

For now everything works fine with AppleALC 1.0.19. And I could just continue to use that instead. But I'm just trying to understand how this is supposed to work, in case I need it in the future.

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Use latest Lilu.kext from GitHub with latest AppleALC.kext. And yes! From now on AppleALC WON'T WORK WITHOUT Lilu.kext. 

 

@vit9696, Could you please add this information in first post :)

 

So, basically put both kexts in Clover/kexts/Other or /10.x. Right?

 

And yes, maybe a few words about this on the main page, would be highly appreciated! :)

 

Thank you!

  • Like 1
Link to comment
Share on other sites
El Capitan
El Capitan
Posted
Posted

@vit9696

 

I've revised my AppleALC entry for "Mosser - ALC269VB Dell Precision Workstation T1600"

 

Now all the outputs and input(s) actually work - apart from the blue/pink "rear input".

 

The front input/mic has "ambient noise reduction" and very good sound quality. The rear LINE OUT and FRONT HEADPHONE are mutually selectable.

 

 

 

 

Dell Precision T1600 Workstation layout-id 11 (0x0B)

 

Codec: Realtek ALC269VB

Vendor Id: 0x10ec0269

Subsystem Id: 0x10280498

Revision Id: 0x100100

 

attachicon.gifT1600.AppleALC.Params.rev1.zip

 

 

Previously, I stated that the "rear input" on the back of the Dell Dimension T1600 Workstation  was not working with the latest revised AppleALC. Well, this is only partially true. The input on the back of the iMac (and the T1600) is NOT for a microphone; it is only for amplified input: looping the "rear output" to the "rear input" results in a sound recording.

 

Link to comment
Share on other sites
c0ke
c0ke
Posted
Posted

Well… This information is more or less enough for us. I had a talk to Vandroiy, and we agreed to include the patch for your 20712/2 codec starting with 10.10+. It is now present in trunk.

 

@vit9696, @vandroiy2012

 

reading accurately the last pages of this topic I figured out @lihuachuan had same issues than me. I saw the patch at post #1261 made by wern apfel, the same author of the mysterious patched AppleHDA "for Dell Latitude E6400, IDT 92HD71B7". The same patch is mentioned in other forums about appleHDA and conexant cards, without further explanation about its effectiveness, so I just checked the diff between vanilla sierra kext and the patched one mentioned before and I've found:

75524c75524
< 00000000000478d0	41 be 6b 70 73 69 	movl	$0x6973706b, %r14d
---
> 00000000000478d0	41 be 63 69 6d 69 	movl	$0x696d6963, %r14d

I believe it's the same imic -> ispk swap highlighted by RehabMan. And it seems that the same patch was applied successfully to let our IDT 92HD71B7 card work. So in xcode I edited manually the info.plist of my card adding the same patch you recently submitted for conexant cards, building again the kext and applying it.

It seems to work really well: keyboard volume control, menubar and system preference slider appear to be correctly synced. It would be great to learn more about what's happening with this patch...

However I've tested only built-in speakers of my laptop and internal mic so far. I'll report later if it helps.

 

I would like to thank you to share with the community your knowledge and such a powerful instruments to be able to learn and improve our stuff.

Link to comment
Share on other sites
Kynyo
Kynyo
Posted
Posted

"Pros (compared to existing bootloader patchers):

  • Does not depend on a bootloader;
  • Works in Recovery / OS Installer;
  • Supports symbolic patcher;
  • Enables kernel and kext API access;
  • Allows process modifications.

Control (via boot-args):

  • -liludbg — enable debug printing (available in DEBUG binaries);
  • -liluoff — disable Lilu;
  • -liluslow — enable legacy user patcher;
  • -lilulowmem — disable kernel unpack (disables Lilu in recovery mode);
  • -lilubeta — enable Lilu on unsupported os versions." @ vit9696
  • Like 1
Link to comment
Share on other sites
DaffyDuck
DaffyDuck
Posted
Posted

So, basically put both kexts in Clover/kexts/Other or /10.x. Right?

And yes, maybe a few words about this on the main page, would be highly appreciated! :)

Thank you!

Actually, some sort of instructions document would probably be incredibly helpful - including packing AppleALC and lilu together in the release package. Just a suggestion.

Link to comment
Share on other sites
arsradu
arsradu
Posted
Posted

Yeah, initially I was like: why did they split it? Looks like more work to maintain two kexts instead of one.
 
Then I came across this page. And then everything started to make more sense. For someone who never heard of Lilu, of course it looked like a weird decision. But now it make sense.
 
Basically, Lilu is not just for patching audio. It can actually do a lot more, with the right plugins. So...kinda neat, I would say. :) Also, not sure that, under the current circumstances and desired functionality, there will be any AppleALC-Lilu merged kext. :) But I might be wrong.

  • Like 1
Link to comment
Share on other sites
tluck
tluck
Posted
Posted

all good here: v1.1.1 + Lilu 1.0.0 working on my T460 for ALC293 

 

... build with Xcode 8.x - just took a few minutes to figure out the right changes to integrate the Lilu code/header path definitions ... as my 2 source trees are at the same directory level (if that makes any sense!)

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...