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

[alsa-devel] View alsa-lib plugins setup for any app?
by Eliot Blennerhassett 05 Dec '25

05 Dec '25

Greetings, running aplay -v will show the plugin chain setup. /proc/asound/card/pcm/* shows hw and sw params for the card driver when in use by any app Is there any way to show the alsa-lib plugin settings a-la aplay for an arbitrary application? thanks -- Eliot

4 8

[PATCH] ASoC: rt5682: Support the ALC5682I-VE codec
by derek.fang＠realtek.com 04 Dec '25

04 Dec '25

From: Derek Fang <derek.fang(a)realtek.com> The ALC5682I-VD and ALC5682I-VE use the same I2C codec driver with different calibration settings. This patch aims to handle their differences. Signed-off-by: Derek Fang <derek.fang(a)realtek.com> diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c index ff9e14fad0cd..a8820435d1e0 100644 --- a/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt5682-i2c.c @@ -186,6 +186,12 @@ static int rt5682_i2c_probe(struct i2c_client *i2c) return -ENODEV; } + regmap_read(rt5682->regmap, RT5682_INT_DEVICE_ID, &val); + if (val == 0x6956) { + dev_dbg(&i2c->dev, "ALC5682I-VE device\n"); + rt5682->ve_ic = true; + } + mutex_init(&rt5682->calibrate_mutex); rt5682_calibrate(rt5682); diff --git a/sound/soc/codecs/rt5682.c b/sound/soc/codecs/rt5682.c index aa163ec40862..b4d72fc4a44d 100644 --- a/sound/soc/codecs/rt5682.c +++ b/sound/soc/codecs/rt5682.c @@ -395,6 +395,7 @@ bool rt5682_volatile_register(struct device *dev, unsigned int reg) case RT5682_4BTN_IL_CMD_1: case RT5682_AJD1_CTRL: case RT5682_HP_CALIB_CTRL_1: + case RT5682_INT_DEVICE_ID: case RT5682_DEVICE_ID: case RT5682_I2C_MODE: case RT5682_HP_CALIB_CTRL_10: @@ -419,6 +420,7 @@ bool rt5682_readable_register(struct device *dev, unsigned int reg) { switch (reg) { case RT5682_RESET: + case RT5682_INT_DEVICE_ID: case RT5682_VERSION_ID: case RT5682_VENDOR_ID: case RT5682_DEVICE_ID: @@ -3139,7 +3141,10 @@ void rt5682_calibrate(struct rt5682_priv *rt5682) regmap_write(rt5682->regmap, RT5682_PWR_DIG_1, 0x0100); regmap_write(rt5682->regmap, RT5682_HP_IMP_SENS_CTRL_19, 0x3800); regmap_write(rt5682->regmap, RT5682_CHOP_DAC, 0x3000); - regmap_write(rt5682->regmap, RT5682_CALIB_ADC_CTRL, 0x7005); + if (rt5682->ve_ic) + regmap_write(rt5682->regmap, RT5682_CHOP_ADC, 0x7005); + else + regmap_write(rt5682->regmap, RT5682_CALIB_ADC_CTRL, 0x7005); regmap_write(rt5682->regmap, RT5682_STO1_ADC_MIXER, 0x686c); regmap_write(rt5682->regmap, RT5682_CAL_REC, 0x0d0d); regmap_write(rt5682->regmap, RT5682_HP_CALIB_CTRL_2, 0x0321); @@ -3168,7 +3173,10 @@ void rt5682_calibrate(struct rt5682_priv *rt5682) regmap_write(rt5682->regmap, RT5682_GLB_CLK, 0x0000); regmap_write(rt5682->regmap, RT5682_PWR_DIG_1, 0x0000); regmap_write(rt5682->regmap, RT5682_CHOP_DAC, 0x2000); - regmap_write(rt5682->regmap, RT5682_CALIB_ADC_CTRL, 0x2005); + if (rt5682->ve_ic) + regmap_write(rt5682->regmap, RT5682_CHOP_ADC, 0x2005); + else + regmap_write(rt5682->regmap, RT5682_CALIB_ADC_CTRL, 0x2005); regmap_write(rt5682->regmap, RT5682_STO1_ADC_MIXER, 0xc0c4); regmap_write(rt5682->regmap, RT5682_CAL_REC, 0x0c0c); diff --git a/sound/soc/codecs/rt5682.h b/sound/soc/codecs/rt5682.h index b2d9e87af259..de43a5d99403 100644 --- a/sound/soc/codecs/rt5682.h +++ b/sound/soc/codecs/rt5682.h @@ -22,6 +22,7 @@ /* Info */ #define RT5682_RESET 0x0000 +#define RT5682_INT_DEVICE_ID 0x00f9 #define RT5682_VERSION_ID 0x00fd #define RT5682_VENDOR_ID 0x00fe #define RT5682_DEVICE_ID 0x00ff @@ -1446,6 +1447,7 @@ struct rt5682_priv { bool hw_init; bool first_hw_init; bool is_sdw; + bool ve_ic; #ifdef CONFIG_COMMON_CLK struct clk_hw dai_clks_hw[RT5682_DAI_NUM_CLKS]; -- 2.34.1

3 2

[PATCH] ASoC: SOF: Intel: Retry codec probing if it fails
by Kai Vehmanen 04 Dec '25

04 Dec '25

From: Hui Wang <hui.wang(a)canonical.com> On the latest Lenovo Thinkstation laptops, we often experience the speaker failure after rebooting, check the dmesg, we could see: sof-audio-pci-intel-tgl 0000:00:1f.3: codec #0 probe error, ret: -5 The analogue codec on the machine is ALC287, then we designed a testcase to reboot and check the codec probing result repeatedly, we found the analogue codec probing always failed at least once within several minutes to several hours (roughly 1 reboot per min). This issue happens on all laptops of this Thinkstation model, but with legacy HDA driver, we couldn't reproduce this issue on those laptops. And so far, this issue is not reproduced on machines which don't belong to this model. We tried to make the hda_dsp_ctrl_init_chip() same as hda_intel_init_chip() which is the controller init routine in the legacy HDA driver, but it didn't help. We found when issue happens, the resp is -1, and if we let driver re-run send_cmd() and get_response(), it will get the correct response 10ec0287, then driver continues the rest work, finally boot to the desktop and all audio function work well. Here adding codec probing retries to 3 times, it could fix the issue on this Thinkstation model, and it doesn't bring impact to other machines. Reviewed-by: Bard Liao <bard.liao(a)intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> --- sound/soc/sof/intel/hda-codec.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) Notes: - patch for-5.16 on top of for-5.16 8a724d5f60 diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c index 6744318de612..13cd96e6724a 100644 --- a/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-codec.c @@ -22,6 +22,7 @@ #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC) #define IDISP_VID_INTEL 0x80860000 +#define CODEC_PROBE_RETRIES 3 /* load the legacy HDA codec driver */ static int request_codec_module(struct hda_codec *codec) @@ -121,12 +122,15 @@ static int hda_codec_probe(struct snd_sof_dev *sdev, int address, u32 hda_cmd = (address << 28) | (AC_NODE_ROOT << 20) | (AC_VERB_PARAMETERS << 8) | AC_PAR_VENDOR_ID; u32 resp = -1; - int ret; + int ret, retry = 0; + + do { + mutex_lock(&hbus->core.cmd_mutex); + snd_hdac_bus_send_cmd(&hbus->core, hda_cmd); + snd_hdac_bus_get_response(&hbus->core, address, &resp); + mutex_unlock(&hbus->core.cmd_mutex); + } while (resp == -1 && retry++ < CODEC_PROBE_RETRIES); - mutex_lock(&hbus->core.cmd_mutex); - snd_hdac_bus_send_cmd(&hbus->core, hda_cmd); - snd_hdac_bus_get_response(&hbus->core, address, &resp); - mutex_unlock(&hbus->core.cmd_mutex); if (resp == -1) return -EIO; dev_dbg(sdev->dev, "HDA codec #%d probed OK: response: %x\n", base-commit: 8a724d5f60904084e09de2685ff9e77bc8a40815 -- 2.34.1

3 2

[alsa-devel] Applied "ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF" to the asoc tree
by Mark Brown 02 Dec '25

02 Dec '25

The patch ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From fd2df3aeafa4b4cc468d58e147e0822967034b71 Mon Sep 17 00:00:00 2001 From: Annaliese McDermond <nh6z(a)nh6z.net> Date: Thu, 21 Mar 2019 17:58:46 -0700 Subject: [PATCH] ASoC: tlv320aic32x4: Model CODEC_CLKIN in CCF Model and manage codec clock input as a component in the Core Clock Framework. This should allow us to do some more complex clock management and power control. Also, some of the on-board chip clocks can be exposed to the outside, and this change will make those clocks easier to consume by other parts of the kernel. Signed-off-by: Annaliese McDermond <nh6z(a)nh6z.net> Signed-off-by: Mark Brown <broonie(a)kernel.org> --- sound/soc/codecs/tlv320aic32x4-clk.c | 34 ++++++++++++++++++++++++++++ sound/soc/codecs/tlv320aic32x4.c | 18 +++++++++++---- 2 files changed, 47 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/tlv320aic32x4-clk.c b/sound/soc/codecs/tlv320aic32x4-clk.c index 5e495fc8d931..cded85009c8c 100644 --- a/sound/soc/codecs/tlv320aic32x4-clk.c +++ b/sound/soc/codecs/tlv320aic32x4-clk.c @@ -265,6 +265,30 @@ static const struct clk_ops aic32x4_pll_ops = { .get_parent = clk_aic32x4_pll_get_parent, }; +static int clk_aic32x4_codec_clkin_set_parent(struct clk_hw *hw, u8 index) +{ + struct clk_aic32x4 *mux = to_clk_aic32x4(hw); + + return regmap_update_bits(mux->regmap, + AIC32X4_CLKMUX, + AIC32X4_CODEC_CLKIN_MASK, index << AIC32X4_CODEC_CLKIN_SHIFT); +} + +static u8 clk_aic32x4_codec_clkin_get_parent(struct clk_hw *hw) +{ + struct clk_aic32x4 *mux = to_clk_aic32x4(hw); + unsigned int val; + + regmap_read(mux->regmap, AIC32X4_CLKMUX, &val); + + return (val & AIC32X4_CODEC_CLKIN_MASK) >> AIC32X4_CODEC_CLKIN_SHIFT; +} + +static const struct clk_ops aic32x4_codec_clkin_ops = { + .set_parent = clk_aic32x4_codec_clkin_set_parent, + .get_parent = clk_aic32x4_codec_clkin_get_parent, +}; + static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = { { .name = "pll", @@ -274,6 +298,14 @@ static struct aic32x4_clkdesc aic32x4_clkdesc_array[] = { .ops = &aic32x4_pll_ops, .reg = 0, }, + { + .name = "codec_clkin", + .parent_names = + (const char *[]) { "mclk", "bclk", "gpio", "pll" }, + .num_parents = 4, + .ops = &aic32x4_codec_clkin_ops, + .reg = 0, + }, }; static struct clk *aic32x4_register_clk(struct device *dev, @@ -314,6 +346,8 @@ int aic32x4_register_clocks(struct device *dev, const char *mclk_name) */ aic32x4_clkdesc_array[0].parent_names = (const char* []) { mclk_name, "bclk", "gpio", "din" }; + aic32x4_clkdesc_array[1].parent_names = + (const char *[]) { mclk_name, "bclk", "gpio", "pll" }; for (i = 0; i < ARRAY_SIZE(aic32x4_clkdesc_array); ++i) aic32x4_register_clk(dev, &aic32x4_clkdesc_array[i]); diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index 7cf8c7cedfe1..5496e4e080f4 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -735,12 +735,9 @@ static int aic32x4_setup_clocks(struct snd_soc_component *component, aic32x4_set_processing_blocks(component, aic32x4_divs[i].r_block, aic32x4_divs[i].p_block); - /* PLL as CODEC_CLKIN */ - snd_soc_component_update_bits(component, AIC32X4_CLKMUX, - AIC32X4_CODEC_CLKIN_MASK, - AIC32X4_CODEC_CLKIN_PLL << AIC32X4_CODEC_CLKIN_SHIFT); /* DAC_MOD_CLK as BDIV_CLKIN */ - snd_soc_component_update_bits(component, AIC32X4_IFACE3, AIC32X4_BDIVCLK_MASK, + snd_soc_component_update_bits(component, AIC32X4_IFACE3, + AIC32X4_BDIVCLK_MASK, AIC32X4_DACMOD2BCLK << AIC32X4_BDIVCLK_SHIFT); /* NDAC divider value */ @@ -987,6 +984,15 @@ static int aic32x4_component_probe(struct snd_soc_component *component) { struct aic32x4_priv *aic32x4 = snd_soc_component_get_drvdata(component); u32 tmp_reg; + int ret; + + struct clk_bulk_data clocks[] = { + { .id = "codec_clkin" }, + }; + + ret = devm_clk_bulk_get(component->dev, ARRAY_SIZE(clocks), clocks); + if (ret) + return ret; if (gpio_is_valid(aic32x4->rstn_gpio)) { ndelay(10); @@ -999,6 +1005,8 @@ static int aic32x4_component_probe(struct snd_soc_component *component) if (aic32x4->setup) aic32x4_setup_gpios(component); + clk_set_parent(clocks[0].clk, clocks[1].clk); + /* Power platform configuration */ if (aic32x4->power_cfg & AIC32X4_PWR_MICBIAS_2075_LDOIN) { snd_soc_component_write(component, AIC32X4_MICBIAS, -- 2.20.1

7 8

HDSPmixer coredumps on Arch Linux
by GitHub issues - opened 30 Nov '25

30 Nov '25

alsa-project/alsa-tools issue #43 was opened from rubin55: This is recent, I suspect after fltk upgrade to 1.4.x november the 25th. Here is the bt: ``` HDSPMixer 1.11 - Copyright (C) 2003 Thomas Charbonnel <thomas(a)undata.org> This program comes with ABSOLUTELY NO WARRANTY HDSPMixer is free software, see the file COPYING for details Looking for RME cards: Card 0: HDA Intel PCH at 0x4802120000 irq 201 Card 1: RME AIO Pro S/N 24093311 at 0x82500000 irq 16 RME AIO found! Card 2: Logi 4K Stream Edition at usb-0000:00:14.0-5, super speed Card 3: HDA NVidia at 0x82080000 irq 17 1 RME cards card found. Initializing default presets Program received signal SIGSEGV, Segmentation fault. Downloading 47.21 K source file /usr/src/debug/alsa-tools/alsa-tools-1.2.14/hdspmixer/src/HDSPMixerWindow.cxx handler_cb (event=24) at /usr/src/debug/alsa-tools/alsa-tools-1.2.14/hdspmixer/src/HDSPMixerWindow.cxx:278 278 if (fl_win->label()) { (gdb) bt #0 handler_cb (event=24) at /usr/src/debug/alsa-tools/alsa-tools-1.2.14/hdspmixer/src/HDSPMixerWindow.cxx:278 #1 0x00007ffff7c69009 in send_handlers (e=24) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl.cxx:935 #2 Fl::handle_ (e=<optimized out>, window=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl.cxx:1620 #3 Fl::handle_ (e=<optimized out>, window=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl.cxx:1384 #4 0x00007ffff6b9cac6 in ffi_call_unix64 () at ../src/x86/unix64.S:104 #5 0x00007ffff6b9976b in ffi_call_int (cif=cif@entry=0x7fffffffc9e0, fn=fn@entry=0x7ffff7cfcd40 <output_done(void*, wl_output*)>, rvalue=<optimized out>, rvalue@entry=0x0, avalue=avalue@entry=0x7fffffffcab0, closure=closure@entry=0x0) at ../src/x86/ffi64.c:676 #6 0x00007ffff6b9c06e in ffi_call (cif=cif@entry=0x7fffffffc9e0, fn=0x7ffff7cfcd40 <output_done(void*, wl_output*)>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7fffffffcab0) at ../src/x86/ffi64.c:713 #7 0x00007ffff763c48d in wl_closure_invoke (closure=closure@entry=0x55555596e0f0, target=<optimized out>, target@entry=0x555555971060, opcode=opcode@entry=2, data=<optimized out>, flags=1) at ../wayland-1.24.0/src/connection.c:1241 #8 0x00007ffff763d2e9 in dispatch_event (display=display@entry=0x5555555a9b70, queue=queue@entry=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:1707 #9 0x00007ffff763d6f3 in dispatch_queue (display=0x5555555a9b70, queue=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:1853 #10 wl_display_dispatch_queue_pending (display=display@entry=0x5555555a9b70, queue=queue@entry=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:2190 #11 0x00007ffff7640f34 in wl_display_dispatch_queue_timeout (display=0x5555555a9b70, queue=0x5555555a9c68, timeout=timeout@entry=0x0) at ../wayland-1.24.0/src/wayland-client.c:2096 #12 0x00007ffff7641010 in wl_display_dispatch_queue (display=<optimized out>, queue=<optimized out>) at ../wayland-1.24.0/src/wayland-client.c:2163 #13 0x00007ffff7cf9aba in sync_done (data=<optimized out>, cb=<optimized out>, time=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1389 #14 0x00007ffff6b9cac6 in ffi_call_unix64 () at ../src/x86/unix64.S:104 #15 0x00007ffff6b9976b in ffi_call_int (cif=cif@entry=0x7fffffffced0, fn=fn@entry=0x7ffff7cf9a60 <sync_done(void*, wl_callback*, uint32_t)>, rvalue=<optimized out>, rvalue@entry=0x0, avalue=avalue@entry=0x7fffffffcfa0, closure=closure@entry=0x0) at ../src/x86/ffi64.c:676 #16 0x00007ffff6b9c06e in ffi_call (cif=cif@entry=0x7fffffffced0, fn=0x7ffff7cf9a60 <sync_done(void*, wl_callback*, uint32_t)>, rvalue=rvalue@entry=0x0, avalue=avalue@entry=0x7fffffffcfa0) at ../src/x86/ffi64.c:713 #17 0x00007ffff763c48d in wl_closure_invoke (closure=closure@entry=0x555555970da0, target=<optimized out>, target@entry=0x55555596e1d0, opcode=opcode@entry=0, data=<optimized out>, flags=1) at ../wayland-1.24.0/src/connection.c:1241 #18 0x00007ffff763d2e9 in dispatch_event (display=display@entry=0x5555555a9b70, queue=queue@entry=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:1707 #19 0x00007ffff763d6f3 in dispatch_queue (display=0x5555555a9b70, queue=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:1853 #20 wl_display_dispatch_queue_pending (display=display@entry=0x5555555a9b70, queue=queue@entry=0x5555555a9c68) at ../wayland-1.24.0/src/wayland-client.c:2190 #21 0x00007ffff7640f34 in wl_display_dispatch_queue_timeout (display=0x5555555a9b70, queue=0x5555555a9c68, timeout=timeout@entry=0x0) at ../wayland-1.24.0/src/wayland-client.c:2096 --Type <RET> for more, q to quit, c to continue without paging-- #22 0x00007ffff7641010 in wl_display_dispatch_queue (display=<optimized out>, queue=<optimized out>) at ../wayland-1.24.0/src/wayland-client.c:2163 #23 0x00007ffff7cfa169 in Fl_Wayland_Screen_Driver::open_display_platform (this=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1426 #24 Fl_Wayland_Screen_Driver::open_display_platform (this=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1406 #25 0x00007ffff7cacafa in Fl_Screen_Driver::open_display (this=0x55555596df60) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl_Screen_Driver.cxx:605 #26 Fl_Screen_Driver::open_display (this=0x55555596df60) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl_Screen_Driver.cxx:600 #27 0x00007ffff7cfd942 in Fl_Wayland_Screen_Driver::get_system_colors (this=<optimized out>) at /usr/src/debug/fltk/fltk-release-1.4.4/src/drivers/Wayland/Fl_Wayland_Screen_Driver.cxx:1708 #28 0x00007ffff7ce301e in Fl_Window::show (this=0x5555555c75a0, argc=1, argv=0x7fffffffd558) at /usr/src/debug/fltk/fltk-release-1.4.4/src/Fl_arg.cxx:290 #29 0x000055555555aa17 in Fl_Double_Window::show (this=<optimized out>, a=1, b=0x7fffffffd558) at /usr/include/FL/Fl_Double_Window.H:36 #30 main (argc=1, argv=0x7fffffffd558) at /usr/src/debug/alsa-tools/alsa-tools-1.2.14/hdspmixer/src/hdspmixer.cxx:120 ``` Issue URL : https://github.com/alsa-project/alsa-tools/issues/43 Repository URL: https://github.com/alsa-project/alsa-tools

1 0

Creative ZXR channels and volume messed up
by GitHub issues - edited 30 Nov '25

30 Nov '25

alsa-project/alsa-lib issue #484 was edited from CommonDirt: posted this over @ Pipewire, but i'm guessing this is an ALSA issue https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4996 something's changed with the CA0132 firmware, because previously in alsamixer the 10 band EQ was not exposed <img width="899" height="439" alt="Image" src="https://github.com/user-attachments/assets/755ecd00-b59a-47fd-b5b0-6fa5456f…" /> Issue URL : https://github.com/alsa-project/alsa-lib/issues/484 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

Creative ZXR channels and volume messed up
by GitHub issues - opened 30 Nov '25

30 Nov '25

alsa-project/alsa-lib issue #484 was opened from CommonDirt: posted this over @ Pipewire, but i'm guessing this is an ALSA issue https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4996 Issue URL : https://github.com/alsa-project/alsa-lib/issues/484 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

hdspmixer: fix null pointer dereference in HDSPMixerWindow:handler_cb
by GitHub pull_request - opened 30 Nov '25

30 Nov '25

alsa-project/alsa-tools pull request #42 was opened from cheldt: Fixes following error: Program received signal SIGSEGV, Segmentation fault. handler_cb () at /home/snaut/dev/alsa-tools/hdspmixer/src/HDSPMixerWindow.cxx:278 Request URL : https://github.com/alsa-project/alsa-tools/pull/42 Patch URL : https://github.com/alsa-project/alsa-tools/pull/42.patch Repository URL: https://github.com/alsa-project/alsa-tools

1 0

Roland OCTA-CAPTURE (0582:0120) - White Noise/Static on Playback
by Niklas Aldervall 29 Nov '25

29 Nov '25

# ALSA Bug Report: Roland OCTA-CAPTURE (0582:0120) - White Noise/Static on Playback ## Summary Roland OCTA-CAPTURE USB audio interface produces white noise/static instead of clean audio on Linux, despite being detected and initialized by snd_usb_audio driver. ## Device Information - **Model**: Roland OCTA-CAPTURE (UA-1010) - **USB ID**: 0582:0120 - **Manufacturer**: Roland Corporation - **Device Class**: Vendor Specific (0xFF) - NOT USB Audio Class compliant - **Serial**: ISRL4B236F81 ## System Information - **Kernel**: 6.17.9-2-cachyos - **Distribution**: Arch Linux (CachyOS) - **Audio Server**: PipeWire 1.2.7 - **ALSA Driver**: snd_usb_audio (built as module) ## Symptoms 1. Device is correctly detected and recognized by ALSA 2. ALSA shows proper capabilities: S32_LE, 10ch playback, 12ch capture, 44100Hz 3. Audio streams can be sent to device without errors 4. **OUTPUT**: Only white noise/static is produced instead of clean audio 5. Issue occurs with both direct ALSA (speaker-test) and PipeWire 6. Issue persists across all available profiles (multichannel, pro-audio) ## Device Detection (lsusb) ``` Bus 001 Device 008: ID 0582:0120 Roland Corp. OCTA-CAPTURE bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 idVendor 0x0582 Roland Corp. idProduct 0x0120 OCTA-CAPTURE ``` ## ALSA Stream Configuration ``` Roland OCTA-CAPTURE at usb-0000:00:14.0-3, high speed : USB Audio Playback: Status: Stop Interface 0 Altset 1 Format: S32_LE Channels: 10 Endpoint: 0x05 (5 OUT) (ASYNC) Rates: 44100 Data packet interval: 125 us Bits: 0 Sync Endpoint: 0x85 (5 IN) Sync EP Interface: 1 Sync EP Altset: 1 Implicit Feedback Mode: Yes Capture: Status: Stop Interface 1 Altset 1 Format: S32_LE Channels: 12 Endpoint: 0x85 (5 IN) (ASYNC) Rates: 44100 Data packet interval: 125 us Bits: 0 Sync Endpoint: 0x05 (5 OUT) Sync EP Interface: 0 Sync EP Altset: 1 Implicit Feedback Mode: Yes ``` ## Hardware Configuration - **Digital Input**: OFF (changed from AUTO - no effect) - **Sample Rate**: 44.1kHz (hardware configured) - **Output**: Connected to OUT 1/2 (analog) - **Routing**: Factory reset performed - no effect ## Workarounds Attempted (All Failed) 1. **PipeWire profiles**: Tried pro-audio, multichannel-duplex 2. **Module parameters** (all individually and in combination): - `lowlatency=0` - Disable low-latency mode - `autoclock=0` - Force manual clock - `implicit_fb=0` - Disable implicit feedback - `device_setup=0,1` - Different device modes - `quirk_flags=0x8,0x20` - Various quirk flags 3. **Hardware configuration**: - DIGITAL = OFF (vs AUTO) - Factory reset via hardware buttons 4. **Different audio paths**: - Direct ALSA (hw:1,0) - PipeWire - All produce same static ## Test Command Used ```bash speaker-test -D hw:1,0 -c 10 -t sine -f 440 -r 44100 -F S32_LE -l 3 ``` **Result**: White noise/static instead of clean 440Hz tone ## Kernel Support Status - Device added to implicit feedback skip list in kernel 5.11.9 (March 2021) - Patch: `IMPLICIT_FB_SKIP_DEV(0x0582, 0x0120)` - No additional patches found for kernels 6.x ## Related Devices - Roland Quad-Capture (0582:0118) - Similar architecture, better Linux support - Roland U-8 (older device) - Has third-party Linux tools (u8ctl) ## Known Issues from Community - LinuxMusicians forum: "loud white noise sounds generated along with audio" - Multiple users report same symptom since 2013 - No documented solution exists ## Hypothesis The OCTA-CAPTURE uses Roland's proprietary USB protocol (vendor-specific class 0xFF). The device likely requires: 1. Proprietary initialization sequence not performed by generic snd_usb_audio 2. SysEx MIDI configuration for internal DSP/routing/clock 3. Vendor-specific control messages for proper operation Without Roland's cooperation or reverse engineering of Windows driver, proper support may be impossible. ## Request 1. Is there additional debugging we can enable to trace USB communication? 2. Could vendor-specific initialization be missing? 3. Would Roland device reverse engineering resources help? 4. Should this device be blacklisted if it cannot work properly? ## Additional Resources - Device manual: https://static.roland.com/assets/media/pdf/OCTA-CAPTURE_v1.6_OM.pdf - Kernel patch (2021): https://patchwork.kernel.org/project/alsa-devel/patch/CAOsVg8psuOkQRoccDs7A… - LinuxMusicians thread: https://linuxmusicians.com/viewtopic.php?t=17423 ## Contact Best Regards Niklas Aldervall

2 1

[GIT PULL] ASoC fixes for v6.18-rc7
by Mark Brown 27 Nov '25

27 Nov '25

The following changes since commit 6a23ae0a96a600d1d12557add110e0bb6e32730c: Linux 6.18-rc6 (2025-11-16 14:25:38 -0800) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v6.18-rc7 for you to fetch changes up to 73b97d46dde64fa184d47865d4a532d818c3a007: ASoC: fsl_xcvr: clear the channel status control memory (2025-11-26 13:24:19 +0000) ---------------------------------------------------------------- ASoC: Fixes for v6.18 A small pile of driver specific fixes that came in during the past few weeks, none of them especially major. ---------------------------------------------------------------- Baojun Xu (1): ASoC: tas2781: Correct the wrong chip ID for reset variable check Biju Das (2): ASoC: renesas: rz-ssi: Fix channel swap issue in full duplex mode ASoC: renesas: rz-ssi: Fix rz_ssi_priv::hw_params_cache::sample_width Ma Ke (2): ASoC: codecs: wcd937x: Fix error handling in wcd937x codec driver ASoC: codecs: Fix error handling in pm4125 audio codec driver Shenghao Ding (1): ASoC: tas2781: correct the wrong period Shengjiu Wang (1): ASoC: fsl_xcvr: clear the channel status control memory Srinivas Kandagatla (1): ASoC: codecs: wcd934x: add explicit soundwire depenency sound/soc/codecs/Kconfig | 1 + sound/soc/codecs/pm4125.c | 21 ++++++++++-- sound/soc/codecs/tas2781-comlib-i2c.c | 2 +- sound/soc/codecs/tas2781-i2c.c | 2 +- sound/soc/codecs/wcd937x.c | 43 ++++++++++++++++++----- sound/soc/fsl/fsl_xcvr.c | 2 +- sound/soc/renesas/rz-ssi.c | 64 +++++++++++++++++++++++++---------- 7 files changed, 103 insertions(+), 32 deletions(-)

2 2