[BUG] ASoC: amd: acp70: Acer Nitro AN16S-61 falls back to acp-pdm-mach, which streams invalid PCM (no working internal mic)

[BUG] ASoC: amd: acp70: Acer Nitro AN16S-61 falls back to acp-pdm-mach, which streams invalid PCM (no working internal mic)

[hazar sahmeran acikbas]

Hello,

On an Acer Nitro AN16S-61 (ACP 7.0, 1022:15e2 rev 70) there is no working
internal microphone under Linux. The board has no entry in the ACP70 DMI
config quirk table in snd_acp_config, so it falls through to the generic
acp-pdm-mach machine driver. That driver creates a capture device which
opens and streams without error, but the data is not PCM audio.

This differs from other reported ACP 7.0 machines (ASUS ROG Flow Z13, HP
Omen 16-ap0xxx) where no PDM capture device is created at all. Here
enumeration, board match and PCM open all succeed; only the data is wrong.

Hardware
--------
DMI  sys_vendor      Acer
     product_name    Nitro AN16S-61
     product_family  Acer Nitro 16S AI
     board_vendor    SXP
     board_name      EV3_SKF
     bios_version    V1.53  (03/06/2026)

ACP (Audio Coprocessor)  1022:15e2 rev 70, subsystem 1025:1874
HD Audio Controller      1022:15e3, subsystem 1025:1874
Analog codec             Realtek ALC245 (10ec:0245), codec SSID 0x10251874

There is no SoundWire codec on this board.

Environment
-----------
Kernel          7.2.0-1-cachyos (x86_64)
sof-firmware    2025.12.2
linux-firmware  20260622
alsa-ucm-conf   1.2.16.1
Userspace       PipeWire/WirePlumber, default config

Legacy ACP path is active; SOF is not bound (no /sys/kernel/debug/sof).
snd_sof_amd_acp70 is loaded but users=0.

Binding chain (all of this succeeds)
------------------------------------
  snd_acp_pci  ->  PCI 0000:64:00.5
  ACPI-based match via snd_amd_acpi_mach
  ->  platform devices acp_asoc_acp70.0 and acp-pdm-mach

Card longname is correctly derived from DMI:

  SXP-NitroAN16S_61-V1.53-EV3_SKF

The kernel log is silent on ACP apart from one line:

  snd_acp_pci 0000:64:00.5: enabling device (0000 -> 0002)

No probe errors or warnings. Card 3 registers zero ALSA controls --
"amixer -c 3 controls" and "amixer -c 3 scontrols" both return nothing,
so there is no PDM gain or enable control of any kind.

Reproduce
---------
  $ arecord -l
  card 3: acppdmmach [acp-pdm-mach], device 0: DMIC capture dmic-hifi-0 []

  $ arecord -D plughw:3,0 -f S32_LE -c 2 -r 48000 -d 3 /tmp/dmic.wav

Then inspect the samples:

  $ python3 -c "
  import struct, collections
  d = open('/tmp/dmic.wav','rb').read()[44:]
  n = len(d)//4
  s = struct.unpack('<%di' % n, d[:n*4])
  c = collections.Counter(s)
  print('samples', n, 'min', min(s), 'max', max(s), 'distinct', len(c))
  print('first 16', s[:16])
  "

Actual result
-------------
A 3-second capture (288000 stereo S32_LE samples) contains only FOUR
distinct sample values:

  min = -2147483648, max = +2147483647, distinct = 4
  287956 of 288000 samples (99.98%) are exactly INT_MIN

The opening frames are a regular alternating pattern:

  -2147483648, -2147483648, +2147483647, +2147483647, -2147483648, ...

i.e. a full-scale square wave at Fs/2, which then collapses to a constant
INT_MIN rail for the remainder of the capture. This looks like an
undecimated/unconverted bitstream or DMA'd garbage rather than a
microphone that is present but silent.

hw:3,0 rejects S16_LE ("Sample format non available"); only S32_LE opens.

Expected: real microphone audio.

The HDA/ALC245 path does not provide the internal mic either
------------------------------------------------------------
The ALC245 pin configuration declares two internal digital mic pins:

  Node 0x12  Pin Default 0x90a60130  [Fixed] Mic at Int, Conn = Digital
  Node 0x13  Pin Default 0x90a60140  [Fixed] Mic at Int, Conn = Digital

Both are exposed as mutually-exclusive capture sources on the HDA card
("Internal Mic" and "Internal Mic 1"), and both default to off with the
external jack "Mic" selected. Selecting each in turn and capturing:

  Internal Mic   (0x12): all zeros, 1 distinct value
  Internal Mic 1 (0x13): an opening full-scale transient that decays
                         exponentially to zero and stays there

Per-0.125s AC-RMS for 0x13 with Internal Mic Boost at maximum (+30 dB):

  1884 906 435 209 100 48 23 11 5 2 1 2 0 0 0 0 0 0 0

That is a filter/DC settling artifact at stream open, not audio. Capture
volume was at maximum in both cases. So the internal mics are not merely
deselected on the HDA codec; neither pin carries a working signal.

For reference, the codec picks only a vendor-level fixup, not a
board-specific one (this kernel is built without CONFIG_SND_DEBUG_VERBOSE,
so the quirk name is stripped from the message):

  snd_hda_codec_alc269 hdaudioC2D0: ALC245: picked fixup  for PCI SSID
  1025:0000

Already ruled out
-----------------
- Reproduces at raw ALSA (arecord), independent of PipeWire/WirePlumber.
  No custom PipeWire/WirePlumber configuration is present.

- Not a machine-match problem: the ACPI match succeeds, both platform
  devices are created, and the DMI-derived card longname is correct.

- Not UCM: alsa-ucm-conf ships a matching profile for this machine driver
  (conf.d/acp-pdm-mach/acp-pdm-mach.conf), and the failure reproduces with
  arecord on plughw directly, which does not go through UCM.

- Not a muted or deselected input: capture gain was at maximum on both
  cards, and both ALC245 internal-mic sources were explicitly selected
  and tested.

- Not a stale local override: the machine previously had an invalid
  "options snd-hda-intel model=alc245-acer" in /etc/modprobe.d. That file
  was removed and the machine rebooted; all results above are from a
  stock configuration, and nothing changed.

- Mic-mute hardware is inert under Linux here: KEY_MICMUTE (248) and
  KEY_F20 (190) are both absent from the "Acer WMI hotkeys" capability
  bitmap, and no micmute LED class device exists. The device does report
  KEY_WLAN, KEY_PROG1 and KEY_TOUCHPAD_TOGGLE, so the hotkey path itself
  works. (This missing keymap entry looks like a separate acer-wmi gap
  worth fixing independently.) The EC's own power-on state is not visible
  from the OS, so this is not a formal proof -- but a muted DMIC would
  give clean zeros, not a full-scale Nyquist square.

Suggested fix
-------------
The mechanism needed appears to exist in-tree already. The ASUS ProArt
PX13 series ("ASoC: amd: acp: PX13 ACP70 config and machine quirks",
March 2026, merged via for-7.0) added a DMI-keyed override in
snd_acp_config that redirects ACP70 boards away from the generic PDM
machine-driver fallback onto the correct path for that board. That table
is present in the running kernel -- the ASUS board string is visible in
the module:

  zstdcat /lib/modules/7.2.0-1-cachyos/kernel/sound/soc/amd/snd-acp-config.ko.zst
| strings | grep HN7306EA

There is simply no entry for this Acer board, so it falls through to
acp-pdm-mach, which is evidently not how its DMICs are wired.

Request: add an ACP70 config quirk entry for the Acer Nitro AN16S-61
(DMI product "Nitro AN16S-61", board "EV3_SKF", ACP subsystem 1025:1874).

What that entry should select is the open question, and I do not have
enough information to answer it. Unlike the PX13, this board has no
SoundWire codec, and the two internal DMIC pins declared on the ALC245
are both silent. So the DMICs appear to be on neither a working PDM
instance nor the HDA codec as currently configured. Possibilities:

  - a different PDM controller instance than the fallback selects;
  - missing PDM clock / decimation-ratio / gain init for ACP 7.0 on this
    board (card 3 registering zero ALSA controls may be a symptom);
  - an ACPI/_DSD-declared endpoint configuration the current code does
    not honour.

I am happy to test patches, apply debug printks, dump ACP registers, or
provide any further logs on request. alsa-info.sh output can be supplied
or uploaded on request -- I did not upload it pre-emptively.

Thanks for looking at this.

Re: [BUG] ASoC: amd: acp70: Acer Nitro AN16S-61 falls back to acp-pdm-mach, which streams invalid PCM (no working internal mic)

[hazar sahmeran acikbas]

Following up with one new data point that narrows this down.

The internal microphone array works correctly under Windows on this same
machine, with stock vendor drivers and no hardware or firmware changes
between the two tests (same BIOS V1.53). So the DMICs are physically
present and functional, and the EC is not holding them in a muted state.

That rules out the two non-software explanations I could not exclude from
Linux alone, and I think confirms this is purely a missing/incorrect
configuration on the Linux side rather than a hardware or firmware fault.

Still reproducing, unchanged, on newer kernels:

  7.2.0-1-cachyos  (original report)
  7.2.4-1-cachyos
  7.2.6-1-cachyos  (current)

with linux-firmware now at 20260916. The ACP70 DMI config quirk table in
snd_acp_config continues to contain only the ASUS HN7306EA entry, and the
capture behaviour is bit-for-bit what I described originally: the
acp-pdm-mach capture device opens and streams a full-scale square wave at
Fs/2 that collapses to an INT_MIN rail, and both internal DMIC pins
declared on the ALC245 are silent at maximum gain.

The open question from my original report stands: what a quirk entry for
this board should actually select, given there is no SoundWire codec here
and the ALC245's declared internal DMIC pins produce nothing.

I am happy to run anything that would help answer that -- debug patches,
printks in the ACP70 config/match path, ACP register dumps, ACPI table
dumps (acpidump/iasl output for the ACP device's _DSD), or alsa-info.sh
output. Just tell me what would be most useful and I will turn it around
quickly.

Thanks,
Hazar

hazar sahmeran acikbas <hazaracikbas@gmail.com>, 29 Ağu 2026 Cmt,
23:35 tarihinde şunu yazdı:
>
> Hello,
>
> On an Acer Nitro AN16S-61 (ACP 7.0, 1022:15e2 rev 70) there is no working
> internal microphone under Linux. The board has no entry in the ACP70 DMI
> config quirk table in snd_acp_config, so it falls through to the generic
> acp-pdm-mach machine driver. That driver creates a capture device which
> opens and streams without error, but the data is not PCM audio.
>
> This differs from other reported ACP 7.0 machines (ASUS ROG Flow Z13, HP
> Omen 16-ap0xxx) where no PDM capture device is created at all. Here
> enumeration, board match and PCM open all succeed; only the data is wrong.
>
> Hardware
> --------
> DMI  sys_vendor      Acer
>      product_name    Nitro AN16S-61
>      product_family  Acer Nitro 16S AI
>      board_vendor    SXP
>      board_name      EV3_SKF
>      bios_version    V1.53  (03/06/2026)
>
> ACP (Audio Coprocessor)  1022:15e2 rev 70, subsystem 1025:1874
> HD Audio Controller      1022:15e3, subsystem 1025:1874
> Analog codec             Realtek ALC245 (10ec:0245), codec SSID 0x10251874
>
> There is no SoundWire codec on this board.
>
> Environment
> -----------
> Kernel          7.2.0-1-cachyos (x86_64)
> sof-firmware    2025.12.2
> linux-firmware  20260622
> alsa-ucm-conf   1.2.16.1
> Userspace       PipeWire/WirePlumber, default config
>
> Legacy ACP path is active; SOF is not bound (no /sys/kernel/debug/sof).
> snd_sof_amd_acp70 is loaded but users=0.
>
> Binding chain (all of this succeeds)
> ------------------------------------
>   snd_acp_pci  ->  PCI 0000:64:00.5
>   ACPI-based match via snd_amd_acpi_mach
>   ->  platform devices acp_asoc_acp70.0 and acp-pdm-mach
>
> Card longname is correctly derived from DMI:
>
>   SXP-NitroAN16S_61-V1.53-EV3_SKF
>
> The kernel log is silent on ACP apart from one line:
>
>   snd_acp_pci 0000:64:00.5: enabling device (0000 -> 0002)
>
> No probe errors or warnings. Card 3 registers zero ALSA controls --
> "amixer -c 3 controls" and "amixer -c 3 scontrols" both return nothing,
> so there is no PDM gain or enable control of any kind.
>
> Reproduce
> ---------
>   $ arecord -l
>   card 3: acppdmmach [acp-pdm-mach], device 0: DMIC capture dmic-hifi-0 []
>
>   $ arecord -D plughw:3,0 -f S32_LE -c 2 -r 48000 -d 3 /tmp/dmic.wav
>
> Then inspect the samples:
>
>   $ python3 -c "
>   import struct, collections
>   d = open('/tmp/dmic.wav','rb').read()[44:]
>   n = len(d)//4
>   s = struct.unpack('<%di' % n, d[:n*4])
>   c = collections.Counter(s)
>   print('samples', n, 'min', min(s), 'max', max(s), 'distinct', len(c))
>   print('first 16', s[:16])
>   "
>
> Actual result
> -------------
> A 3-second capture (288000 stereo S32_LE samples) contains only FOUR
> distinct sample values:
>
>   min = -2147483648, max = +2147483647, distinct = 4
>   287956 of 288000 samples (99.98%) are exactly INT_MIN
>
> The opening frames are a regular alternating pattern:
>
>   -2147483648, -2147483648, +2147483647, +2147483647, -2147483648, ...
>
> i.e. a full-scale square wave at Fs/2, which then collapses to a constant
> INT_MIN rail for the remainder of the capture. This looks like an
> undecimated/unconverted bitstream or DMA'd garbage rather than a
> microphone that is present but silent.
>
> hw:3,0 rejects S16_LE ("Sample format non available"); only S32_LE opens.
>
> Expected: real microphone audio.
>
> The HDA/ALC245 path does not provide the internal mic either
> ------------------------------------------------------------
> The ALC245 pin configuration declares two internal digital mic pins:
>
>   Node 0x12  Pin Default 0x90a60130  [Fixed] Mic at Int, Conn = Digital
>   Node 0x13  Pin Default 0x90a60140  [Fixed] Mic at Int, Conn = Digital
>
> Both are exposed as mutually-exclusive capture sources on the HDA card
> ("Internal Mic" and "Internal Mic 1"), and both default to off with the
> external jack "Mic" selected. Selecting each in turn and capturing:
>
>   Internal Mic   (0x12): all zeros, 1 distinct value
>   Internal Mic 1 (0x13): an opening full-scale transient that decays
>                          exponentially to zero and stays there
>
> Per-0.125s AC-RMS for 0x13 with Internal Mic Boost at maximum (+30 dB):
>
>   1884 906 435 209 100 48 23 11 5 2 1 2 0 0 0 0 0 0 0
>
> That is a filter/DC settling artifact at stream open, not audio. Capture
> volume was at maximum in both cases. So the internal mics are not merely
> deselected on the HDA codec; neither pin carries a working signal.
>
> For reference, the codec picks only a vendor-level fixup, not a
> board-specific one (this kernel is built without CONFIG_SND_DEBUG_VERBOSE,
> so the quirk name is stripped from the message):
>
>   snd_hda_codec_alc269 hdaudioC2D0: ALC245: picked fixup  for PCI SSID
>   1025:0000
>
> Already ruled out
> -----------------
> - Reproduces at raw ALSA (arecord), independent of PipeWire/WirePlumber.
>   No custom PipeWire/WirePlumber configuration is present.
>
> - Not a machine-match problem: the ACPI match succeeds, both platform
>   devices are created, and the DMI-derived card longname is correct.
>
> - Not UCM: alsa-ucm-conf ships a matching profile for this machine driver
>   (conf.d/acp-pdm-mach/acp-pdm-mach.conf), and the failure reproduces with
>   arecord on plughw directly, which does not go through UCM.
>
> - Not a muted or deselected input: capture gain was at maximum on both
>   cards, and both ALC245 internal-mic sources were explicitly selected
>   and tested.
>
> - Not a stale local override: the machine previously had an invalid
>   "options snd-hda-intel model=alc245-acer" in /etc/modprobe.d. That file
>   was removed and the machine rebooted; all results above are from a
>   stock configuration, and nothing changed.
>
> - Mic-mute hardware is inert under Linux here: KEY_MICMUTE (248) and
>   KEY_F20 (190) are both absent from the "Acer WMI hotkeys" capability
>   bitmap, and no micmute LED class device exists. The device does report
>   KEY_WLAN, KEY_PROG1 and KEY_TOUCHPAD_TOGGLE, so the hotkey path itself
>   works. (This missing keymap entry looks like a separate acer-wmi gap
>   worth fixing independently.) The EC's own power-on state is not visible
>   from the OS, so this is not a formal proof -- but a muted DMIC would
>   give clean zeros, not a full-scale Nyquist square.
>
> Suggested fix
> -------------
> The mechanism needed appears to exist in-tree already. The ASUS ProArt
> PX13 series ("ASoC: amd: acp: PX13 ACP70 config and machine quirks",
> March 2026, merged via for-7.0) added a DMI-keyed override in
> snd_acp_config that redirects ACP70 boards away from the generic PDM
> machine-driver fallback onto the correct path for that board. That table
> is present in the running kernel -- the ASUS board string is visible in
> the module:
>
>   zstdcat /lib/modules/7.2.0-1-cachyos/kernel/sound/soc/amd/snd-acp-config.ko.zst
> | strings | grep HN7306EA
>
> There is simply no entry for this Acer board, so it falls through to
> acp-pdm-mach, which is evidently not how its DMICs are wired.
>
> Request: add an ACP70 config quirk entry for the Acer Nitro AN16S-61
> (DMI product "Nitro AN16S-61", board "EV3_SKF", ACP subsystem 1025:1874).
>
> What that entry should select is the open question, and I do not have
> enough information to answer it. Unlike the PX13, this board has no
> SoundWire codec, and the two internal DMIC pins declared on the ALC245
> are both silent. So the DMICs appear to be on neither a working PDM
> instance nor the HDA codec as currently configured. Possibilities:
>
>   - a different PDM controller instance than the fallback selects;
>   - missing PDM clock / decimation-ratio / gain init for ACP 7.0 on this
>     board (card 3 registering zero ALSA controls may be a symptom);
>   - an ACPI/_DSD-declared endpoint configuration the current code does
>     not honour.
>
> I am happy to test patches, apply debug printks, dump ACP registers, or
> provide any further logs on request. alsa-info.sh output can be supplied
> or uploaded on request -- I did not upload it pre-emptively.
>
> Thanks for looking at this.

Re: [BUG] ASoC: amd: acp70: Acer Nitro AN16S-61 falls back to acp-pdm-mach, which streams invalid PCM (no working internal mic)

[Mukunda,Vijendar]

On 9/19/26 14:52, hazar sahmeran acikbas wrote:
> [You don't often get email from hazaracikbas@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Following up with one new data point that narrows this down.
>
> The internal microphone array works correctly under Windows on this same
> machine, with stock vendor drivers and no hardware or firmware changes
> between the two tests (same BIOS V1.53). So the DMICs are physically
> present and functional, and the EC is not holding them in a muted state.
>
> That rules out the two non-software explanations I could not exclude from
> Linux alone, and I think confirms this is purely a missing/incorrect
> configuration on the Linux side rather than a hardware or firmware fault.
>
> Still reproducing, unchanged, on newer kernels:
>
>    7.2.0-1-cachyos  (original report)
>    7.2.4-1-cachyos
>    7.2.6-1-cachyos  (current)
>
> with linux-firmware now at 20260916. The ACP70 DMI config quirk table in
> snd_acp_config continues to contain only the ASUS HN7306EA entry, and the
> capture behaviour is bit-for-bit what I described originally: the
> acp-pdm-mach capture device opens and streams a full-scale square wave at
> Fs/2 that collapses to an INT_MIN rail, and both internal DMIC pins
> declared on the ALC245 are silent at maximum gain.
>
> The open question from my original report stands: what a quirk entry for
> this board should actually select, given there is no SoundWire codec here
> and the ALC245's declared internal DMIC pins produce nothing.
>
> I am happy to run anything that would help answer that -- debug patches,
> printks in the ACP70 config/match path, ACP register dumps, ACPI table
> dumps (acpidump/iasl output for the ACP device's _DSD), or alsa-info.sh
> output. Just tell me what would be most useful and I will turn it around
> quickly.
++

Could you please log a bugzilla ticket including acpi dump, dmi decode
information along with alsa info output?

Thanks,
Vijendar
>
> Thanks,
> Hazar
>
> hazar sahmeran acikbas <hazaracikbas@gmail.com>, 29 Ağu 2026 Cmt,
> 23:35 tarihinde şunu yazdı:
>> Hello,
>>
>> On an Acer Nitro AN16S-61 (ACP 7.0, 1022:15e2 rev 70) there is no working
>> internal microphone under Linux. The board has no entry in the ACP70 DMI
>> config quirk table in snd_acp_config, so it falls through to the generic
>> acp-pdm-mach machine driver. That driver creates a capture device which
>> opens and streams without error, but the data is not PCM audio.
>>
>> This differs from other reported ACP 7.0 machines (ASUS ROG Flow Z13, HP
>> Omen 16-ap0xxx) where no PDM capture device is created at all. Here
>> enumeration, board match and PCM open all succeed; only the data is wrong.
>>
>> Hardware
>> --------
>> DMI  sys_vendor      Acer
>>       product_name    Nitro AN16S-61
>>       product_family  Acer Nitro 16S AI
>>       board_vendor    SXP
>>       board_name      EV3_SKF
>>       bios_version    V1.53  (03/06/2026)
>>
>> ACP (Audio Coprocessor)  1022:15e2 rev 70, subsystem 1025:1874
>> HD Audio Controller      1022:15e3, subsystem 1025:1874
>> Analog codec             Realtek ALC245 (10ec:0245), codec SSID 0x10251874
>>
>> There is no SoundWire codec on this board.
>>
>> Environment
>> -----------
>> Kernel          7.2.0-1-cachyos (x86_64)
>> sof-firmware    2025.12.2
>> linux-firmware  20260622
>> alsa-ucm-conf   1.2.16.1
>> Userspace       PipeWire/WirePlumber, default config
>>
>> Legacy ACP path is active; SOF is not bound (no /sys/kernel/debug/sof).
>> snd_sof_amd_acp70 is loaded but users=0.
>>
>> Binding chain (all of this succeeds)
>> ------------------------------------
>>    snd_acp_pci  ->  PCI 0000:64:00.5
>>    ACPI-based match via snd_amd_acpi_mach
>>    ->  platform devices acp_asoc_acp70.0 and acp-pdm-mach
>>
>> Card longname is correctly derived from DMI:
>>
>>    SXP-NitroAN16S_61-V1.53-EV3_SKF
>>
>> The kernel log is silent on ACP apart from one line:
>>
>>    snd_acp_pci 0000:64:00.5: enabling device (0000 -> 0002)
>>
>> No probe errors or warnings. Card 3 registers zero ALSA controls --
>> "amixer -c 3 controls" and "amixer -c 3 scontrols" both return nothing,
>> so there is no PDM gain or enable control of any kind.
>>
>> Reproduce
>> ---------
>>    $ arecord -l
>>    card 3: acppdmmach [acp-pdm-mach], device 0: DMIC capture dmic-hifi-0 []
>>
>>    $ arecord -D plughw:3,0 -f S32_LE -c 2 -r 48000 -d 3 /tmp/dmic.wav
>>
>> Then inspect the samples:
>>
>>    $ python3 -c "
>>    import struct, collections
>>    d = open('/tmp/dmic.wav','rb').read()[44:]
>>    n = len(d)//4
>>    s = struct.unpack('<%di' % n, d[:n*4])
>>    c = collections.Counter(s)
>>    print('samples', n, 'min', min(s), 'max', max(s), 'distinct', len(c))
>>    print('first 16', s[:16])
>>    "
>>
>> Actual result
>> -------------
>> A 3-second capture (288000 stereo S32_LE samples) contains only FOUR
>> distinct sample values:
>>
>>    min = -2147483648, max = +2147483647, distinct = 4
>>    287956 of 288000 samples (99.98%) are exactly INT_MIN
>>
>> The opening frames are a regular alternating pattern:
>>
>>    -2147483648, -2147483648, +2147483647, +2147483647, -2147483648, ...
>>
>> i.e. a full-scale square wave at Fs/2, which then collapses to a constant
>> INT_MIN rail for the remainder of the capture. This looks like an
>> undecimated/unconverted bitstream or DMA'd garbage rather than a
>> microphone that is present but silent.
>>
>> hw:3,0 rejects S16_LE ("Sample format non available"); only S32_LE opens.
>>
>> Expected: real microphone audio.
>>
>> The HDA/ALC245 path does not provide the internal mic either
>> ------------------------------------------------------------
>> The ALC245 pin configuration declares two internal digital mic pins:
>>
>>    Node 0x12  Pin Default 0x90a60130  [Fixed] Mic at Int, Conn = Digital
>>    Node 0x13  Pin Default 0x90a60140  [Fixed] Mic at Int, Conn = Digital
>>
>> Both are exposed as mutually-exclusive capture sources on the HDA card
>> ("Internal Mic" and "Internal Mic 1"), and both default to off with the
>> external jack "Mic" selected. Selecting each in turn and capturing:
>>
>>    Internal Mic   (0x12): all zeros, 1 distinct value
>>    Internal Mic 1 (0x13): an opening full-scale transient that decays
>>                           exponentially to zero and stays there
>>
>> Per-0.125s AC-RMS for 0x13 with Internal Mic Boost at maximum (+30 dB):
>>
>>    1884 906 435 209 100 48 23 11 5 2 1 2 0 0 0 0 0 0 0
>>
>> That is a filter/DC settling artifact at stream open, not audio. Capture
>> volume was at maximum in both cases. So the internal mics are not merely
>> deselected on the HDA codec; neither pin carries a working signal.
>>
>> For reference, the codec picks only a vendor-level fixup, not a
>> board-specific one (this kernel is built without CONFIG_SND_DEBUG_VERBOSE,
>> so the quirk name is stripped from the message):
>>
>>    snd_hda_codec_alc269 hdaudioC2D0: ALC245: picked fixup  for PCI SSID
>>    1025:0000
>>
>> Already ruled out
>> -----------------
>> - Reproduces at raw ALSA (arecord), independent of PipeWire/WirePlumber.
>>    No custom PipeWire/WirePlumber configuration is present.
>>
>> - Not a machine-match problem: the ACPI match succeeds, both platform
>>    devices are created, and the DMI-derived card longname is correct.
>>
>> - Not UCM: alsa-ucm-conf ships a matching profile for this machine driver
>>    (conf.d/acp-pdm-mach/acp-pdm-mach.conf), and the failure reproduces with
>>    arecord on plughw directly, which does not go through UCM.
>>
>> - Not a muted or deselected input: capture gain was at maximum on both
>>    cards, and both ALC245 internal-mic sources were explicitly selected
>>    and tested.
>>
>> - Not a stale local override: the machine previously had an invalid
>>    "options snd-hda-intel model=alc245-acer" in /etc/modprobe.d. That file
>>    was removed and the machine rebooted; all results above are from a
>>    stock configuration, and nothing changed.
>>
>> - Mic-mute hardware is inert under Linux here: KEY_MICMUTE (248) and
>>    KEY_F20 (190) are both absent from the "Acer WMI hotkeys" capability
>>    bitmap, and no micmute LED class device exists. The device does report
>>    KEY_WLAN, KEY_PROG1 and KEY_TOUCHPAD_TOGGLE, so the hotkey path itself
>>    works. (This missing keymap entry looks like a separate acer-wmi gap
>>    worth fixing independently.) The EC's own power-on state is not visible
>>    from the OS, so this is not a formal proof -- but a muted DMIC would
>>    give clean zeros, not a full-scale Nyquist square.
>>
>> Suggested fix
>> -------------
>> The mechanism needed appears to exist in-tree already. The ASUS ProArt
>> PX13 series ("ASoC: amd: acp: PX13 ACP70 config and machine quirks",
>> March 2026, merged via for-7.0) added a DMI-keyed override in
>> snd_acp_config that redirects ACP70 boards away from the generic PDM
>> machine-driver fallback onto the correct path for that board. That table
>> is present in the running kernel -- the ASUS board string is visible in
>> the module:
>>
>>    zstdcat /lib/modules/7.2.0-1-cachyos/kernel/sound/soc/amd/snd-acp-config.ko.zst
>> | strings | grep HN7306EA
>>
>> There is simply no entry for this Acer board, so it falls through to
>> acp-pdm-mach, which is evidently not how its DMICs are wired.
>>
>> Request: add an ACP70 config quirk entry for the Acer Nitro AN16S-61
>> (DMI product "Nitro AN16S-61", board "EV3_SKF", ACP subsystem 1025:1874).
>>
>> What that entry should select is the open question, and I do not have
>> enough information to answer it. Unlike the PX13, this board has no
>> SoundWire codec, and the two internal DMIC pins declared on the ALC245
>> are both silent. So the DMICs appear to be on neither a working PDM
>> instance nor the HDA codec as currently configured. Possibilities:
>>
>>    - a different PDM controller instance than the fallback selects;
>>    - missing PDM clock / decimation-ratio / gain init for ACP 7.0 on this
>>      board (card 3 registering zero ALSA controls may be a symptom);
>>    - an ACPI/_DSD-declared endpoint configuration the current code does
>>      not honour.
>>
>> I am happy to test patches, apply debug printks, dump ACP registers, or
>> provide any further logs on request. alsa-info.sh output can be supplied
>> or uploaded on request -- I did not upload it pre-emptively.
>>
>> Thanks for looking at this.