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

Re: [Bug 220109] Audio disappears on HP 15-fc000 after warm boot again (ALC256 code path)
by Ruslan Nikolaev 20 May '25

20 May '25

Kailiang, I added alsa-info outputs to https://bugzilla.kernel.org/show_bug.cgi?id=220109 (see attachments for both the regression and reverted changes) by following your instructions. Please let me know if there is any other information you need. Thanks, Ruslan On Tuesday, May 13, 2025 at 02:30:17 AM EDT, <bugzilla-daemon(a)kernel.org> wrote: https://bugzilla.kernel.org/show_bug.cgi?id=220109 Kailiang Yang (kailang(a)realtek.com) changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kailang(a)realtek.com --- Comment #3 from Kailiang Yang (kailang(a)realtek.com) --- Could you run alsa-info.sh to dump codec info? Please do ==> echo 1 > /sys/module/snd_hda_codec/parameters/dump_coef before do alsa-info.sh. -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. You reported the bug.

1 1

[PATCH v1] ASoC: tas2781: Header file cleanup and Move the macro definitions to fwlib
by Shenghao Ding 20 May '25

20 May '25

Drop the I2C in one comment, for these registers are also used in SPI driver; Move the macro definition of TASDEVICE_CMD_XXX from tas2781.h to tas2781_fmwlib.c, because the macros are only referenced in only fwlib. Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- v1: - Correct the comment in tas2781.h. - Move the definition of TASDEVICE_CMD_XXX from tas2781.h to tas2781_fmwlib.c --- include/sound/tas2781.h | 7 +------ sound/soc/codecs/tas2781-fmwlib.c | 5 +++++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/sound/tas2781.h b/include/sound/tas2781.h index 442126aa124a..9dc178a7486a 100644 --- a/include/sound/tas2781.h +++ b/include/sound/tas2781.h @@ -49,7 +49,7 @@ #define TASDEVICE_REG_SWRESET TASDEVICE_REG(0x0, 0x0, 0x01) #define TASDEVICE_REG_SWRESET_RESET BIT(0) -/* I2C Checksum */ +/* Checksum */ #define TASDEVICE_CHECKSUM_REG TASDEVICE_REG(0x0, 0x0, 0x7e) /* XM_340 */ @@ -105,11 +105,6 @@ #define TAS2781_RUNTIME_RE_REG_TF TASDEVICE_REG(0x64, 0x62, 0x48) #define TAS2781_RUNTIME_RE_REG TASDEVICE_REG(0x64, 0x63, 0x44) -#define TASDEVICE_CMD_SING_W 0x1 -#define TASDEVICE_CMD_BURST 0x2 -#define TASDEVICE_CMD_DELAY 0x3 -#define TASDEVICE_CMD_FIELD_W 0x4 - enum audio_device { TAS2563, TAS2781, diff --git a/sound/soc/codecs/tas2781-fmwlib.c b/sound/soc/codecs/tas2781-fmwlib.c index 28adfc5526bd..c9c1e608ddb7 100644 --- a/sound/soc/codecs/tas2781-fmwlib.c +++ b/sound/soc/codecs/tas2781-fmwlib.c @@ -50,6 +50,11 @@ #define TAS2781_YRAM5_START_REG TAS2781_YRAM3_START_REG #define TAS2781_YRAM5_END_REG TAS2781_YRAM3_END_REG +#define TASDEVICE_CMD_SING_W 0x1 +#define TASDEVICE_CMD_BURST 0x2 +#define TASDEVICE_CMD_DELAY 0x3 +#define TASDEVICE_CMD_FIELD_W 0x4 + #define TASDEVICE_MAXPROGRAM_NUM_KERNEL 5 #define TASDEVICE_MAXCONFIG_NUM_KERNEL_MULTIPLE_AMPS 64 #define TASDEVICE_MAXCONFIG_NUM_KERNEL 10 -- 2.43.0

2 1

[PATCH v2] ASoC: amd: use new ACP dev names for DAI links
by Brady Norander 20 May '25

20 May '25

On AMD SoC platforms with an ACP2x gpu ip block (such as stoneyridge), the amdgpu driver will create several platform devices for the ACP ASoC driver to communicate with the ACP hardware block on the gpu. These platform devices include dma for audio and one or multiple i2s interfaces. The amdgpu driver has always created these platform devices with automatic ids. The ASoC machine drives hardcode the platform device name. This creates an issue where if the ACP platform devices are not the first to be created, the ids can be different to what the machine drivers expect, causing them to not find the ACP platform devices and failing to load. Switch to using static ids for these ACP platform devices so that the names never change. Depends on patch: drm/amdgpu: use static ids for ACP platform devs [1] [1] https://lore.kernel.org/all/20250325210517.2097188-1-bradynorander@gmail.co… Signed-off-by: Brady Norander <bradynorander(a)gmail.com> --- v2: rewrite commit message to better describe the issue --- sound/soc/amd/acp-da7219-max98357a.c | 8 ++++---- sound/soc/amd/acp-es8336.c | 4 ++-- sound/soc/amd/acp-rt5645.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/soc/amd/acp-da7219-max98357a.c b/sound/soc/amd/acp-da7219-max98357a.c index 02b04f355ca6..42aa009c4e13 100644 --- a/sound/soc/amd/acp-da7219-max98357a.c +++ b/sound/soc/amd/acp-da7219-max98357a.c @@ -517,11 +517,11 @@ static const struct snd_soc_ops cz_rt5682_dmic1_cap_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(designware2, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2"))); SND_SOC_DAILINK_DEF(designware3, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.3.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.3"))); SND_SOC_DAILINK_DEF(dlgs, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-DLGS7219:00", "da7219-hifi"))); @@ -533,7 +533,7 @@ SND_SOC_DAILINK_DEF(adau, DAILINK_COMP_ARRAY(COMP_CODEC("ADAU7002:00", "adau7002-hifi"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link cz_dai_7219_98357[] = { { diff --git a/sound/soc/amd/acp-es8336.c b/sound/soc/amd/acp-es8336.c index 0193b3eae7a6..b16dde0e2987 100644 --- a/sound/soc/amd/acp-es8336.c +++ b/sound/soc/amd/acp-es8336.c @@ -137,11 +137,11 @@ static const struct snd_soc_ops st_es8336_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(codec, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-ESSX8336:00", "ES8316 HiFi"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.1.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link st_dai_es8336[] = { { diff --git a/sound/soc/amd/acp-rt5645.c b/sound/soc/amd/acp-rt5645.c index 72ddad24dbda..11d373169380 100644 --- a/sound/soc/amd/acp-rt5645.c +++ b/sound/soc/amd/acp-rt5645.c @@ -108,15 +108,15 @@ static const struct snd_soc_ops cz_aif1_ops = { }; SND_SOC_DAILINK_DEF(designware1, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.1"))); SND_SOC_DAILINK_DEF(designware2, - DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2.auto"))); + DAILINK_COMP_ARRAY(COMP_CPU("designware-i2s.2"))); SND_SOC_DAILINK_DEF(codec, DAILINK_COMP_ARRAY(COMP_CODEC("i2c-10EC5650:00", "rt5645-aif1"))); SND_SOC_DAILINK_DEF(platform, - DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0.auto"))); + DAILINK_COMP_ARRAY(COMP_PLATFORM("acp_audio_dma.0"))); static struct snd_soc_dai_link cz_dai_rt5650[] = { { -- 2.49.0

2 2

New include guard in seq_event.h breaks DSSI header
by GitHub issues - edited 17 May '25

17 May '25

alsa-project/alsa-lib issue #455 was edited from cannam: Hello! I am one of the original authors of [DSSI](https://dssi.sourceforge.net/), a soft-synth API that was created about 20 years ago. It's not an active project, it was basically "done" by about 2011 but is still used in a number of applications. The DSSI header `dssi.h` includes `<alsa/seq_event.h>` in order to pick up a structure for MIDI-like events. I see that following a report of breakage in #431, a guard was added to seq_event.h in ea8972c to warn against including that header directly. This of course breaks for packagers using `-Werror` builds and the like. The official fix seems to be to include the whole of `<alsa/asoundlib.h>`, and that is what packagers appear to be patching the DSSI header with currently (and I see it is also what the guard does itself after emitting the warning). Unfortunately from the perspective of DSSI as an API, that isn't really a fix at all because all we need is an event structure - there is no other dependency on ALSA as a library and there was never any intention to require linking with ALSA. Probably the historical error was to use an ALSA header at all, and the best option for us might be to duplicate enough of the contents of `seq_event.h` locally to sever the dependency that way. But that would be a significant intervention at this point - I think it would be the first substantive change to `dssi.h` since 2004 so I am wary of the risks in terms of breaking other things. I thought I should first check whether you can suggest a better approach, for example whether you might be open to making it possible (again) to make use of `seq_event.h` specifically without pulling in a dependency on everything else in ALSA. Thank you! Issue URL : https://github.com/alsa-project/alsa-lib/issues/455 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

New include guard in seq_event.h breaks DSSI header
by GitHub issues - opened 17 May '25

17 May '25

alsa-project/alsa-lib issue #455 was opened from cannam: Hello! I am one of the original authors of [DSSI](https://dssi.sourceforge.net/), a soft-synth API that was created about 20 years ago. It's not an active project, it was basically "done" by about 2011 but is still used in a number of applications. The DSSI header `dssi.h` includes `<alsa/seq_event.h>` in order to pick up a structure for MIDI-like events. I see that following a report of breakage in #431, a guard was added to seq_event.h in ea8972c to warn against including that header directly. The official fix seems to be to include the whole of `<alsa/asoundlib.h>`, and that is what packagers appear to be patching the DSSI header with currently (and I see it is also what the guard does itself after emitting the warning). Unfortunately from the perspective of DSSI as an API, that isn't really a fix at all because all we need is an event structure - there is no other dependency on ALSA as a library and there was never any intention to require linking with ALSA. Probably the historical error was to use an ALSA header at all, and the best option for us might be to duplicate enough of the contents of `seq_event.h` locally to sever the dependency that way. But I thought I should first check whether you can suggest a better approach, for example whether you might be open to making it possible (again) to make use of `seq_event.h` specifically without pulling in a dependency on everything else in ALSA. Thank you! Issue URL : https://github.com/alsa-project/alsa-lib/issues/455 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[GIT PULL] ASoC fixes for v6.15-rc6
by Mark Brown 16 May '25

16 May '25

The following changes since commit 92a09c47464d040866cf2b4cd052bc60555185fb: Linux 6.15-rc5 (2025-05-04 13:55:04 -0700) are available in the Git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-fix-v6.15-rc6 for you to fetch changes up to 7dd7f39fce0022b386ef1ea5ffef92ecc7dfc6af: ASoC: SOF: Intel: hda: Fix UAF when reloading module (2025-05-14 16:34:48 +0200) ---------------------------------------------------------------- ASoC: Fixes for v6.15 A collection of driver specific fixes that built up over the past few weeks, plus one core patch which fixes handling of topology files where some DAI names are substrings of others. ---------------------------------------------------------------- Arnd Bergmann (1): ASoC: mediatek: mt8188-mt6359: select CONFIG_SND_SOC_MT6359_ACCDET Kai Vehmanen (1): ASoc: SOF: topology: connect DAI to a single DAI link Nícolas F. R. A. Prado (1): ASoC: mediatek: mt8188-mt6359: Depend on MT6359_ACCDET set or disabled Peter Ujfalusi (3): ASoC: SOF: ipc4-control: Use SOF_CTRL_CMD_BINARY as numid for bytes_ext ASoC: SOF: ipc4-pcm: Delay reporting is only supported for playback direction ASoC: SOF: Intel: hda-bus: Use PIO mode on ACE2+ platforms Tavian Barnes (1): ASoC: SOF: Intel: hda: Fix UAF when reloading module sound/soc/mediatek/Kconfig | 1 + sound/soc/sof/intel/hda-bus.c | 2 +- sound/soc/sof/intel/hda.c | 16 +++++++++++++++- sound/soc/sof/ipc4-control.c | 11 ++++++++++- sound/soc/sof/ipc4-pcm.c | 3 ++- sound/soc/sof/topology.c | 18 ++++++++++++++---- 6 files changed, 43 insertions(+), 8 deletions(-)

2 1

restore auto-mute mode for Dell Chrome platform
by Kailang 16 May '25

16 May '25

Hi Takashi, Attach patch was approved by Google guy. BR, Kailang

2 1

[PATCH 1/1] bat: Fix buffer time configuration
by Alexander Stein 16 May '25

16 May '25

By swapping time configuration some hardware constraints can be supported. Fixes the error: Set parameter to device error: buffer time: 500000 hw:tqmtlv320aic32: Invalid argument(-22) Signed-off-by: Alexander Stein <alexander.stein(a)ew.tq-group.com> --- Our common 'alsabat -Dhw:tqmtlv320aic32 -f S16_LE -c 2 -r 44100 -F 997:500' failed ona i.MX95 based platform, while it worked flawlessly on others, e.g. i.MX8M Plus. Upon searching I stumbled across [1], which this patch is inspired/based on. [1] https://github.com/arkq/bluez-alsa/pull/290/commits/da78b82ff77310093b4b4a9… --- bat/alsa.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/bat/alsa.c b/bat/alsa.c index 67489c4..457e79a 100644 --- a/bat/alsa.c +++ b/bat/alsa.c @@ -221,23 +221,23 @@ static int set_snd_pcm_params(struct bat *bat, struct pcm_container *sndpcm) period_time = buffer_time / DIV_BUFFERTIME; - /* Set buffer time and period time */ - err = snd_pcm_hw_params_set_buffer_time_near(sndpcm->handle, - params, &buffer_time, 0); + /* Set period time and buffer time */ + err = snd_pcm_hw_params_set_period_time_near(sndpcm->handle, + params, &period_time, 0); if (err < 0) { fprintf(bat->err, _("Set parameter to device error: ")); - fprintf(bat->err, _("buffer time: %d %s: %s(%d)\n"), - buffer_time, + fprintf(bat->err, _("period time: %d %s: %s(%d)\n"), + period_time, device_name, snd_strerror(err), err); return err; } - err = snd_pcm_hw_params_set_period_time_near(sndpcm->handle, - params, &period_time, 0); + err = snd_pcm_hw_params_set_buffer_time_near(sndpcm->handle, + params, &buffer_time, 0); if (err < 0) { fprintf(bat->err, _("Set parameter to device error: ")); - fprintf(bat->err, _("period time: %d %s: %s(%d)\n"), - period_time, + fprintf(bat->err, _("buffer time: %d %s: %s(%d)\n"), + buffer_time, device_name, snd_strerror(err), err); return err; } -- 2.43.0

2 2

Device rename regression fixes
by GitHub pull_request - opened 15 May '25

15 May '25

alsa-project/alsa-ucm-conf pull request #563 was opened from jhovold: A recent change renaming device sections introduced a name collision which broke the internal microphones on the Lenovo ThinkPad X13s. A number of jack hw mute and conflicting devices properties are now also referring to non-existing devices. Please consider doing a bug fix release as soon as possible to address the X13s regression in v1.2.14. Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/563 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/563.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

MIDI 2.0 Network UDP server/client programs for ALSA
by Takashi Iwai 14 May '25

14 May '25

Hi, I recently wrote a set of small programs for the new Network MIDI 2.0 UDP transport with ALSA sequencer / rawmidi API, based on v1.0 spec. The current version (v0.3) is found at: https://github.com/tiwai/amidi2net A network server can be invoked simply via: % amidi2net-server and this will create an ALSA sequencer client/port. This ALSA sequencer port can be connected by any other ALSA sequencer programs or devices. The server opens a UDP port, so that it can be connected by a client on another machine on the net, e.g.: % amidi2net-client -l amidi2net which creates an ALSA sequencer client/port similarly, and this can be connected by other apps, too. After the network connection, server and client can pass the UMP data between them freely, so they work as a bridge or hub for applications on both machines. Some details are found in README and man pages. For the builds, you'll need openssl and avahi devel packages. (It allows to build without those, but basic functions will be missing.) As it's a quite initial version, there can be bugs and subject to change. But the stuff seems working stably. Feel free to reach me if you find any issues. thanks, Takashi

1 0