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

Re: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
by Krzysztof Kozlowski 15 Jun '26

15 Jun '26

On 15/06/2026 12:14, Zhang Yi wrote: >>>>> Yes, setting mclk-from-sclk does not affect the MCLK connection. >>>> >>>> I am asking about wiring of the device. If MCLK is used from SCLK, but >>>> SCLK is used as the internal clock, then how can you still have MCLK >>>> connected? >>> >>> If MCLK is derived from SCLK, whether the 'MCLK' pin on the device is >>> connected or not has no effect on operation. >> >> If MCLK is connected, why would you derive it from SCLK? That's the >> point - your clocks property already might be telling everything needed >> here. > > This is because sometimes the codec does not work properly > when using the MCLK provided by the CPU. OK. > >>>>>>> + >>>>>>> + everest,hpfl: >>>>>>> + $ref: /schemas/types.yaml#/definitions/uint8 >>>>>>> + description: >>>>>>> + the HPF value of ADCL. >>>>>> >>>>>> Is HPF value in dB? If so, use proper unit suffix and proper units. >>>>> >>>>> No, the values here correspond to the values in the registers. >>>>> The value is not in dB >>>> >>>> What are the meanings of the register values? >>> >>> The value of everest,hpfl is equal to the value of the corresponding register, >>> not the cutoff frequency of the HPF. >> >> You keep avoiding answers. >> >> I don't want you to encode standard units as register values. > > I think I understand what you mean. > Do you want me to enter the physical values in DTS and then convert them to register values in the code? If you have clear physical values then this should be rather used in DTS. Best regards, Krzysztof

1 0

Re: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
by Krzysztof Kozlowski 15 Jun '26

15 Jun '26

On 15/06/2026 08:07, Zhang Yi wrote: >>>>> + $ref: /schemas/types.yaml#/definitions/flag >>>>> + description: >>>>> + Indicates that SCLK is used as the internal clock. >>>> >>>> And what happens with mclk in such case? Is it still wired? >>> >>> Yes, setting mclk-from-sclk does not affect the MCLK connection. >> >> I am asking about wiring of the device. If MCLK is used from SCLK, but >> SCLK is used as the internal clock, then how can you still have MCLK >> connected? > > If MCLK is derived from SCLK, whether the 'MCLK' pin on the device is > connected or not has no effect on operation. If MCLK is connected, why would you derive it from SCLK? That's the point - your clocks property already might be telling everything needed here. > >>>>> + >>>>> + everest,hpfl: >>>>> + $ref: /schemas/types.yaml#/definitions/uint8 >>>>> + description: >>>>> + the HPF value of ADCL. >>>> >>>> Is HPF value in dB? If so, use proper unit suffix and proper units. >>> >>> No, the values here correspond to the values in the registers. >>> The value is not in dB >> >> What are the meanings of the register values? > > The value of everest,hpfl is equal to the value of the corresponding register, > not the cutoff frequency of the HPF. You keep avoiding answers. I don't want you to encode standard units as register values. Best regards, Krzysztof

1 0

[PATCH RFC] ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT
by Ripeer 15 Jun '26

15 Jun '26

From: ripeeerr(a)gmail.com ALSA: hda/realtek: Add quirk for Lenovo Xiaoxin 14 GT The Lenovo Xiaoxin 14 GT (Chinese market model, AMD Ryzen AI 9 365) produces constant electrical hissing and crackling noise from both internal speakers and 3.5mm headphone jack during audio playback. Audio works correctly on Windows. The noise is louder than the audio itself and is present on all tested distributions (Arch Linux, Fedora 44, kernels 6.12 and 7.0-zen). The PCI SSID 17aa:3912 is not present in the quirk list. Additionally, in some configurations the BIOS reports the SSID as 17aa:0000, causing the kernel to apply no fixup at all: snd_hda_codec_alc269 hdaudioC1D0: ALC287: picked fixup for PCI SSID 17aa:0000 Codec info (/proc/asound/card1/codec#0): Codec: Realtek ALC287 Vendor Id: 0x10ec0287 Subsystem Id: 0x17aa3912 Revision Id: 0x100002 Audio devices: c2:00.1 AMD/ATI Radeon HD Audio [1002:1640] c2:00.5 AMD Audio Coprocessor [1022:15e2] c2:00.6 AMD Ryzen HD Audio Controller [1022:15e3] GPIO state (all zeros, amplifier appears uninitialized): IO[0-4]: enable=0, dir=0, data=0 The proposed fixup ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN is chosen by analogy with neighboring Lenovo 14" AMD models (17aa:3911, 17aa:390d) that use the same fixup. However, this has NOT been verified by testing a compiled kernel — I do not currently have a working Linux installation on this machine. Guidance from maintainers on the correct fixup is very welcome. Signed-off-by: ripeeerr(a)gmail.com --- sound/hda/codecs/realtek/alc269.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index dcbc66984..0d8f157c9 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -7774,6 +7774,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x17aa, 0x390d, "Lenovo Yoga Pro 7 14ASP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), SND_PCI_QUIRK(0x17aa, 0x3911, "Lenovo Yoga Pro 7 14IAH10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), + SND_PCI_QUIRK(0x17aa, 0x3912, "Lenovo Xiaoxin 14 GT", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN), SND_PCI_QUIRK(0x17aa, 0x3913, "Lenovo 145", ALC236_FIXUP_LENOVO_INV_DMIC), SND_PCI_QUIRK(0x17aa, 0x391a, "Lenovo Yoga Slim 7 14AKP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),

2 1

conf: fix snd_func_imul accumulator initialization
by GitHub pull_request - opened 14 Jun '26

14 Jun '26

alsa-project/alsa-lib pull request #511 was opened from orange-dot: snd_func_iops() initialized result to 0 for both iadd and imul. For imul, every multiplication step therefore multiplied by 0, so @func imul always evaluated to 0. Initialize the accumulator to 1 for imul, while preserving the existing 0 result for an empty integers list. Add regression coverage for iadd and imul evaluation. Fixes: https://github.com/alsa-project/alsa-lib/issues/456 Request URL : https://github.com/alsa-project/alsa-lib/pull/511 Patch URL : https://github.com/alsa-project/alsa-lib/pull/511.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

ALSA 1.2.8 release
by Jaroslav Kysela 14 Jun '26

14 Jun '26

Hello all, new ALSA userspace packages were released. You may download them from the ALSA website http://www.alsa-project.org or directly: HTTP: https://www.alsa-project.org/files/pub FTP: ftp://ftp.alsa-project.org/pub Released packages: alsa-lib alsa-utils alsa-ucm-conf tinycompress Full list of changes: https://www.alsa-project.org/wiki/Changes_v1.2.7.2_v1.2.8 The fingerprint of the public signing key is: F04D F507 37AC 1A88 4C4B 3D71 8380 596D A6E5 9C91 Have fun, Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Sound Maintainer; ALSA Project; Red Hat, Inc.

2 14

Internal microphone saturates at 100% volume on ASUS TUF Gaming A15 (Realtek ALC256)
by GitHub issues - opened 14 Jun '26

14 Jun '26

alsa-project/alsa-ucm-conf issue #790 was opened from Giossue: ### Summary The internal microphone of the ASUS TUF Gaming A15 (FA506QM) saturates/distorts when the system capture volume is set above ~50%. The ALSA hardware volume range is 0–63 steps, where step 63 corresponds to approximately +30 dB. At step 31 (~0 dB / ~49% physical gain) the microphone sounds clean. Currently, the default profile exposes the full 0–63 step range to the UI volume slider, so 100% system volume maps to +30 dB physical gain, clipping the built-in microphone capsule. I am opening this issue to request an upstream fix (such as a UCM profile or hardware quirk) for this laptop model, so the limitation is applied correctly at the ALSA level for all Linux distributions. ### Environment - **Hardware:** ASUS TUF Gaming A15 (FA506QM) - **Audio codec:** Realtek ALC256 (`HDA:10ec0256,10431682,00100002`) - **Distribution:** CachyOS / Arch Linux base - **Kernel:** 6.11-cachyos (or specify exact version) - **PipeWire:** 1.0.0 (or specify exact version) - **Desktop:** KDE Plasma 6, Wayland ### Steps to reproduce 1. Boot the laptop on a fresh Linux session. 2. Open any application that uses the internal microphone (Discord, WebRTC, Audacity, etc.). 3. Set the microphone volume to 100% in the system mixer. 4. Record or monitor the microphone. ### Expected behavior At 100% UI system volume, the microphone should reach a clean, non-saturating gain level suitable for the built-in mic capsule (hardware step 31 / 0 dB). ### Actual behavior The audio is heavily distorted/clipped due to excessive hardware gain. Lowering the system volume to around 50% makes it sound clean. ### ALSA hardware details ```bash $ amixer -c 2 sget Capture Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 63 [100%] [30.00dB] [on] Front Right: Capture 63 [100%] [30.00dB] [on] ``` - Step 0 ≈ -96 dB (effectively muted) - Step 31 ≈ 0 dB / ~49% physical gain (clean level) - Step 63 ≈ +30 dB / 100% physical gain (saturates) ### User-space Workaround used I managed to solve this locally using PipeWire/PulseAudio ALSA Card Profiles, but I understand this should ideally be handled by ALSA UCM or kernel quirks: 1. Custom ALSA Card Profile in `/etc/alsa-card-profile/mixer/profile-sets/default.conf`: ```ini [DecibelFix Capture] db-values = 0:-96.00 31:0.00 ``` 2. WirePlumber rule in `~/.config/wireplumber/wireplumber.conf.d/mic-ignore-db.conf`: ```lua monitor.alsa.rules = [ { matches = [ { device.name = "alsa_card.pci-0000_06_00.6" } ] actions = { update-props = { api.alsa.ignore-dB = true } } } ] ``` Result after this workaround: 100% UI volume maps to step 31/63 (~49% physical hardware gain). The microphone is completely clean and the whole UI slider remains usable. ### Suggested fix Implement a UCM2 profile or hardware database quirk for the ASUS TUF Gaming A15 (`HDA:10ec0256,10431682,00100002`) that correctly limits the `Capture` maximum to 0 dB, so upper layers (WirePlumber/PulseAudio) map 100% volume safely. ### Additional information I am willing to test any UCM configurations or fixes. My `alsa-info.sh` output is: https://alsa-project.org/db/?f=dc8efae429325ead7103381ee34884c5f9d735e5 Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/790 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

USB-Audio: ALC4082 - add MSI MEG X870E GODLIKE (0db0:e5c3)
by GitHub pull_request - opened 14 Jun '26

14 Jun '26

alsa-project/alsa-ucm-conf pull request #789 was opened from Tomcatt: ## Summary The MSI MEG X870E GODLIKE (MS-7E48) uses the Realtek ALC4082 codec presented as a USB Audio class device (USB ID 0db0:e5c3). Two fixes: **1. `ucm2/USB-Audio/USB-Audio.conf`** — add `e5c3` to the ALC4080 profile match so the device is recognised and routed to the correct profile. **2. `ucm2/USB-Audio/Realtek/ALC4080-HiFi.conf`** — add `e5c3` to the `spdif_dev2` condition. On this board the optical S/PDIF output is on ALSA sub-device 2 (Interface 6, Endpoint 8 OUT, stereo, up to 192 kHz) rather than the default sub-device 3. Without this fix the `iec958-stereo` ACP profile produces valid S/PDIF framing — the receiver locks on and clicks — but the PCM audio payload is silent. Routing to sub-device 2 confirmed working. ## Hardware - Board: MSI MEG X870E GODLIKE (MS-7E48) - USB device: `0db0:e5c3 Micro Star International USB Audio` - Kernel: 7.0.12 (CachyOS), ALSA `snd-usb-audio` - `lsusb`: `Bus 003 Device 005: ID 0db0:e5c3 Micro Star International USB Audio` ## Verification ``` $ aplay -l | grep -A1 'card 4' card 4: Audio [USB Audio], device 0: USB Audio [USB Audio] card 4: Audio [USB Audio], device 1: USB Audio [USB Audio #1] card 4: Audio [USB Audio], device 2: USB Audio [USB Audio #2] ← optical S/PDIF card 4: Audio [USB Audio], device 3: USB Audio [USB Audio #3] $ paplay --device=alsa_output.usb-Generic_USB_Audio-00.pro-output-2 \ /usr/share/sounds/alsa/Front_Center.wav # Audio confirmed received by amplifier via optical TOSLINK ``` Without the `spdif_dev2` fix, `hw:Audio,3` produces a valid S/PDIF carrier (receiver relay clicks) but silent PCM. With the fix, `hw:Audio,2` delivers audio correctly. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/789 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/789.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Missing UCM profile for Fifine SC3 (3142:0c33) causes PCM volume to reset to 0 on every boot
by GitHub issues - opened 14 Jun '26

14 Jun '26

alsa-project/alsa-ucm-conf issue #788 was opened from jacxel42: > Note: This issue description was drafted with the help of an AI assistant based on troubleshooting steps and command output from my system. I've done a cursory check and believe it's accurate, but I'm not very familiar with ALSA/UCM internals, so please let me know if anything doesn't make sense or needs clarifying — happy to run further commands or tests. ### Summary The Fifine SC3 USB audio interface (`3142:0c33`) has no UCM profile (`ucm2/USB-Audio/conf.d/3142-0c33.conf` does not exist). As a result, `alsa-restore.service` fails to restore the saved PCM mixer state on boot, and the `PCM` playback volume defaults to `0` every time the system starts — effectively muting the device until manually corrected. ### Hardware - Device: Fifine SC3 (USB audio mixer/interface) - USB ID: `3142:0c33` (MV-SILICON) - `aplay -l` shows it as `card 1: SC3 [fifine SC3], device 0: USB Audio [USB Audio]` ### Symptom On every boot: - `alsamixer -c SC3` shows `PCM` at `0` - Desktop volume controls appear functional (volume slider moves, mute toggle works) but produce no audible output, because the underlying ALSA PCM level is at 0 regardless of what PipeWire/WirePlumber report - Manually running `alsamixer` and raising `PCM` to `100` immediately restores audio, but this does not persist across reboots ### Root cause `alsa-restore.service` logs the following on every boot: ``` alsa-lib utils.c:372:(uc_mgr_config_load_into) could not open configuration file /usr/share/alsa/ucm2/USB-Audio/conf.d/3142-0c33.conf alsa-lib parser.c:79:(uc_mgr_config_load_file) failed to open file /usr/share/alsa/ucm2/USB-Audio/conf.d/3142-0c33.conf: -2 ``` Because no UCM profile exists for this device, `alsactl restore` does not properly initialise/restore the `PCM` mixer control, even though `alsactl store` correctly saves `PCM Playback Volume` at the desired level (4096/4096, 100%) in `/var/lib/alsa/asound.state`. ### Confirmed simple mixer controls ``` $ amixer -c SC3 scontrols Simple mixer control 'PCM',0 Simple mixer control 'Mic',0 $ amixer -c SC3 controls numid=3,iface=MIXER,name='PCM Playback Switch' numid=4,iface=MIXER,name='PCM Playback Volume' numid=5,iface=MIXER,name='Mic Capture Switch' numid=6,iface=MIXER,name='Mic Capture Volume' numid=2,iface=PCM,name='Capture Channel Map' numid=1,iface=PCM,name='Playback Channel Map' ``` ### Current workaround A udev rule that runs `amixer -c SC3 sset 'PCM' 100%` whenever the device is detected (`ACTION=="add", SUBSYSTEM=="sound", ATTRS{idVendor}=="3142", ATTRS{idProduct}=="0c33"`) resolves the issue, but a proper UCM profile would fix this for all users without requiring a manual workaround. ### Environment - OS: Bazzite Linux (Fedora Atomic / Universal Blue based) - Audio stack: PipeWire + WirePlumber (device runs in pro-audio profile) ### Request Could a UCM profile be added for `3142:0c33` (Fifine SC3) that correctly initialises/restores the `PCM` mixer control on boot? Full `alsa-info.sh` output attached/linked separately. Happy to test any proposed config. [alsa-info.txt](https://github.com/user-attachments/files/28919510/alsa-info… Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/788 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Re: [PATCH 7/7] ASoC: dt-bindings: ES8389: Add members about HPF and clock
by Krzysztof Kozlowski 13 Jun '26

13 Jun '26

On Tue, Jun 09, 2026 at 11:06:23AM +0800, Zhang Yi wrote: > Add members related to HPF and mclk_source Please organize the patch documenting the ABI (DT bindings) before the patch using that ABI. See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/… > > Signed-off-by: Zhang Yi <zhangyi(a)everest-semi.com> > --- > .../bindings/sound/everest,es8389.yaml | 23 +++++++++++++++++++ > 1 file changed, 23 insertions(+) > > diff --git a/Documentation/devicetree/bindings/sound/everest,es8389.yaml b/Documentation/devicetree/bindings/sound/everest,es8389.yaml > index 75ce0bc48..be92014c0 100644 > --- a/Documentation/devicetree/bindings/sound/everest,es8389.yaml > +++ b/Documentation/devicetree/bindings/sound/everest,es8389.yaml > @@ -38,6 +38,27 @@ properties: > description: > Interface power supply. > > + everest,mclk-from-sclk: > + $ref: /schemas/types.yaml#/definitions/flag > + description: > + Indicates that SCLK is used as the internal clock. And what happens with mclk in such case? Is it still wired? > + > + everest,hpfl: > + $ref: /schemas/types.yaml#/definitions/uint8 > + description: > + the HPF value of ADCL. Is HPF value in dB? If so, use proper unit suffix and proper units. > + minimum: 0x00 > + maximum: 0x0f > + default: 0x0a > + > + everest,hpfr: > + $ref: /schemas/types.yaml#/definitions/uint8 > + description: > + the HPF value of ADCR. > + minimum: 0x00 > + maximum: 0x0f > + default: 0x0a > + > required: > - compatible > - reg > @@ -58,5 +79,7 @@ examples: > #sound-dai-cells = <0>; > vddd-supply = <&vdd3v3>; > vdda-supply = <&vdd3v3>; > + everest,hpfl = [0a]; <0xa>? What did you want to say here? Best regards, Krzysztof

2 2

Re: [PATCH 2/7] ASoC: codecs: ES8389: Fix the issue about mclk_src
by Krzysztof Kozlowski 13 Jun '26

13 Jun '26

On Tue, Jun 09, 2026 at 11:06:18AM +0800, Zhang Yi wrote: > Fix the issue with incorrect modifications to mclk_src What issue? Your commit msgs are really poor - explain nothing. You just duplicated subject... and anything can be a fix. > > Signed-off-by: Zhang Yi <zhangyi(a)everest-semi.com> > --- > sound/soc/codecs/es8389.c | 12 ++++-------- > sound/soc/codecs/es8389.h | 5 ++--- > 2 files changed, 6 insertions(+), 11 deletions(-) > > diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c > index 9c8164916..7a9d5d42a 100644 > --- a/sound/soc/codecs/es8389.c > +++ b/sound/soc/codecs/es8389.c > @@ -36,8 +36,8 @@ struct es8389_private { > unsigned int sysclk; > int mastermode; > > - u8 mclk_src; > u8 vddd; > + bool mclk_src; > int version; > enum snd_soc_bias_level bias_level; > }; > @@ -607,9 +607,9 @@ static int es8389_pcm_hw_params(struct snd_pcm_substream *substream, > regmap_update_bits(es8389->regmap, ES8389_ADC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state); > regmap_update_bits(es8389->regmap, ES8389_DAC_FORMAT_MUTE, ES8389_DATA_LEN_MASK, state); > > - if (es8389->mclk_src == ES8389_SCLK_PIN) { > + if (es8389->mclk_src) { > regmap_update_bits(es8389->regmap, ES8389_MASTER_CLK, > - ES8389_MCLK_SOURCE, es8389->mclk_src); > + ES8389_MCLK_MASK, ES8389_MCLK_FROM_SCLK); > es8389->sysclk = params_channels(params) * params_width(params) * params_rate(params); > } > > @@ -897,11 +897,7 @@ static int es8389_probe(struct snd_soc_component *component) > int ret, i; > struct es8389_private *es8389 = snd_soc_component_get_drvdata(component); > > - ret = device_property_read_u8(component->dev, "everest,mclk-src", &es8389->mclk_src); Why are you changing implemented ABI? Best regards, Krzysztof

2 2