Microphone working on AMD, with AppleALC.kext

[atanvarno]

I'm not sure did I just discover hot water but...from @CaseySJ post from last December, I assumed that no-mic-on-AMD is still the case in AppleALC.kext land.
While researching further, mainly to figure out how to do Realtek HDA codec-dump for my builds, I encountered a post of Discord that lead me to this commit on someone's fork of AppleALC:

A "safer" workround for AMD ZEN Microphone · qhuyduong/AppleALC@b071754

Previously the workround is to disable DMA Position Buffer Enable bit completely, which can be dangerous. This new patch just skips that bit check in getAudioStreamLinkPositionInDMABuffer method, w...

github.com

I took this commit (which is from Aug 2023), added it to my local fork of AppleALC 1.8.7, compiled and replaced the resulting .kext in the EFI. I then tested using Deity V-Mic D4 plugged into back mic-in port on my board (Gigabyte B550I Aorus AX Pro with 5900X). It works!



The first part of the recording is with 400% gain, then I tried without that block and default gain levels are also just fine. The sound is rather noisy though, with System Settings / Sound / Input level set to MAX. Maybe this patch needs fine-tunning or something more suitable than alcid=1 is needed for my build.

Here's the recorded audio file as well as compiled AppleALC.kext if someone else wants to try.

(Does anyone know who qhuyduong is..?)

 

[Edhawk]

As your Gigabyte motherboard uses the Realtek ALC1220-VB codec, chances are that others with the same Audio codec would also have a working Mic, using your Forked AppleACL.kext.

 

[atanvarno]

As your Gigabyte motherboard uses the Realtek ALC1220-VB codec, chances are that others with the same Audio codec would also have a working Mic, using your Forked AppleACL.kext.

This is likely universal fix, for any AMD board (or at least B550 chipset).
I have not seen anything that specifically targets 1220 sound chip.

 

[Edhawk]

AppleALC.kext will be targeting your Audio Codec, along with using layout-id=1. Layout-id=1 is a generic (catch-all) ID that along with ids 2, 3, 5 & 7 are the standard IDs people use. Any ID higher than 7 is usually a custom codec setting for a specific board/system.

Generic layout-ids created by Toleda and Mirone, both past-masters when it came to Audio patching.

I know of a few people who created custom layout-ids for their systems, which were in turn incorporated in to AppleALC.kext. Unfortunately most of them weren't using AMD boards, the majority were for Intel Hacks and Laptops.

Looking through the Supported Codecs and specifically the info.plist for the ALC1220 codec, I noticed that @CaseySJ has created a custom layout-id=20 for a Gigabyte B550 Vision D system.



Changing the layout-id you are using from 1 to 20 might give you a better result with the Mic.

I am using another custom layout-id Casey created for my Asus ROG Strip X570-F gaming Hack.

 

[atanvarno]

I think I have about 20 or so browser tabs, 2/3 are from Casey on various forums

I'm just done with preparing codec dump from Ubuntu Live (which was another first for me) so will see which one of the existing layouts most resembles my own.
This is what it looks like in PinConfigurator as loaded from codec dump:



This is after doing Verb Sanitize



Enough for today, will continue tomorrow, as work allows.

Not sure is there a way to load layoutXY.xml into PinConfigurator or similar app to visualize the codec.

 

[CaseySJ]

This is very interesting! I have been unable to get Microphone Input to work on any of my AMD Hackintoshes, including B550 Vision D that has Realtek 1220.

I will try the modified AppleALC as soon as I get a chance!!

It seems that the fix in question affects all AMDZEN controllers, so it is independent of Layout ID.

Is the microphone input noisy?

 

[CaseySJ]

I think @ExtremeXT will be interested in this!

 

[CaseySJ]

Update -- Rear Mic Input Works!

Yes the rear microphone input works! Here's a test file created as follows:

• Played NPR Radio on iPhone
• Recorded via simple handheld microphone using Voice Memos app in Sonoma on my Gigabyte B550 Vision D

Recording is quite good. If you speak too loudly (i.e. reach clipping) then there will be noise. But if input loudness is reasonable, there is no noticeable noise.

I am unable to use front Microphone input, but that may be due to Layout ID. Anyway, the rear Mic works rather well.

 

[atanvarno]

Recording is quite good. If you speak too loudly (i.e. reach clipping) then there will be noise. But if input loudness is reasonable, there is no noticeable noise.

Yeah, this audio is just fine. It's rather perfect actually, considering you just pointed a mic into a speaker.

I had Deity V-Mic D4 for months now and was unable to use it on the main build, only occasionally on my old MacBook Pro. Curious fact about that mic, which has USB-C port on itself and various cables with some jack on the other end: when used with TRRS audio jack, input gain levels are as expected. It also has a USB-C to USB-C cable and while it works, signal is really weak. That screenshot in my first post is me trying to boost the volume in order to make sure it even works. It needs about ~10x more gain to bring it into usable levels. Basically it needs a preamp / booster before going into computer.

 

[Shaneee]

Swapped in the AppleALC from first post and changed layout ID to 1. Audio still works as it should and front panel mic on my gaming headset works flawlessly.

 

[atanvarno]

Here's the source code branch from where I compiled the .kext.

Nothing really specials, the branch is current master from acidanthera/AppleALC and then merged the master branch from qhuyduong/AppleALC. Then followed steps to add MacKernelSDK and Lilu.kext + link the mentioned library. It builds with no errors, using Xcode 15.

 

[CaseySJ]

The microphone fix was made in late August, but the author hasn't submitted a pull request back to Acidanthera. This is unfortunate.

I wonder if one of us can submit a pull-request to Acidanthera while crediting qhuyduong (based in Vietnam) for the fix? Not sure whether that would be questionable behavior, but the author has made these changes public.

Let me at least ping the author to submit the PR.

 

[atanvarno]

I sent him an email along with a comment, urging him to do a PR. Will see...

 

[CaseySJ]

I spent many hours in vain looking for a solution to microphone input. After experimenting with codec verbs and PCIe flags, it seemed that the solution would lie somewhere in PCIe configuration. I'm glad to see that the solution involves DMA buffers (a PCIe configuration item), and the patch itself is very simple.

 

[ExtremeXT]

This is a workaround, it disables the PCI DMA check when creating audio streams, that's why it was not merged into upstream.

 

[CaseySJ]

This is a workaround, it disables the PCI DMA check when creating audio streams, that's why it was not merged into upstream.

Does Linux use the same workaround?

I looked at the Linux source code several months ago and there are all sorts of PCI patches that are enabled selectively for different AMD audio controllers. I don't remember whether one of those patches is similar to this workaround.

From the author's pull-request:

In the function AppleHDAController::getAudioStreamLinkPositionInDMABuffer(IOHDAStream*, uint64_t*), it expects bit 0 of register 0x70 to be cleared before reading DMA position. However, for AMD, it somehow is not cleared, hence DMA position is incorrect. For now the workround is to skip that bit check.

 

[atanvarno]

This is a workaround, it disables the PCI DMA check when creating audio streams, that's why it was not merged into upstream.

I'm confused...is this somehow a drawback..?

 

[Edhawk]

Wouldn’t the correct patch have been to set this bit as ‘0’, rather than skipping it? So the PCI DMA check wasn’t omitted.

 

[ExtremeXT]

I'm confused...is this somehow a drawback..?

Well, the check is there for a reason, I don't know what it is but there is one.

Wouldn’t the correct patch have been to set this bit as ‘0’, rather than skipping it? So the PCI DMA check wasn’t omitted.

The correct patch would be to find out why the bit is not the correct value and correct that instead.

 

[CaseySJ]

I'm confused...is this somehow a drawback..?

Wouldn’t the correct patch have been to set this bit as ‘0’, rather than skipping it? So the PCI DMA check wasn’t omitted.

Linux also struggles with DMA Position registers.




Some quirks Linux uses on AMD controllers: