October 2026 - Alsa-devel - mailman.alsa-project.org

Re: [PATCH] ALSA: hda/conexant: Add quirk for Acer Aspire Go 16 mic mute LED
by Takashi Iwai 12 Oct '26

12 Oct '26

On Sun, 11 Oct 2026 13:37:09 +0200, Gonçalo Miranda wrote: > > The Acer Aspire Go 16 (AG16-71P) uses a Conexant SN6180 codec > (subsystem ID 0x1025:0x1937) with the microphone mute LED wired > to GPIO4. Add a quirk entry so the kernel drives the LED in sync > with the microphone mute state. > > The fixup reuses the existing cxt_setup_mute_led() helper with > mask 0x10, matching the behavior verified on the hardware. > > Signed-off-by: Gonçalo Miranda <me(a)goncalom.dev> > --- > sound/hda/codecs/conexant.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/sound/hda/codecs/conexant.c b/sound/hda/codecs/conexant.c > index 40da2832b..f66bae098 100644 > --- a/sound/hda/codecs/conexant.c > +++ b/sound/hda/codecs/conexant.c > @@ -283,6 +283,7 @@ enum { > CXT_FIXUP_HP_SPECTRE, > CXT_FIXUP_HP_GATE_MIC, > CXT_FIXUP_MUTE_LED_GPIO, > + CXT_FIXUP_ACER_ASPIRE_GO_MUTE_LED, > CXT_FIXUP_HP_ELITEONE_OUT_DIS, > CXT_FIXUP_HP_ZBOOK_MUTE_LED, > CXT_FIXUP_HEADSET_MIC, > @@ -786,6 +787,13 @@ static void cxt_fixup_hp_zbook_mute_led(struct hda_codec *codec, > cxt_setup_mute_led(codec, 0x10, 0x20); > } > > +static void cxt_fixup_acer_aspire_go_mute_led(struct hda_codec *codec, > + const struct hda_fixup *fix, int action) > +{ > + if (action == HDA_FIXUP_ACT_PRE_PROBE) > + cxt_setup_mute_led(codec, 0, 0x10); > +} > + > static void cxt_fixup_hp_a_u(struct hda_codec *codec, > const struct hda_fixup *fix, int action) > { > @@ -985,6 +993,10 @@ static const struct hda_fixup cxt_fixups[] = { > .type = HDA_FIXUP_FUNC, > .v.func = cxt_fixup_mute_led_gpio, > }, > + [CXT_FIXUP_ACER_ASPIRE_GO_MUTE_LED] = { > + .type = HDA_FIXUP_FUNC, > + .v.func = cxt_fixup_acer_aspire_go_mute_led, > + }, > [CXT_FIXUP_HP_ELITEONE_OUT_DIS] = { > .type = HDA_FIXUP_FUNC, > .v.func = cxt_fixup_update_pinctl, > @@ -1098,6 +1110,7 @@ static const struct hda_quirk cxt5066_fixups[] = { > SND_PCI_QUIRK(0x103c, 0x82b4, "HP ProDesk 600 G3", CXT_FIXUP_HP_MIC_NO_PRESENCE), > SND_PCI_QUIRK(0x103c, 0x836e, "HP ProBook 455 G5", CXT_FIXUP_MUTE_LED_GPIO), > SND_PCI_QUIRK(0x103c, 0x837f, "HP ProBook 470 G5", CXT_FIXUP_MUTE_LED_GPIO), > + SND_PCI_QUIRK(0x1025, 0x1937, "Acer Aspire Go 16", CXT_FIXUP_ACER_ASPIRE_GO_MUTE_LED), > SND_PCI_QUIRK(0x103c, 0x83b2, "HP EliteBook 840 G5", CXT_FIXUP_HP_DOCK), > SND_PCI_QUIRK(0x103c, 0x83b3, "HP EliteBook 830 G5", CXT_FIXUP_HP_DOCK), > SND_PCI_QUIRK(0x103c, 0x83d3, "HP ProBook 640 G4", CXT_FIXUP_HP_DOCK), The fixup table is sorted in PCI SSID order. Please put the new entry at the right position. Also, the correct place for the sound kernel patch submission is linux-sound ML (linux-sound(a)vger.kernel.org) instead of alsa-devel ML. The latter is only for user-space stuff now. Please resubmit to the former ML, instead. thanks, Takashi

1 0

ucm2: Qualcomm: add HP EliteBook support
by GitHub pull_request - opened 12 Oct '26

12 Oct '26

alsa-project/alsa-ucm-conf pull request #874 was opened from juergh: The EliteBook series is just a higher-end version of the OmniBook and compatible. Confirmed working on a EliteBook 6 G1q. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/874 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/874.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v2] ALSA: hda/tas2781: Enable bass speakers support
by Georg Wenzel 11 Oct '26

11 Oct '26

Configure the driver to correctly initialize and enable the bass speakers on devices utilizing the TAS2781 amplifier. Without this change, only the tweeters or main speakers are active, leading to thin audio output. Set up the required register sequences and routing to ensure the bass channels are properly powered and mixed into the audio stream. Signed-off-by: Georg Wenzel <g.wenzel(a)gmail.com> --- v2: - Rebased onto sound/for-next (Takashi Iwai). - Removed non-ASCII characters in comments (Takashi Iwai). include/sound/tas2781.h | 12 +++ .../hda/codecs/side-codecs/tas2781_hda_i2c.c | 98 +++++++++++++++++++ 2 files changed, 110 insertions(+) diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h index b763da613769..ccc0142fbad5 100644 --- a/include/sound/tas2781.h +++ b/include/sound/tas2781.h @@ -91,6 +91,18 @@ /* prm_TE_1_Beta1 */ #define TAS2563_TE_DT_REG TASDEVICE_REG(0x00, 0x0f, 0x70) +/* TAS2563 ASI (Audio Serial Interface) Register Definitions */ +#define TAS2563_ASI_CFG_REG TASDEVICE_REG(0x00, 0x00, 0x06) +#define TAS2563_ASI_SR_REG TASDEVICE_REG(0x00, 0x00, 0x07) +#define TAS2563_ASI_FS_REG TASDEVICE_REG(0x00, 0x00, 0x08) +#define TAS2563_ASI_DA_REG TASDEVICE_REG(0x00, 0x00, 0x0a) +#define TAS2563_ASI_TDM_REG TASDEVICE_REG(0x00, 0x00, 0x0b) +#define TAS2563_ASI_DL_REG TASDEVICE_REG(0x00, 0x00, 0x0c) +#define TAS2563_ASI_SLOT_REG TASDEVICE_REG(0x00, 0x00, 0x30) + +/* TAS2563 ASI Apply Register (triggers configuration update) */ +#define TAS2563_ASI_APPLY_REG TASDEVICE_REG(0x00, 0x00, 0x02) + #define TAS2781_PRM_INT_MASK_REG TASDEVICE_REG(0x00, 0x00, 0x3b) #define TAS2781_PRM_CLK_CFG_REG TASDEVICE_REG(0x00, 0x00, 0x5c) #define TAS2781_PRM_RSVD_REG TASDEVICE_REG(0x00, 0x01, 0x19) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index 5e5f46c9fb6b..cef33159eba4 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -46,6 +46,83 @@ #define TAS2563_CAL_TLIM TASDEVICE_REG(0, 0x10, 0x14) #define TAS2563_CAL_R0 TASDEVICE_REG(0, 0x0f, 0x34) +/* + * TAS2563 Post-Firmware ASI Configuration. + * + * The DSP firmware loading can overwrite the ASI (Audio Serial Interface) + * registers that configure the I2S/TDM audio path to the amplifier. + * This function re-applies the correct ASI configuration after firmware load, + * matching the reference initialization sequence used by the vendor script: + * - Software reset + * - ASI_CFG = 0x09 (I2S mode, master/slave config) + * - ASI_SR = 0x02 (sample rate divider for 48 kHz) + * - ASI_DA = 0xf1 (data alignment / slot assignment) + * - ASI_TDM = 0x02 (TDM mode select) + * - ASI_DL = 0x00 (delay line off) + * - ASI_SLOT = 0x99 (slot enable mask for 2-channel stereo) + * - CHNL_0 = 0x02 (channel mapping) + * - ASI_FS = 0x1e or 0x2e (frame sync, device-specific: bit4 selects + * which of the two devices is the "primary" for FS generation) + * - ASI_APPLY= 0x00 (trigger configuration update) + */ +static void tas2563_post_fw_init(struct tasdevice_priv *tas_priv) +{ + int i, ret; + + dev_info(tas_priv->dev, "%s: ndev=%d, chip_id=%d\n", + __func__, tas_priv->ndev, tas_priv->chip_id); + + for (i = 0; i < tas_priv->ndev; i++) { + struct tasdevice *tasdev = &tas_priv->tasdevice[i]; + u8 fs_val; + + dev_info(tas_priv->dev, + "%s: device[%d] dev_addr=0x%02x\n", + __func__, i, tasdev->dev_addr); + + /* Step 1: Software reset (matches script: 0x01 = 0x01) */ + ret = tasdevice_dev_write(tas_priv, i, TASDEVICE_REG_SWRESET, + TASDEVICE_REG_SWRESET_RESET); + dev_info(tas_priv->dev, + "%s: chn=%d SWRESET ret=%d\n", __func__, i, ret); + usleep_range(1000, 2000); + + /* Step 2: ASI configuration registers */ + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_CFG_REG, 0x09); + dev_info(tas_priv->dev, "%s: chn=%d ASI_CFG=0x09 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_SR_REG, 0x02); + dev_info(tas_priv->dev, "%s: chn=%d ASI_SR=0x02 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_DA_REG, 0xf1); + dev_info(tas_priv->dev, "%s: chn=%d ASI_DA=0xf1 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_TDM_REG, 0x02); + dev_info(tas_priv->dev, "%s: chn=%d ASI_TDM=0x02 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_DL_REG, 0x00); + dev_info(tas_priv->dev, "%s: chn=%d ASI_DL=0x00 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_SLOT_REG, 0x99); + dev_info(tas_priv->dev, "%s: chn=%d ASI_SLOT=0x99 ret=%d\n", __func__, i, ret); + + ret = tasdevice_dev_write(tas_priv, i, TAS2781_PRM_CHNL_0_REG, 0x02); + dev_info(tas_priv->dev, "%s: chn=%d CHNL_0=0x02 ret=%d\n", __func__, i, ret); + + /* Step 3: Device-specific frame sync (0x1e for dev0, 0x2e for dev1) */ + fs_val = 0x1e | ((i & 0x01) << 4); + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_FS_REG, fs_val); + dev_info(tas_priv->dev, "%s: chn=%d ASI_FS=0x%02x ret=%d\n", + __func__, i, fs_val, ret); + + /* Step 4: Apply ASI configuration */ + ret = tasdevice_dev_write(tas_priv, i, TAS2563_ASI_APPLY_REG, 0x00); + dev_info(tas_priv->dev, "%s: chn=%d ASI_APPLY ret=%d\n", __func__, i, ret); + + usleep_range(1000, 2000); + } +} + enum device_chip_id { HDA_TAS2563, HDA_TAS2770, @@ -172,6 +249,13 @@ static void tas2781_hda_playback_hook(struct device *dev, int action) pm_runtime_get_sync(dev); scoped_guard(mutex, &tas_hda->priv->codec_lock) { tasdevice_tuning_switch(tas_hda->priv, 0, false); + /* Re-apply ASI configuration for TAS2563 after + * tuning switch - DSP firmware loading can + * overwrite ASI registers. + */ + if (tas_hda->priv->chip_id == TAS2563) + tas2563_post_fw_init(tas_hda->priv); + tas_hda->priv->playback_started = true; } break; @@ -475,6 +559,12 @@ static void tasdevice_dspfw_init(void *context) tas_priv->rcabin.init_profile_id, TASDEVICE_BIN_BLK_PRE_POWER_UP); + /* Apply ASI configuration for TAS2563 after firmware load. + * DSP firmware loading can overwrite ASI registers. + */ + if (tas_hda->priv->chip_id == TAS2563) + tas2563_post_fw_init(tas_hda->priv); + /* If calibrated data occurs error, dsp will still works with default * calibrated data inside algo. */ @@ -659,6 +749,7 @@ static int tas2781_hda_i2c_probe(struct i2c_client *clt) */ device_name = "INT8866"; hda_priv->hda_chip_id = HDA_TAS2563; + tas_hda->priv->chip_id = TAS2563; hda_priv->save_calibration = tas2563_save_calibration; tas_hda->priv->global_addr = TAS2563_GLOBAL_ADDR; } else if (strstarts(dev_name(&clt->dev), "i2c-TXNW5825")) { @@ -782,6 +873,13 @@ static int tas2781_system_resume(struct device *dev) tas_hda->priv->rcabin.init_profile_id, TASDEVICE_BIN_BLK_PRE_POWER_UP); + /* Re-apply ASI configuration for TAS2563 after system sleep + * resume — amplifiers may lose their register state during + * suspend-to-ram or suspend-to-disk regardless of playback state. + */ + if (tas_hda->priv->chip_id == TAS2563) + tas2563_post_fw_init(tas_hda->priv); + if (tas_hda->priv->playback_started) tasdevice_tuning_switch(tas_hda->priv, 0, false); -- 2.55.0

3 2

Help - help: unsubscribe
by richardh＠tuta.io 11 Oct '26

11 Oct '26

Hi Please unsubscribe richardh(a)tuta.io from your mailing list. Many thanks Richard -- Secured with Tuta Mail: https://tuta.com/free-email 11 Oct 2026, 08:15 by alsa-devel-request(a)alsa-project.org: > Send Alsa-devel mailing list submissions to > alsa-devel(a)alsa-project.org > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > alsa-devel-request(a)alsa-project.org > > You can reach the person managing the list at > alsa-devel-owner(a)alsa-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Alsa-devel digest..."Today's Topics: > > 1. ALSA: hda/realtek: LG Gram 16T90SP (ALC298 + ALC1318, SSID 1854:0521) - no speaker output, need amp init sequence > (Cory Mattson) > 2. Backport request for 7.0.y and 7.1.y: 6485da8579e2 (ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk) > (Eli D) > 3. [PATCH] ALSA: hda/realtek: Fix internal mic capture on ASUS ROG Flow Z13 GZ302EA > (Alex James) > 4. ucm2: MediaTek: add mt8189-rt1019p-rt5682s (skywalker Chromebooks) > (GitHub pull_request - opened) > _______________________________________________ > Alsa-devel mailing list -- alsa-devel(a)alsa-project.org > To unsubscribe send an email to alsa-devel-leave(a)alsa-project.org >

1 0

ucm2: MediaTek: add mt8189-rt1019p-rt5682s (skywalker Chromebooks)
by GitHub pull_request - opened 11 Oct '26

11 Oct '26

alsa-project/alsa-ucm-conf pull request #872 was opened from zoan37: Adds a UCM profile for MT8189 (Kompanio 540) Chromebooks with RT1019P speaker amps and an RT5682S headset codec (card `mt8189_1019_rt5682s`, the "skywalker" family; tested on quigon, the Lenovo IdeaPad Slim 3 Chromebook). - Speaker, headphones, internal DMIC and headset mic. - All DPCM front ends are routed in the BootSequence: PipeWire's ACP opens every PCM while it probes the profile, and these front ends refuse hw_params until they're routed to a back end (routing them in the devices' EnableSequence made ACP drop the whole profile). - HDMI (`hw:CardId,6`, through an HDMI bridge on PCM 0) and DisplayPort over USB-C (`hw:CardId,5`, via the `TDM Playback Route` demux) are only added when the machine driver created their jacks, the same pattern as the recent mt8391-evk DisplayPort change. Tested with linux-next plus the posted MT8189 series (the board DTS isn't upstream yet): speaker, headphones, both mics, HDMI and USB-C DisplayPort audio, starting from cleared mixer routes and across reboots. `alsa-info.sh` output for the UCM validator: https://gist.github.com/zoan37/b611da4f1e569613f176c33edbe34a01 The profile was written with help from an AI assistant (Claude); I tested it on the hardware and reviewed it. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/872 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/872.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[Suggestion] Impliment an anti-AI policy?
by GitHub issues - edited 10 Oct '26

10 Oct '26

alsa-project/alsa-lib issue #530 was edited from cloudskater: Hi! I wanted to ask about the possibility of banning AI use from ALSA's codebase due to a myriad of issues it creates, within the FOSS space and far beyond it. Such problems are inherent to modern-day "AI" and its only continuing to damage the people around us and the world in which we all live. As someone who uses Linux and ALSA almost every day, it would be very reassuring to see such an essential pillar of Linux audio take a firm stance against this harmful tech with continually worsening consequences. Those consequences include: ## Environmental Impact To start learning a bit more, you can check out the Wikipedia page on the [environmental impact of artificial intelligence](https://en.wikipedia.org/wiki/Environmental_impact_of_artific…. Here's some more specific sources: - [MIT News: Generative AI's environmental impact](https://news.mit.edu/2025/explained-generative-ai-environmental-imp… - [MIT Technology Review: We did the math on AI's energy footprint. Here's the story you haven't heard.](https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage… ## Effect on Hardware Prices The demand for construction and outfitting of new data-centers to host AI/LLM compute capacity has overwhelmed global supply and production of multiple hardware components. Memory, Storage, and GPUs have seen massive increases in price for both consumer and enterprise models, upwards of 400% in some cases. The lack of supply has led large system-builders to purchase production capacity from OEMs well in advance of delivery, leading some manufacturers to end consumer-oriented product lines in favor of enterprise capacity. The downstream effects for consumers is that nearly all electronic devices which contain memory and storage will see their prices rise and availability decline. Those who already own existing electronics and computer hardware components may also find themselves unable to have their devices repaired or replaced under warranty. - [The RAM shortage is coming for everything you care about](https://www.theverge.com/tech/880812/ramageddon-ram-shortage-memory-… - [Western Digital is already sold out of hard drives for all of 2026 — chief says some long-term agreements for 2027 and 2028 already in place](https://www.tomshardware.com/pc-components/hdds/western-digital-is-a… - [The 2026 storage crisis: Why AI data centers are hoarding every hard drive on the market](https://www.howtogeek.com/dont-count-on-hdds-to-save-you-from-risin… This has resulted in pricing historically marginalized individuals, who are more likely to have less financial resources, out of learning about computers at home and shrinking the diversity of the computing and programming industry. ## Ties to the War Industry A lot of AI companies also work directly with nation states for use in their War Departments, which in turn leads to further AI usage during war and invasions. This is coupled with [NYT: Palantir, Anthropic and small start-ups are generating rewards from their investments in defense tech](https://www.nytimes.com/2026/03/18/technology/silicon-valley-war-defe…. As another example [NPR: OpenAI announced Pentagon deal after Trump banned Anthropic](https://www.npr.org/2026/02/27/nx-s1-5729118/trump-anthropic-pen… which was due to the USA Department of War [launching an AI acceleration strategy](https://web.archive.org/web/20260113071131/https://www.war.gov/Ne…. Due to the nature of LLMs being only kind of as good as the data they are trained on, this can lead to additional civilian deaths and housing/infrastructure damage either intentionally or not. Examples: <details> <summary>Content Warning: War details, death</summary> - [Gaza: UN experts deplore use of purported AI to commit ‘domicide’ in Gaza, call for reparative approach to rebuilding](https://www.ohchr.org/en/press-releases/2024/04/gaza-un-experts… - [Lavender & Where’s Daddy: How Israel Used AI to Form Kill Lists & Bomb Palestinians in Their Homes](https://www.democracynow.org/2024/4/5/israel_ai) - [Microsoft says it provided AI to Israeli military for war](https://apnews.com/article/microsoft-israel-military-gaza-hamas-artifi… - [Google has dropped its promise not to use AI for weapons](https://theconversation.com/google-has-dropped-its-promise-not-to-… - ["We want to use it for everything": How Project Maven became central to America’s AI-powered warfare](https://web.archive.org/web/20260312035736/https://www.independent… </details> ## What You Can Do I'd like to kindly suggest implementing a strict "No AI" policy. This can also help with what seems to be larger and larger influxes of low quality drive-by PRs by AI agents. You can find other projects that have taken steps to say no to AI here: https://noai.starlightnet.work/list.html For a specific policy, I can recommend the following policies for inspiration: - [wafrn's Contributring Doc](https://codeberg.org/wafrn/wafrn/src/branch/main/CONTRIBUTING.md) - [Loupe's Use of Generative AI Policy](https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-… Thank you for reading. I really appreciate it and hope that we can build a more humane and thoughtful future for FOSS together. Kind regards, cloudskater Issue URL : https://github.com/alsa-project/alsa-lib/issues/530 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

ucm2: Intel: avs: Add UCM for renamed AVS HD-Audio, DMIC and HDMI
by GitHub pull_request - opened 10 Oct '26

10 Oct '26

alsa-project/alsa-ucm-conf pull request #871 was opened from archerallstars: Add UCM for the renamed Intel AVS cards so PipeWire ACP can load HiFi on Kaby Lake machines that no longer use the old `hdaudioB0D2` / DMI long names. ## Hardware (live-tested) | | | | --- | --- | | Machine | Acer Swift SF514-52T (DMI `Carlsberg_KL`) | | CPU | Intel Core i5-8250U (Kaby Lake-U) | | PCI audio | `8086:9d71` subsystem `1025:1225` | | Codec | Realtek ALC255 (`0x10ec0255` / `0x10251225`) | | HDMI codec | Intel Kabylake HDMI (`0x8086280b`) | | Driver | `snd_soc_avs` (default `dsp_driver=0`) | | Kernel | `7.2.9-200.fc44.x86_64` (Fedora Silverblue 44) | ``` 0 [DMIC ]: avs_dmic - AVS DMIC 1 [PROBE ]: avs_probe_mb - AVS PROBE 2 [HDAudio ]: avs_hdaudio - AVS HD-Audio 3 [HDMI ]: avs_hdaudio - AVS HDMI ``` Playback: `hw:HDAudio,0` (analog), `hw:HDMI,0/1/2` (HDMI1/2/3). Capture: `hw:DMIC,0` (internal array), `hw:HDAudio,0` (analog headset). ## What this adds Lookups: - `ucm2/conf.d/avs_hdaudio/AVS HD-Audio.conf` - `ucm2/conf.d/avs_hdaudio/AVS HDMI.conf` - `ucm2/conf.d/avs_dmic/AVS DMIC.conf` Profiles: - **AVS HD-Audio** — `HDA/HiFi-analog.conf` for Speaker / Headphones. Extra `Headset` device on `pcm0c` when `Front Headphone Jack` exists. Analog capture has no `Capture Switch` on this BIOS (mic pins left N/A); topology still exposes `HDAudio Analog`. Format is 24-bit left-justified in `S32_LE`. - **AVS DMIC** — PCM device 0 (after the card rename), `CaptureChannels 2`, `CaptureRate 48000`, `cset 'DMIC Volume' 100%` (the control boots at 0 / digital silence). - **AVS HDMI** — three converters, `Number` 1/2/3 with `Device` 0/1/2. `codecs/hda/hdmi.conf` programs `IEC958 Playback Switch` at `index = Number - 1`, so `Number` is 1-based. `Number 0` yields index `-1`. Jack names on this SKU are `HDMI/DP Jack`, `HDMI/DP,pcm=1 Jack`, `HDMI/DP,pcm=2 Jack`. Old `hdaudioB0D2` / `DMIC-2ch` / DMI long-name files are left in place. ## Proven on this chassis | Path | Result | | --- | --- | | Internal speakers | playback works | | 3.5 mm 2-ring headphones | playback works | | 3.5 mm 3-ring CTIA headset mic | capture works on **Headset Microphone** | | Internal AVS DMIC | capture works | | HDMI / DisplayPort | playback works | A 2-ring analog **microphone** on this combo jack is not compatible (pin `0x21` is OUT-only / `NO_HP_MIC`; the same plug is also silent on a Galaxy A25). Analog headset **pins** still need a kernel quirk or userspace HDA hwdep verbs. AVS logs PCI SSID `1025:0000`, so `ALC255_FIXUP_ACER_HEADSET_MIC` never runs. This PR only binds the analog capture PCM and jack. The out-of-tree layer that programs CTIA (`0x45=0xd489`) and pin `0x19` IN+VREF_80 lives in https://github.com/archerallstars/acer-swift-sf514-52t (`scripts-audio-fix`). WirePlumber capture `Mult` boosts are also out of scope here. ## Relation to #571 [#571](https://github.com/alsa-project/alsa-ucm-conf/pull/571) is the generic Intel AVS renamed-card set (including I2S codecs). This PR is the HD-Audio + DMIC + HDMI subset that is live on ALC255, with three deltas from that branch: 1. HDMI `Number` is 1-based (`1/2/3` with `Device` `0/1/2`). #571 uses `Number 0` for PCM 0. 2. DMIC sets `CaptureChannels 2`. ACP assumes stereo when the count is omitted and fails with `EINVAL` on a 4-channel array ([comment on #571](https://github.com/alsa-project/alsa-ucm-conf/pull/571#issuecomment-5608938568)). This NHLT is stereo. 3. Headset analog capture device, because `HiFi-mic.conf` is skipped without `Capture Switch`. This PR does not add the I2S codec UCMs from #571. The kernel still exposes three cards. PipeWire ACP profiles each card. A combined/linked UCM (one logical onboard device) is the open design point on #571; these files match the split that works with current ACP on this laptop. ## References - https://bugzilla.kernel.org/show_bug.cgi?id=219654 - https://bugzilla.suse.com/show_bug.cgi?id=1213187 (3-ring CTIA headset mic on this codec under `snd-hda-intel`) - Full `alsa-info.sh` dump follows in a comment for the UCM validator. Signed-off-by: Archer Allstars <archerallstars(a)proton.me> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/871 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/871.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Backport request for 7.0.y and 7.1.y: 6485da8579e2 (ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk)
by Eli D 10 Oct '26

10 Oct '26

Hello, I would like to request a backport of the mainline commit 6485da8579e2 ALSA: hda: Add Lenovo Legion 7i 16IAX7 17AA3874 quirk into the 7.0.y and 7.1.y stable series. Why it qualifies. The commit adds a device ID and a quirk entry for a machine whose built-in speakers are completely silent without it. Per the stable rules this falls under both accepted categories: it fixes a real user-visible problem, and it merely adds a device ID. The change is three added lines across two files, touches only static quirk and property tables, and cannot affect other hardware. The problem. On Lenovo Legion 7 16IAX7 with Realtek ALC287 codec SSID 17aa:3874 and CSC3551/CS35L41 speaker amps, cs35l41-hda fails to probe the amps: Failed property cirrus,dev-index: -22 error -EINVAL: Platform not supported and the Realtek codec never selects ALC287_FIXUP_CS35L41_I2C_2 for that SSID, so the amps are not linked to the speaker output and the built-in speakers stay silent. Headphones are unaffected, which makes it easy to miss. Testing. I reproduced and verified the fix on a Lenovo Legion 7 16IAX7 (board 82TD), ALC287 SSID 17aa:3874, PCI SSID 17aa:382b, two CS35L41 amps, running a 7.0-series Ubuntu kernel. After applying the change both amps probe and bind, firmware loads, the dev-index error disappears and speaker playback works. The commit is first present in v7.2, so 7.0.y and 7.1.y do not have it. It has no Cc: stable tag, hence this request. There are no prerequisites; the patch applies on its own. For reference, sibling Legion quirks in the same code path were Cc'd to stable, for example d35dfb6329ac (ALSA: hda/realtek: Fix speakers on Legion Pro 7 16ARX8H with codec SSID 17aa:38a7). If you prefer an explicit patch submission rather than a pickup request, I can send one. References: commit: https://github.com/torvalds/linux/commit/6485da8579e2b0132630faa1ee2ac72cca… thread: https://patch.msgid.link/20260622172247.19301-1-kamleshkc2002@gmail.com kernel bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=221663 Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2157060 Thanks, Eli D info(a)16bc.ru

1 0

[PATCH] ALSA: hda/realtek: Fix internal mic capture on ASUS ROG Flow Z13 GZ302EA
by Alex James 10 Oct '26

10 Oct '26

The ASUS ROG Flow Z13 GZ302EA (Realtek ALC294, SSID 1043:1fb3) exposes two fixed internal mic pins, 0x12 (0x90a60140) and 0x13 (0x90a60130), as capture sources "Internal Mic" and "Internal Mic 1". The input mux defaults to 0x12, but on this model 0x12 is defective: its right channel rails to -32768 and the left channel carries heavy noise, so out of the box the internal microphone records loud noise/hum. Pin 0x13 captures clean audio on both channels (at lower level). The mic array is not reachable through the AMD ACP70/PDM path either: forcing it on via ACPI _WOV=1 creates the dmic-codec device but all samples rail at -32768, so HDA is the only usable capture path. The existing quirk for this SSID only initializes the two CS35L41 I2C smart amps (speakers). Disable the broken 0x12 pin via pincfg so that 0x13 becomes the sole "Internal Mic" capture source, and keep the CS35L41 initialization by chaining it in a new fixup. Measured on a GZ302EA (arecord, 48 kHz S16LE, identical gain): pin 0x12: L 47% clipped samples, R 15% clipped (railed noise) pin 0x13: <0.3% clipped, hum components below -65 dBFS The fix was validated on the target hardware without building a kernel by applying the same pincfg override (0x12 -> 0x40000000) through a boot-time HDA patch firmware (snd-hda-intel patch=). With the override the codec parser drops pin 0x12 entirely: the card comes up with a single "Internal Mic" (0x13), the Capture Source mux control disappears (single input is hardwired), and capture is clean and stable across boot, suspend/resume, and PipeWire/WirePlumber route re-applies. Note that a runtime hda-verb override alone is not sufficient because the bus driver builds its pin cache at codec registration. Also observed on this SSID while testing: repeated "ALC294: Invalid fixup type 2016568172" messages in dmesg during probe with the current quirk; likely unrelated but worth a look. Link: https://github.com/CachyOS/linux-cachyos/issues/880 Tested-by: aic0d3r <funforfreeapps(a)gmail.com> Signed-off-by: aic0d3r <funforfreeapps(a)gmail.com> --- sound/hda/codecs/realtek/alc269.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index be54825..20b5c82 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -4219,6 +4219,8 @@ enum { ALC294_FIXUP_ASUS_ALLY, ALC294_FIXUP_ASUS_ALLY_PINS, ALC294_FIXUP_ASUS_ALLY_VERBS, + ALC294_FIXUP_ASUS_GZ302EA, + ALC294_FIXUP_ASUS_GZ302EA_PINS, ALC294_FIXUP_ASUS_HPE, ALC294_FIXUP_ASUS_COEF_1B, ALC294_FIXUP_ASUS_GX502_HP, @@ -5889,6 +5891,19 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC285_FIXUP_THINKPAD_X1_GEN7 }, + [ALC294_FIXUP_ASUS_GZ302EA] = { + .type = HDA_FIXUP_FUNC, + .v.func = cs35l41_fixup_i2c_two, + .chained = true, + .chain_id = ALC294_FIXUP_ASUS_GZ302EA_PINS + }, + [ALC294_FIXUP_ASUS_GZ302EA_PINS] = { + .type = HDA_FIXUP_PINS, + .v.pins = (const struct hda_pintbl[]) { + { 0x12, 0x40000000 }, + { } + }, + }, [ALC294_FIXUP_ASUS_HPE] = { .type = HDA_FIXUP_VERBS, .v.verbs = (const struct hda_verb[]) { @@ -7937,7 +7952,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1f62, "ASUS UX7602ZM", ALC245_FIXUP_CS35L41_SPI_2), SND_PCI_QUIRK(0x1043, 0x1f63, "ASUS P5405CSA", ALC245_FIXUP_CS35L41_SPI_2), SND_PCI_QUIRK(0x1043, 0x1f92, "ASUS ROG Flow X16", ALC289_FIXUP_ASUS_GA401), - SND_PCI_QUIRK(0x1043, 0x1fb3, "ASUS ROG Flow Z13 GZ302EA", ALC287_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x1043, 0x1fb3, "ASUS ROG Flow Z13 GZ302EA", ALC294_FIXUP_ASUS_GZ302EA), SND_PCI_QUIRK(0x1043, 0x3011, "ASUS B5605CVA", ALC245_FIXUP_CS35L41_SPI_2), SND_PCI_QUIRK(0x1043, 0x3030, "ASUS ZN270IE", ALC256_FIXUP_ASUS_AIO_GPIO2), SND_PCI_QUIRK(0x1043, 0x3061, "ASUS B3405CCA", ALC294_FIXUP_ASUS_CS35L41_SPI_2),

1 0

[Suggestion] Impliment an anti-AI policy?
by GitHub issues - opened 10 Oct '26

10 Oct '26

alsa-project/alsa-lib issue #530 was opened from cloudskater: Hi! I wanted to ask about the possibility of banning AI use from ALSA's codebase due to a myriad of issues it creates, withing the FOSS space and far beyond it. Such problems are inherent to modern-day "AI" and its only continuing to damage the people around us and the world in which we all live. As someone who uses Linux and ALSA almost every day, it would be very reassuring to see such an essential pillar of Linux audio take a firm stance against this harmful tech with continually worsening consequences. Those consequences include: ## Environmental Impact To start learning a bit more, you can check out the Wikipedia page on the [environmental impact of artificial intelligence](https://en.wikipedia.org/wiki/Environmental_impact_of_artific…. Here's some more specific sources: - [MIT News: Generative AI's environmental impact](https://news.mit.edu/2025/explained-generative-ai-environmental-imp… - [MIT Technology Review: We did the math on AI's energy footprint. Here's the story you haven't heard.](https://www.technologyreview.com/2025/05/20/1116327/ai-energy-usage… ## Effect on Hardware Prices The demand for construction and outfitting of new data-centers to host AI/LLM compute capacity has overwhelmed global supply and production of multiple hardware components. Memory, Storage, and GPUs have seen massive increases in price for both consumer and enterprise models, upwards of 400% in some cases. The lack of supply has led large system-builders to purchase production capacity from OEMs well in advance of delivery, leading some manufacturers to end consumer-oriented product lines in favor of enterprise capacity. The downstream effects for consumers is that nearly all electronic devices which contain memory and storage will see their prices rise and availability decline. Those who already own existing electronics and computer hardware components may also find themselves unable to have their devices repaired or replaced under warranty. - [The RAM shortage is coming for everything you care about](https://www.theverge.com/tech/880812/ramageddon-ram-shortage-memory-… - [Western Digital is already sold out of hard drives for all of 2026 — chief says some long-term agreements for 2027 and 2028 already in place](https://www.tomshardware.com/pc-components/hdds/western-digital-is-a… - [The 2026 storage crisis: Why AI data centers are hoarding every hard drive on the market](https://www.howtogeek.com/dont-count-on-hdds-to-save-you-from-risin… This has resulted in pricing historically marginalized individuals, who are more likely to have less financial resources, out of learning about computers at home and shrinking the diversity of the computing and programming industry. ## Ties to the War Industry A lot of AI companies also work directly with nation states for use in their War Departments, which in turn leads to further AI usage during war and invasions. This is coupled with [NYT: Palantir, Anthropic and small start-ups are generating rewards from their investments in defense tech](https://www.nytimes.com/2026/03/18/technology/silicon-valley-war-defe…. As another example [NPR: OpenAI announced Pentagon deal after Trump banned Anthropic](https://www.npr.org/2026/02/27/nx-s1-5729118/trump-anthropic-pen… which was due to the USA Department of War [launching an AI acceleration strategy](https://web.archive.org/web/20260113071131/https://www.war.gov/Ne…. Due to the nature of LLMs being only kind of as good as the data they are trained on, this can lead to additional civilian deaths and housing/infrastructure damage either intentionally or not. Examples: <details> <summary>Content Warning: War details, death</summary> - [Gaza: UN experts deplore use of purported AI to commit ‘domicide’ in Gaza, call for reparative approach to rebuilding](https://www.ohchr.org/en/press-releases/2024/04/gaza-un-experts… - [Lavender & Where’s Daddy: How Israel Used AI to Form Kill Lists & Bomb Palestinians in Their Homes](https://www.democracynow.org/2024/4/5/israel_ai) - [Microsoft says it provided AI to Israeli military for war](https://apnews.com/article/microsoft-israel-military-gaza-hamas-artifi… - [Google has dropped its promise not to use AI for weapons](https://theconversation.com/google-has-dropped-its-promise-not-to-… - ["We want to use it for everything": How Project Maven became central to America’s AI-powered warfare](https://web.archive.org/web/20260312035736/https://www.independent… </details> ## What You Can Do I'd like to kindly suggest implementing a strict "No AI" policy. This can also help with what seems to be larger and larger influxes of low quality drive-by PRs by AI agents. You can find other projects that have taken steps to say no to AI here: https://noai.starlightnet.work/list.html For a specific policy, I can recommend the following policies for inspiration: - [wafrn's Contributring Doc](https://codeberg.org/wafrn/wafrn/src/branch/main/CONTRIBUTING.md) - [Loupe's Use of Generative AI Policy](https://discourse.gnome.org/t/loupe-no-longer-allows-generative-ai-… Thank you for reading. I really appreciate it and hope that we can build a more humane and thoughtful future for FOSS together. Kind regards, cloudskater Issue URL : https://github.com/alsa-project/alsa-lib/issues/530 Repository URL: https://github.com/alsa-project/alsa-lib

1 0