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

[PATCH] ALSA: hda - Add new driver for HDA controllers listed via ACPI
by Daniel Dadap 21 May '25

21 May '25

Some systems expose HD-Audio controllers via objects in the ACPI tables which encapsulate the controller's interrupt and the base address for the HDA registers in an ACPI _CRS object, for example, as listed in this ACPI table dump excerpt: Device (HDA0) { Name (_HID, "NVDA2014") // _HID: Hardware ID ... Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0x36078000, // Address Base 0x00008000, // Address Length ) Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) { 0x0000021E, } }) } Add support for HDA controllers discovered through ACPI, including support for some platforms which expose such HDA controllers on NVIDIA SoCs. This is done with a new driver which uses existing infrastructure for extracting resource information from _CRS objects and plumbs the parsed resource information through to the existing HDA infrastructure to enable HD-Audio functionality on such devices. Although this driver is in the sound/pci/hda/ directory, it targets devices which are not actually enumerated on the PCI bus. This is because it depends upon the Intel "Azalia" infrastructure which has traditionally been used for PCI-based devices. Signed-off-by: Daniel Dadap <ddadap(a)nvidia.com> --- sound/pci/hda/Kconfig | 11 ++ sound/pci/hda/Makefile | 2 + sound/pci/hda/hda_acpi.c | 316 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 329 insertions(+) create mode 100644 sound/pci/hda/hda_acpi.c diff --git a/sound/pci/hda/Kconfig b/sound/pci/hda/Kconfig index 9c427270ff4f..436dfd182a09 100644 --- a/sound/pci/hda/Kconfig +++ b/sound/pci/hda/Kconfig @@ -42,6 +42,17 @@ config SND_HDA_TEGRA To compile this driver as a module, choose M here: the module will be called snd-hda-tegra. +config SND_HDA_ACPI + tristate "HD Audio ACPI" + depends on ACPI + select SND_HDA + help + Say Y here to include support for Azalia-compatible HDA controllers + which are advertised via ACPI objects. + + To compile this driver as a module, choose M here: the module + will be called snd-hda-acpi. + if SND_HDA config SND_HDA_HWDEP diff --git a/sound/pci/hda/Makefile b/sound/pci/hda/Makefile index 210c406dfbc5..7a7c16d705dd 100644 --- a/sound/pci/hda/Makefile +++ b/sound/pci/hda/Makefile @@ -1,6 +1,7 @@ # SPDX-License-Identifier: GPL-2.0 snd-hda-intel-y := hda_intel.o snd-hda-tegra-y := hda_tegra.o +snd-hda-acpi-y := hda_acpi.o snd-hda-codec-y := hda_bind.o hda_codec.o hda_jack.o hda_auto_parser.o hda_sysfs.o snd-hda-codec-y += hda_controller.o @@ -80,3 +81,4 @@ obj-$(CONFIG_SND_HDA_SCODEC_TAS2781_SPI) += snd-hda-scodec-tas2781-spi.o # when built in kernel obj-$(CONFIG_SND_HDA_INTEL) += snd-hda-intel.o obj-$(CONFIG_SND_HDA_TEGRA) += snd-hda-tegra.o +obj-$(CONFIG_SND_HDA_ACPI) += snd-hda-acpi.o diff --git a/sound/pci/hda/hda_acpi.c b/sound/pci/hda/hda_acpi.c new file mode 100644 index 000000000000..736eac59eaa0 --- /dev/null +++ b/sound/pci/hda/hda_acpi.c @@ -0,0 +1,316 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * ALSA driver for ACPI-based HDA Controllers. + */ + +#include <linux/module.h> +#include <linux/platform_device.h> +#include <linux/acpi.h> + +#include <sound/hda_codec.h> + +#include "hda_controller.h" + +struct hda_acpi { + struct azx azx; + struct snd_card *card; + struct platform_device *pdev; + void __iomem *regs; + struct work_struct probe_work; + const struct hda_data *data; +}; + +/** + * struct hda_data - Optional device-specific data + * @short_name: Used for the ALSA card name; defaults to KBUILD_MODNAME + * @long_name: Used for longer description; defaults to short_name + * @flags: Passed to &azx->driver_caps + * + * A pointer to a record of this type may be stored in the + * &acpi_device_id->driver_data field of an ACPI match table entry in order to + * customize the naming and behavior of a particular device. All fields are + * optional and sensible defaults will be selected in their absence. + */ +struct hda_data { + const char *short_name; + const char *long_name; + unsigned long flags; +}; + +static int hda_acpi_dev_disconnect(struct snd_device *device) +{ + struct azx *chip = device->device_data; + + chip->bus.shutdown = 1; + return 0; +} + +static int hda_acpi_dev_free(struct snd_device *device) +{ + struct azx *azx = device->device_data; + struct hda_acpi *hda = container_of(azx, struct hda_acpi, azx); + + cancel_work_sync(&hda->probe_work); + if (azx_bus(azx)->chip_init) { + azx_stop_all_streams(azx); + azx_stop_chip(azx); + } + + azx_free_stream_pages(azx); + azx_free_streams(azx); + snd_hdac_bus_exit(azx_bus(azx)); + + return 0; +} + +static int hda_acpi_init(struct hda_acpi *hda) +{ + struct hdac_bus *bus = azx_bus(&hda->azx); + struct snd_card *card = hda->azx.card; + struct device *dev = &hda->pdev->dev; + struct azx *azx = &hda->azx; + struct resource *res; + unsigned short gcap; + const char *sname, *lname; + int err, irq; + + /* The base address for the HDA registers and the interrupt are wrapped + * in an ACPI _CRS object which can be parsed by platform_get_irq() and + * devm_platform_get_and_ioremap_resource() */ + + irq = platform_get_irq(hda->pdev, 0); + if (irq < 0) + return irq; + + hda->regs = devm_platform_get_and_ioremap_resource(hda->pdev, 0, &res); + if (IS_ERR(hda->regs)) + return PTR_ERR(hda->regs); + + bus->remap_addr = hda->regs; + bus->addr = res->start; + + err = devm_request_irq(dev, irq, azx_interrupt, + IRQF_SHARED, KBUILD_MODNAME, azx); + if (err) { + dev_err(dev, "unable to request IRQ %d, disabling device\n", irq); + return err; + } + bus->irq = irq; + bus->dma_stop_delay = 100; + card->sync_irq = bus->irq; + + gcap = azx_readw(azx, GCAP); + dev_dbg(dev, "chipset global capabilities = 0x%x\n", gcap); + + azx->align_buffer_size = 1; + + azx->capture_streams = (gcap >> 8) & 0x0f; + azx->playback_streams = (gcap >> 12) & 0x0f; + + azx->capture_index_offset = 0; + azx->playback_index_offset = azx->capture_streams; + azx->num_streams = azx->playback_streams + azx->capture_streams; + + err = azx_init_streams(azx); + if (err < 0) { + dev_err(dev, "failed to initialize streams: %d\n", err); + return err; + } + + err = azx_alloc_stream_pages(azx); + if (err < 0) { + dev_err(dev, "failed to allocate stream pages: %d\n", err); + return err; + } + + azx_init_chip(azx, 1); + + if (!bus->codec_mask) { + dev_err(dev, "no codecs found!\n"); + return -ENODEV; + } + + strscpy(card->driver, "hda-acpi", sizeof(card->driver)); + + sname = hda->data->short_name ? hda->data->short_name : KBUILD_MODNAME; + + if (strlen(sname) > sizeof(card->shortname)) + dev_info(dev, "truncating shortname for card %s\n", sname); + strscpy(card->shortname, sname, sizeof(card->shortname)); + + lname = hda->data->long_name ? hda->data->long_name : sname; + + snprintf(card->longname, sizeof(card->longname), + "%s at 0x%lx irq %i", lname, bus->addr, bus->irq); + + return 0; +} + +static void hda_acpi_probe_work(struct work_struct *work) +{ + struct hda_acpi *hda = container_of(work, struct hda_acpi, probe_work); + struct azx *chip = &hda->azx; + int err; + + err = hda_acpi_init(hda); + if (err < 0) + return; + + err = azx_probe_codecs(chip, 8); + if (err < 0) + return; + + err = azx_codec_configure(chip); + if (err < 0) + return; + + err = snd_card_register(chip->card); + if (err < 0) + return; + + chip->running = 1; +} + +static int hda_acpi_create(struct hda_acpi *hda) +{ + static const struct snd_device_ops ops = { + .dev_disconnect = hda_acpi_dev_disconnect, + .dev_free = hda_acpi_dev_free, + }; + static const struct hda_controller_ops null_ops; + struct azx *azx = &hda->azx; + int err; + + mutex_init(&azx->open_mutex); + azx->card = hda->card; + INIT_LIST_HEAD(&azx->pcm_list); + + azx->ops = &null_ops; + azx->driver_caps = hda->data->flags; + azx->driver_type = hda->data->flags & 0xff; + azx->codec_probe_mask = -1; + + err = azx_bus_init(azx, NULL); + if (err < 0) + return err; + + err = snd_device_new(hda->card, SNDRV_DEV_LOWLEVEL, &hda->azx, &ops); + if (err < 0) { + dev_err(&hda->pdev->dev, "Error creating device\n"); + return err; + } + + return 0; +} + +static int hda_acpi_probe(struct platform_device *pdev) +{ + struct hda_acpi *hda; + int err; + + hda = devm_kzalloc(&pdev->dev, sizeof(*hda), GFP_KERNEL); + if (!hda) + return -ENOMEM; + + hda->pdev = pdev; + hda->data = acpi_device_get_match_data(&pdev->dev); + + err = snd_card_new(&pdev->dev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1, + THIS_MODULE, 0, &hda->card); + if (err < 0) { + dev_err(&pdev->dev, "Error creating card!\n"); + return err; + } + + INIT_WORK(&hda->probe_work, hda_acpi_probe_work); + + err = hda_acpi_create(hda); + if (err < 0) + goto out_free; + hda->card->private_data = &hda->azx; + + dev_set_drvdata(&pdev->dev, hda->card); + + schedule_work(&hda->probe_work); + + return 0; + +out_free: + snd_card_free(hda->card); + return err; +} + +static void hda_acpi_remove(struct platform_device *pdev) +{ + snd_card_free(dev_get_drvdata(&pdev->dev)); +} + +static void hda_acpi_shutdown(struct platform_device *pdev) +{ + struct snd_card *card = dev_get_drvdata(&pdev->dev); + struct azx *chip; + + if (!card) + return; + chip = card->private_data; + if (chip && chip->running) + azx_stop_chip(chip); +} + +static int __maybe_unused hda_acpi_suspend(struct device *dev) +{ + struct snd_card *card = dev_get_drvdata(dev); + int rc; + + rc = pm_runtime_force_suspend(dev); + if (rc < 0) + return rc; + snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); + + return 0; +} + +static int __maybe_unused hda_acpi_resume(struct device *dev) +{ + struct snd_card *card = dev_get_drvdata(dev); + int rc; + + rc = pm_runtime_force_resume(dev); + if (rc < 0) + return rc; + snd_power_change_state(card, SNDRV_CTL_POWER_D0); + + return 0; +} + +static const struct dev_pm_ops hda_acpi_pm = { + SET_SYSTEM_SLEEP_PM_OPS(hda_acpi_suspend, hda_acpi_resume) +}; + +struct hda_data nvidia_hda_data = { + .short_name = "NVIDIA", + .long_name = "NVIDIA HDA Controller", + .flags = AZX_DCAPS_CORBRP_SELF_CLEAR, +}; + +static const struct acpi_device_id hda_acpi_match[] = { + { .id = "NVDA2014", .driver_data = (uintptr_t) &nvidia_hda_data }, + { .id = "NVDA2015", .driver_data = (uintptr_t) &nvidia_hda_data }, + {}, +}; +MODULE_DEVICE_TABLE(acpi, hda_acpi_match); + +static struct platform_driver hda_acpi_platform_driver = { + .driver = { + .name = KBUILD_MODNAME, + .pm = &hda_acpi_pm, + .acpi_match_table = hda_acpi_match, + }, + .probe = hda_acpi_probe, + .remove = hda_acpi_remove, + .shutdown = hda_acpi_shutdown, +}; +module_platform_driver(hda_acpi_platform_driver); + +MODULE_DESCRIPTION("Driver for ACPI-based HDA Controllers"); +MODULE_LICENSE("GPL v2"); -- 2.39.5

2 14

Behringer UMC404HD volume low, "cannot load mixer controls: No such file or directory", and erroneously remapped channels
by GitHub issues - opened 21 May '25

21 May '25

alsa-project/alsa-ucm-conf issue #564 was opened from mikelpr: alright so this is a weird one: I've got a fedora install and two openSUSE installs, one older but dist upgraded to today and a newer one, also dist upgraded to today, and the fedora is updated too. now, on the fedora install and the newer openSUSE install the volume on my UMC404HD does not reach what is 100% on the older suse install and on Windows. it's more like 50%. I've tried using alsamixer but it fails when selecting the soundcard with `cannot load mixer controls: No such file or directory`. possibly noteworthy is that I share home dir on the suse installs so it's not user config. I also did a diff on /etc between both installs and could find nothing that seemed out of the ordinary. also, at some point an update was pushed that remapped channels from FL FR RL RR to Line A and Line B, two channels each, and on the Direct profile to FL FC FR LFE. I've got no strong opinions on the Line A/B split on the default profile but definitely FL FC FR LFE is wrong for this card. please lmk what data to gather Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/564 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

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