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

Behringer UMC404HD Line A/B volume too low when used in "Pro Audio" mode
by GitHub issues - edited 16 Dec '25

16 Dec '25

alsa-project/alsa-ucm-conf issue #662 was edited from mrbumpy409: The Behringer UMC404HD shows five volume faders in alsamixer: * **Line A** and **UMC404HD 192k Output Front**: These faders are linked (changing one changes the other) and control the level of **L & R MAIN OUT** and **PLAYBACK OUTPUT A 1/L & 2/R** on the back of the unit. * **Line B** and **UMC404HD 192k Output Back**: These faders are linked and control the level of **PLAYBACK OUTPUT B 3/L & 4/R**. * **UMC404HD 192k Output 1**: The primary volume control for the unit. How these sliders are used by Pipewire depends on the mode selected for the Behringer: * **Default**: Two output devices are presented to the user: - **UMC404HD 192k Line A**: Controls the "Line A" volume in alsamixer. - **UMC404HD 192k Line B**: Controls the "Line B" volume in alsamixer. - The "UMC404HD 192k Output 1" slider in alsamixer appears to be unused. * **Direct UMC404HD 192k**: One output device is presented to the user: - **Direct UMC404HD 192k**: Doesn't seem to be manipulating any of the hardware output levels in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. * **Pro Audio**: One output device is presented to the user: - **UMC404HD 192k Pro**: Controls the "UMC404HD 192k Output 1" output level in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. I would imagine most people are using a Behringer UMC404HD for recording purposes, and therefore would likely be using it in "Pro Audio" mode (or at least they should be if they care about latency). Since a recent update (Fedora 43 KDE), the levels of the "Line A" and "Line B" channels (and their linked pairs) are being set by default to **41**, which results in audio that is far too quiet when using the line outputs (headphone output is unaffected). Furthermore, these low levels throw off the balance between the computer's output and the UMC404HD's live input monitoring. "Line A" and "Line B" channels should both be at **100** by default to match the Windows driver (and previous ALSA version?) and provide correct balance with the live monitoring feature. Currently, I have to run alsamixer on every boot to adjust "Line A" and "Line B" to **100**. Am I right to report this to ALSA, or is this something Pipewire should be handling? Pipewire doesn't appear to touch the "Line A" or "Line B" levels at all when in "Pro Audio" mode, so I'd assume this is ALSA's doing, but I don't really know. ### My System * **OS:** Fedora Linux 43 Plasma Desktop Edition (Plasma Desktop 6.5.4, KDE Frameworks 6.21.0, Qt 6.10.1) * **Linux Kernel:** 6.17.11-300.fc43.x86_64 (64-bit) Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/662 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Behringer UMC404HD Line A/B volume too low when used in "Pro Audio" mode
by GitHub issues - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-ucm-conf issue #662 was opened from mrbumpy409: The Behringer UMC404HD shows five volume faders in alsamixer: * **Line A** and **UMC404HD 192k Output Front**: These faders are linked (changing one changes the other) and control the level of **L & R MAIN OUT** and **PLAYBACK OUTPUT A 1/L & 2/R** on the back of the unit. * **Line B** and **UMC404HD 192k Output Back**: These faders are linked and control the level of **PLAYBACK OUTPUT B 3/L & 4/R**. * **UMC404HD 192k Output 1**: The primary volume control for the unit. How these sliders are used by Pipewire depends on the mode selected for the Behringer: * **Default**: Two output devices are presented to the user: - **UMC404HD 192k Line A**: Controls the "Line A" volume in alsamixer. - **UMC404HD 192k Line B**: Controls the "Line B" volume in alsamixer. - The "UMC404HD 192k Output 1" slider in alsamixer appears to be unused. * **Direct UMC404HD 192k**: One output device is presented to the user: - **Direct UMC404HD 192k**: Doesn't seem to be manipulating any of the hardware output levels in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. * **Pro Audio**: One output device is presented to the user: - **UMC404HD 192k Pro**: Controls the "UMC404HD 192k Output 1" output level in alsamixer. - The "Line A" and "Line B" channels are not available via Pipewire in this mode. I would imagine most people are using a Behringer UMC404HD for recording purposes, and therefore would likely be using it in "Pro Audio" mode (or at least they should be if they care about latency). Since a recent update (Fedora 43 KDE), the levels of the "Line A" and "Line B" channels (and their linked pairs) are being set by default to **41**, which results in audio that is far too quiet when using the line outputs (headphone output is unaffected). Furthermore, these low levels throw off the balance between the computer's output and the UMC404HD's live input monitoring. "Line A" and "Line B" channels should both be at **100** by default to match the Windows driver (and previous ALSA version?) and provide correct balance with the live monitoring feature. Currently, I have to run alsamixer on every boot to adjust "Line A" and "Line B" to **100**. Am I right to report this to ALSA, or is this something Pipewire should be handling? Pipewire doesn't appear to touch the "Line A" or "Line B" levels at all when in "Pro Audio" mode, so I'd assume this is ALSA's doing, but I don't really know. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/662 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

alsa-lib 1.2.15: only fallback stereo available (bisected)
by GitHub issues - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-lib issue #491 was opened from Just4GH: With alsa-lib 1.2.15 only stereo is available. ``` git bisect bad Bisecting: 0 revisions left to test after this (roughly 0 steps) [ eda76146c5653ff1d5bc4b4c53f7a2d5ccc17da2 ] conf: fix load_for_all_cards() - do not merge the card specific contents ``` Reverting eda76146c5653ff1d5bc4b4c53f7a2d5ccc17da2 allows the usual profiles to load and 5.1 output. ``` $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC1150 Analog [ALC1150 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 1: ALC1150 Digital [ALC1150 Digital] Subdevices: 1/1 Subdevice #0: subdevice #0 ``` Issue URL : https://github.com/alsa-project/alsa-lib/issues/491 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

aplay: add missing break before the default case
by GitHub pull_request - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-utils pull request #315 was opened from bardliao: Add the break before the default case back. Otherwise, all cases will fall into the default/error case. Fixes: e78583ab7cde ("aplay: reorganize format handling in begin_wave()") Request URL : https://github.com/alsa-project/alsa-utils/pull/315 Patch URL : https://github.com/alsa-project/alsa-utils/pull/315.patch Repository URL: https://github.com/alsa-project/alsa-utils

1 0

Re: [PATCH v2] ALSA: usb-mixer: us16x08: validate meter packet indices
by Takashi Iwai 16 Dec '25

16 Dec '25

On Tue, 16 Dec 2025 07:01:56 +0100, Shipei Qu wrote: > > Hi, > > resending with a properly formatted diff (the previous email had a malformed > patch header). The change itself is the same: while fuzzing a USB gadget that > emulates a Tascam US-16x08 we found that get_meter_levels_from_urb() in > mixer_us16x08.c uses a channel index taken directly from the 64-byte meter > packet to index meter_level[], comp_level[] and master_level[] without any > bounds checking. A malformed packet can therefore cause out-of-bounds writes in > the snd_us16x08_meter_store. > > A malicious USB audio device (or USB gadget implementation) that pretends to be > a US-16x08-compatible interface can trigger this by sending crafted meter > packets. We have a small USB gadget-based PoC for this behaviour and can share > it if that would be helpful. > > This driver is used by common distributions (e.g. Ubuntu) when a US-16x08 or > compatible USB audio device is present. The same pattern is present in current > mainline kernels. > > This issue was first reported via security(a)kernel.org. The kernel security team > explained that, in the upstream threat model, USB endpoints are expected to be > trusted (i.e. only trusted devices should be bound to drivers), so they > consider this a normal bug rather than a security vulnerability, and asked us > to send a fix to the development lists. The patch below adds simple range > checks before updating these arrays. > > Reported-by: DARKNAVY (@DarkNavyOrg) <vr(a)darknavy.com> > Signed-off-by: Shipei Qu <qu(a)darknavy.com> Thanks, now it looks applicable, and the code change itself looks good. But, could you try to rephrase the patch description above? It'll be used directly as the commit message. So it should be well descriptive about the bug and the fix, while it should concentrate on the technical issues. You can check other commits how they look like, and also see Documentation/process/submitting-patches.rst. thanks, Takashi > --- > sound/usb/mixer_us16x08.c | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/sound/usb/mixer_us16x08.c b/sound/usb/mixer_us16x08.c > index 1c5712c31..f9df40730 100644 > --- a/sound/usb/mixer_us16x08.c > +++ b/sound/usb/mixer_us16x08.c > @@ -655,17 +655,25 @@ static void get_meter_levels_from_urb(int s, > u8 *meter_urb) > { > int val = MUC2(meter_urb, s) + (MUC3(meter_urb, s) << 8); > + int ch = MUB2(meter_urb, s) - 1; > + > + if (ch < 0) > + return; > > if (MUA0(meter_urb, s) == 0x61 && MUA1(meter_urb, s) == 0x02 && > MUA2(meter_urb, s) == 0x04 && MUB0(meter_urb, s) == 0x62) { > - if (MUC0(meter_urb, s) == 0x72) > - store->meter_level[MUB2(meter_urb, s) - 1] = val; > - if (MUC0(meter_urb, s) == 0xb2) > - store->comp_level[MUB2(meter_urb, s) - 1] = val; > + if (ch < SND_US16X08_MAX_CHANNELS) { > + if (MUC0(meter_urb, s) == 0x72) > + store->meter_level[ch] = val; > + if (MUC0(meter_urb, s) == 0xb2) > + store->comp_level[ch] = val; > + } > } > if (MUA0(meter_urb, s) == 0x61 && MUA1(meter_urb, s) == 0x02 && > - MUA2(meter_urb, s) == 0x02 && MUB0(meter_urb, s) == 0x62) > - store->master_level[MUB2(meter_urb, s) - 1] = val; > + MUA2(meter_urb, s) == 0x02 && MUB0(meter_urb, s) == 0x62) { > + if (ch < ARRAY_SIZE(store->master_level)) > + store->master_level[ch] = val; > + } > } > > /* Function to retrieve current meter values from the device. > -- > 2.45.1

1 0

mixer: fix cache coherency issue in multi-application scenario
by GitHub pull_request - edited 16 Dec '25

16 Dec '25

alsa-project/alsa-lib pull request #490 was edited from DevreeseJorik: Remove conditional hardware writes in set_volume_ops and set_switch_ops to ensure hardware state is always updated. This fixes an issue where setting controls to the same value repeatedly does nothing, even if the hardware state has changed due to actions from other applications. --- Given this code has been in alsa-lib for 20 years, I assume there is a good reason for it, or perhaps a workaround exists that I could not find. The issue we faced is that after an initial write, if the same value is written again, but in the meantime a different application altered the hardware state, the new change will not occur, yet no error code is provided. Also, reading the current state returns the current application's state, rather than the actual hardware state. Is alsa-lib not designed with multi-application uses in mind? Request URL : https://github.com/alsa-project/alsa-lib/pull/490 Patch URL : https://github.com/alsa-project/alsa-lib/pull/490.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

mixer: fix cache coherency issue in multi-application scenario
by GitHub pull_request - opened 16 Dec '25

16 Dec '25

alsa-project/alsa-lib pull request #490 was opened from DevreeseJorik: Remove conditional hardware writes in set_volume_ops and set_switch_ops to ensure hardware state is always updated. This fixes an issue where setting controls to the same value repeatedly does nothing, even if the hardware state has changed due to actions from other applications. Request URL : https://github.com/alsa-project/alsa-lib/pull/490 Patch URL : https://github.com/alsa-project/alsa-lib/pull/490.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH v10 0/3] ASoC: rt5575: Add the codec driver for the ALC5575
by Oder Chiou 16 Dec '25

16 Dec '25

Hi all, This patch series adds support for the Realtek ALC5575 audio codec. Changes in v10: - Patch 1/3: - export of_find_spi_controller_by_node() - Patch 2/3: - remove realtek,rt5575-use-spi - add spi-parent for firmware-loading - Patch 3/3: - use of_find_spi_controller_by_node() to get the SPI controller and add the spi device for firmware-loading Changes in v9: - Patch 1/2: - modify the comment - change the compatible name to "realtek,rt5575-use-spi" - Patch 2/2: - remove the standalone rt5575_spi_driver module and integrate its functionality into the I2C driver - move the SPI firmware-loading function to rt5575-spi.c - use the match data to distinguish between w/wo flash - minor fixes - Link to v9: https://lore.kernel.org/all/20251211110130.2925541-1-oder_chiou@realtek.com/ Changes in v8: - Patch 1/2: - remove the variable rt5575_spi_ready - use the multiple compatible names to distinguish between w/wo flash - Patch 2/2: - add compatible enum "realtek,rt5575-with-spi" - Link to v8: https://lore.kernel.org/all/20251201105926.1714341-1-oder_chiou@realtek.com/ Changes in v7: - Patch 1/2: - add a caption for the tristates - remove the redundant enum of the SPI command - add the error log in the request firmware failure - change the function name rt5575_spi_fw_loaded to rt5575_fw_load_by_spi - minor fixes - Patch 2/2: - modify commit message - Link to v7: https://lore.kernel.org/all/20251121084112.743518-1-oder_chiou@realtek.com/ Changes in v6: - Patch 1/2: - modify commit message - add select SND_SOC_RT5575 to config SND_SOC_RT5575_SPI in the Kconfig - revise the boiler plate in the head of the file - sort the include files - use a structure to transfer the spi data - use the poll() related function instead the for-loop - revise the UUID to the private ID - minor fixes - Patch 2/2: - modify description - Link to v6: https://lore.kernel.org/all/20251031073245.3629060-1-oder_chiou@realtek.com/ Changes in v2 to v5: - Patch 1/2: - move the firmware to the subdirectory - remove the empty functions - remove the cache_type in the regmap_config - add the error log in the run firmware failure - Patch 2/2: - nothing - Link to v5: https://lore.kernel.org/all/20251015103404.3075684-1-oder_chiou@realtek.com/ Oder Chiou (3): spi: export of_find_spi_controller_by_node() ASoC: dt-bindings: realtek,rt5575: add support for ALC5575 ASoC: rt5575: Add the codec driver for the ALC5575 .../bindings/sound/realtek,rt5575.yaml | 61 +++ drivers/spi/spi.c | 3 +- include/linux/spi/spi.h | 11 + sound/soc/codecs/Kconfig | 10 + sound/soc/codecs/Makefile | 3 + sound/soc/codecs/rt5575-spi.c | 119 ++++++ sound/soc/codecs/rt5575-spi.h | 26 ++ sound/soc/codecs/rt5575.c | 359 ++++++++++++++++++ sound/soc/codecs/rt5575.h | 54 +++ 9 files changed, 645 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/sound/realtek,rt5575.yaml create mode 100644 sound/soc/codecs/rt5575-spi.c create mode 100644 sound/soc/codecs/rt5575-spi.h create mode 100644 sound/soc/codecs/rt5575.c create mode 100644 sound/soc/codecs/rt5575.h -- 2.52.0

1 3

Re: [PATCH v2 7/8] ASoC: tas2783A: use acpi initialisation table
by Charles Keepax 15 Dec '25

15 Dec '25

On Mon, Dec 15, 2025 at 09:02:18PM +0530, Niranjan H Y wrote: > This patch adds support for parsing the initilisation > data from ACPI table. This table is required to configure > each device correctly so that correct channel's data is > selected during playback. > > Signed-off-by: Niranjan H Y <niranjan.hy(a)ti.com> > --- Reviewed-by: Charles Keepax <ckeepax(a)opensource.cirrus.com> Thanks, Charles

1 0

HP OMEN Transcend 14 (board 8C58, Meteor Lake) – SoundWire speakers not configured (missing UCM profile)
by GitHub issues - opened 15 Dec '25

15 Dec '25

alsa-project/alsa-ucm-conf issue #661 was opened from Farnaz03: ### **Hardware** * Model: HP OMEN Transcend Gaming Laptop 14-fb0xxx * Board ID: **8C58** * CPU: Intel Meteor Lake-P * Audio: Intel SOF + SoundWire * Codec(s): rt711-sdca (headset), rt1316 (speaker amp) * OS: Ubuntu 24.04 LTS ### **Kernels tested** * 6.8.0-88-generic * 6.8.0-90-generic * 6.14.0-1008-oem * 6.14.0-1014-oem --- ### **Description** Internal speakers produce no sound on Linux. SOF firmware and SoundWire devices are detected successfully, and a Speaker PCM exists, but no UCM profile configures or enables the speaker path. Audio reportedly worked earlier (May–July 2025) and stopped after an update around August 2025. --- ### **DMI / board identification** ``` sys_vendor : HP product_name : OMEN Transcend Gaming Laptop 14-fb0xxx board_name : 8C58 board_vendor : HP ``` --- ### **SOF topology in use** ``` intel/sof-ace-tplg/sof-mtl-rt711-l0-rt1316-l3-2ch.tplg ``` --- ### **aplay -l** ``` card 1: sofsoundwire [sof-soundwire], device 0: Jack Out card 1: sofsoundwire [sof-soundwire], device 2: Speaker card 1: sofsoundwire [sof-soundwire], device 31: Deepbuffer Jack Out ... ``` --- ### **ALSA direct tests (PipeWire bypassed)** ``` aplay -D hw:1,2 /usr/share/sounds/alsa/Front_Center.wav aplay -D hw:1,0 /usr/share/sounds/alsa/Front_Center.wav aplay -D hw:1,31 /usr/share/sounds/alsa/Front_Center.wav ``` All fail with: ``` aplay: set_params: Channels count non available ``` --- ### **UCM status** ``` /usr/share/alsa/ucm2/sof-soundwire/ -> empty (no profiles) ``` --- ### **Expected result** Internal speakers work via ALSA / PipeWire. ### **Actual result** Speaker PCM exists but is unusable due to missing UCM configuration. ### **Request** Add a UCM profile for HP OMEN Transcend 14 (board 8C58) under `sof-soundwire`, enabling the speaker path for the existing SOF topology. ### Optional notes / suggestions This platform uses SOF SoundWire with rt1316 speaker amp and rt711 headset codec, and the loaded topology already supports a 2-channel speaker path: sof-mtl-rt711-l0-rt1316-l3-2ch.tplg It may be possible to adapt or clone an existing HP SoundWire UCM profile for Meteor Lake platforms using rt1316 (if available), matching DMI board ID `HP / 8C58`. I am happy to test patches or provide additional logs if needed. Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/661 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0