alsa-project/alsa-ucm-conf

Add support for AMD ACP Microphone devices for Yellow Carp platform

vijendarmukunda opened this issue · 8 comments

We have tried to add similar changes which were applied for Renoir platform for YC platform by following below link.
#54

But we are unable to create links.

Without ALSA UCM changes, we are able to observe similar issues earlier reported on Renoir platform as mentioned below.

  1. Fallback profile is getting loaded and capture endpoint name is not listed as "Digital Microphone"
  2. Mic Mute Led button is not reflected with Mute status.

Attached pa-info and alsa info output.
painfo.txt
alsa-info.txt
a

Could you test changes in the above PR #138?

will verify the changes and let you know the result

I had some test on an upcoming platform that uses this, and I can confirm that this is fixed:

Fallback profile is getting loaded and capture endpoint name is not listed as "Digital Microphone"

However the mic mute LED doesn't work by default. So I ran alsactl clean and rebooted the machine.
Here is the logs from muting or not muting in the GUI:
painfo_not_muted_logs.txt
pactl_list_sources_muted.txt
pactl_list_sources_not_muted.txt
painfo_muted_logs.txt

Another interesting thing I found by default in the mixers that there is a "Capture" source that is enabled.
image
If I disable that source like this:
image

Then the GUI starts working for controlling mic mute LED.

It's correct behavior. Mic mute LED is connected to two paths - the software defined Mic LED mixer control and HDA capture control by default. Both must be off to turn on the mic mute LED.

The mixer paths may be controlled using pavucontrol or any other tool for the pulseaudio/pipewire configuration (select the input path + mute sound button).

Yeah, from pavucontrol if I go and mute both the "Family 17h (Models 10h-1fh) HD Audio Controller Headphones Stereo Microphone" and the "Family 17h (Models 10h-1fh) HD Audio Controller Digital Microphone" from pavucontrol then I can observe the LED does turn on. I guess we can close this then.

BTW - that Family ### (Models ###) business is completely wrong - this is a family 19h model 44h. Where does it populate that from?

I think that those strings are from udev - udevadm info /sys/class/sound/card0 (maybe another card).

Ah thanks, it looks like they pull from the PCI database.

E: ID_MODEL_FROM_DATABASE=Family 17h (Models 10h-1fh) HD Audio Controller

I'll submit a request there to make them more generic.

@vijendarmukunda please close this issue as Jaraslov committed the fix above.