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

Dell Precision 3571: DMIC not detected by SOF driver, silent mic under Linux, works in Windows
by Adam Larios 08 Apr '25

08 Apr '25

*System*: Dell Precision 3571 Realtek ALC3204 codec Intel Alder Lake (SOF platform) *Symptoms*: Internal mic is silent or muffled in all Linux applications Works perfectly in Windows SOF driver loads correctly with firmware sof-adl.ri and topology sof-hda-generic.tplg But dmesg shows: sof-audio-pci-intel-tgl 0000:00:1f.3: DMICs detected in NHLT tables: 0 No working audio input nodes exposed in PipeWire *Tested*: - Ubuntu 24.04 with kernel 6.8.0-57-generic - snd-intel-dspcfg.dsp_driver=3 set - PulseAudio and PipeWire backends - alsa-base.conf overrides for model options - hdajackretask pin remapping - SOF firmware and topology confirmed present *Conclusion*: Firmware/ACPI likely missing DMIC NHLT entry; requesting kernel quirk or guidance

1 0

[PATCH v1] ALSA: hda/tas2781: Create a common header for both spi and i2c tas2781 hda driver
by Shenghao Ding 08 Apr '25

08 Apr '25

Move the common macro definition of kcontrols into a common header. Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- v1: - revise the year of spi and i2c tas2781 hda drivers. - Create a common header for both spi and i2c tas2781 hda driver to define the common macros and declare the common functions. --- sound/pci/hda/tas2781_hda.h | 42 +++++++++++++++++++++++++++++++++ sound/pci/hda/tas2781_hda_i2c.c | 29 ++--------------------- sound/pci/hda/tas2781_hda_spi.c | 35 ++------------------------- 3 files changed, 46 insertions(+), 60 deletions(-) create mode 100644 sound/pci/hda/tas2781_hda.h diff --git a/sound/pci/hda/tas2781_hda.h b/sound/pci/hda/tas2781_hda.h new file mode 100644 index 000000000000..c57909c0ed65 --- /dev/null +++ b/sound/pci/hda/tas2781_hda.h @@ -0,0 +1,42 @@ +/* SPDX-License-Identifier: GPL-2.0-only + * + * HDA audio driver for Texas Instruments TAS2781 smart amp + * + * Copyright (C) 2025 Texas Instruments, Inc. + */ +#ifndef __TAS2781_HDA_H__ +#define __TAS2781_HDA_H__ + +/* + * No standard control callbacks for SNDRV_CTL_ELEM_IFACE_CARD + * Define two controls, one is Volume control callbacks, the other is + * flag setting control callbacks. + */ + +/* Volume control callbacks for tas2781 */ +#define ACARD_SINGLE_RANGE_EXT_TLV(xname, xreg, xshift, xmin, xmax, xinvert, \ + xhandler_get, xhandler_put, tlv_array) { \ + .iface = SNDRV_CTL_ELEM_IFACE_CARD, .name = (xname), \ + .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \ + SNDRV_CTL_ELEM_ACCESS_READWRITE, \ + .tlv.p = (tlv_array), \ + .info = snd_soc_info_volsw, \ + .get = xhandler_get, .put = xhandler_put, \ + .private_value = (unsigned long)&(struct soc_mixer_control) { \ + .reg = xreg, .rreg = xreg, \ + .shift = xshift, .rshift = xshift,\ + .min = xmin, .max = xmax, .invert = xinvert, \ + } \ +} + +/* Flag control callbacks for tas2781 */ +#define ACARD_SINGLE_BOOL_EXT(xname, xdata, xhandler_get, xhandler_put) { \ + .iface = SNDRV_CTL_ELEM_IFACE_CARD, \ + .name = xname, \ + .info = snd_ctl_boolean_mono_info, \ + .get = xhandler_get, \ + .put = xhandler_put, \ + .private_value = xdata, \ +} + +#endif diff --git a/sound/pci/hda/tas2781_hda_i2c.c b/sound/pci/hda/tas2781_hda_i2c.c index 29dc4f500580..9d94ae5fcfe0 100644 --- a/sound/pci/hda/tas2781_hda_i2c.c +++ b/sound/pci/hda/tas2781_hda_i2c.c @@ -2,7 +2,7 @@ // // TAS2781 HDA I2C driver // -// Copyright 2023 - 2024 Texas Instruments, Inc. +// Copyright 2023 - 2025 Texas Instruments, Inc. // // Author: Shenghao Ding <shenghao-ding(a)ti.com> // Current maintainer: Baojun Xu <baojun.xu(a)ti.com> @@ -30,35 +30,10 @@ #include "hda_component.h" #include "hda_jack.h" #include "hda_generic.h" +#include "tas2781_hda.h" #define TASDEVICE_SPEAKER_CALIBRATION_SIZE 20 -/* No standard control callbacks for SNDRV_CTL_ELEM_IFACE_CARD - * Define two controls, one is Volume control callbacks, the other is - * flag setting control callbacks. - */ - -/* Volume control callbacks for tas2781 */ -#define ACARD_SINGLE_RANGE_EXT_TLV(xname, xreg, xshift, xmin, xmax, xinvert, \ - xhandler_get, xhandler_put, tlv_array) \ -{ .iface = SNDRV_CTL_ELEM_IFACE_CARD, .name = (xname),\ - .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ |\ - SNDRV_CTL_ELEM_ACCESS_READWRITE,\ - .tlv.p = (tlv_array), \ - .info = snd_soc_info_volsw, \ - .get = xhandler_get, .put = xhandler_put, \ - .private_value = (unsigned long)&(struct soc_mixer_control) \ - {.reg = xreg, .rreg = xreg, .shift = xshift, \ - .rshift = xshift, .min = xmin, .max = xmax, \ - .invert = xinvert} } - -/* Flag control callbacks for tas2781 */ -#define ACARD_SINGLE_BOOL_EXT(xname, xdata, xhandler_get, xhandler_put) \ -{ .iface = SNDRV_CTL_ELEM_IFACE_CARD, .name = xname, \ - .info = snd_ctl_boolean_mono_info, \ - .get = xhandler_get, .put = xhandler_put, \ - .private_value = xdata } - enum calib_data { R0_VAL = 0, INV_R0, diff --git a/sound/pci/hda/tas2781_hda_spi.c b/sound/pci/hda/tas2781_hda_spi.c index 399f2e4c3b62..c6be2be1b53e 100644 --- a/sound/pci/hda/tas2781_hda_spi.c +++ b/sound/pci/hda/tas2781_hda_spi.c @@ -2,7 +2,7 @@ // // TAS2781 HDA SPI driver // -// Copyright 2024 Texas Instruments, Inc. +// Copyright 2024 - 2025 Texas Instruments, Inc. // // Author: Baojun Xu <baojun.xu(a)ti.com> @@ -38,38 +38,7 @@ #include "hda_component.h" #include "hda_jack.h" #include "hda_generic.h" - -/* - * No standard control callbacks for SNDRV_CTL_ELEM_IFACE_CARD - * Define two controls, one is Volume control callbacks, the other is - * flag setting control callbacks. - */ - -/* Volume control callbacks for tas2781 */ -#define ACARD_SINGLE_RANGE_EXT_TLV(xname, xreg, xshift, xmin, xmax, xinvert, \ - xhandler_get, xhandler_put, tlv_array) { \ - .iface = SNDRV_CTL_ELEM_IFACE_CARD, .name = (xname), \ - .access = SNDRV_CTL_ELEM_ACCESS_TLV_READ | \ - SNDRV_CTL_ELEM_ACCESS_READWRITE, \ - .tlv.p = (tlv_array), \ - .info = snd_soc_info_volsw, \ - .get = xhandler_get, .put = xhandler_put, \ - .private_value = (unsigned long)&(struct soc_mixer_control) { \ - .reg = xreg, .rreg = xreg, \ - .shift = xshift, .rshift = xshift,\ - .min = xmin, .max = xmax, .invert = xinvert, \ - } \ -} - -/* Flag control callbacks for tas2781 */ -#define ACARD_SINGLE_BOOL_EXT(xname, xdata, xhandler_get, xhandler_put) { \ - .iface = SNDRV_CTL_ELEM_IFACE_CARD, \ - .name = xname, \ - .info = snd_ctl_boolean_mono_info, \ - .get = xhandler_get, \ - .put = xhandler_put, \ - .private_value = xdata, \ -} +#include "tas2781_hda.h" struct tas2781_hda { struct tasdevice_priv *priv; -- 2.34.1

2 1

ucm2: Qualcomm: add Lenovo ThinkBook 16 support
by GitHub pull_request - opened 08 Apr '25

08 Apr '25

alsa-project/alsa-ucm-conf pull request #543 was opened from jglathe: add a Regex string, seems compatible with Thinkpad T14s Tested-by: Jens Glathe <jens.glathe(a)oldschoolsolutions.biz> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/543 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/543.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

Fireworks Alsa Driver Buffer SIze
by jayt0808＠gmail.com 08 Apr '25

08 Apr '25

Hi I'm using an AudioFire 8a that has 16 channels over the firewire bus and the snd-fireworks alsa firewire driver. In Jack, when I set Frames/Period to anything higher than 64, alsa fails with an error saying Mon Apr 7 22:15:35 2025: ERROR: ALSA: cannot set hardware parameters for capture Mon Apr 7 22:15:35 2025: ERROR: ALSA: cannot configure capture channel I noticed that the output of "aplay -D hw:1,0 --dump-hw-params /dev/zero" indicated the following alsa settings: Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono HW Params of device "hw:1,0": -------------------- ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED FORMAT: S32_LE SUBFORMAT: STD SAMPLE_BITS: 32 FRAME_BITS: [384 512] CHANNELS: [12 16] RATE: [32000 96000] PERIOD_TIME: [250 32000] PERIOD_SIZE: [16 2720] PERIOD_BYTES: [768 131072] PERIODS: [2 341] BUFFER_TIME: (333 170500] BUFFER_SIZE: [32 5456] BUFFER_BYTES: [1536 262144] TICK_TIME: ALL -------------------- aplay: set_params:1371: Sample format non available Available formats: - S32_LE I was concerned that the BUFFER_SIZE was too small to support 16 channels at a 128 Frames/Period size. But when I modded the driver to increase this figure, it did not fix the issue. Anyone have any insight on this issue? Running Ubuntu 24.04 with kernel 6.8.0-57-lowlatency. Everything seems to work fine when I set 64 Frames/Period (except the occasional annoying stuttering that one can expect in that scenario; with a buffer that is too small to support the system load). Thanks Jay

1 0

[PATCH v2] ASoC: dwc: always enable/disable i2s irqs
by Brady Norander 08 Apr '25

08 Apr '25

Commit a42e988 ("ASoC: dwc: add DMA handshake control") changed the behavior of the driver to not enable or disable i2s irqs if using DMA. This breaks platforms such as AMD ACP. Audio playback appears to work but no audio can be heard. Revert to the old behavior by always enabling and disabling i2s irqs while keeping DMA handshake control. Fixes: a42e988 ("ASoC: dwc: add DMA handshake control") Signed-off-by: Brady Norander <bradynorander(a)gmail.com> --- v2: reword commit message to better describe the issue --- sound/soc/dwc/dwc-i2s.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/sound/soc/dwc/dwc-i2s.c b/sound/soc/dwc/dwc-i2s.c index 57b789d7fbed..5b4f20dbf7bb 100644 --- a/sound/soc/dwc/dwc-i2s.c +++ b/sound/soc/dwc/dwc-i2s.c @@ -199,12 +199,10 @@ static void i2s_start(struct dw_i2s_dev *dev, else i2s_write_reg(dev->i2s_base, IRER, 1); - /* I2S needs to enable IRQ to make a handshake with DMAC on the JH7110 SoC */ - if (dev->use_pio || dev->is_jh7110) - i2s_enable_irqs(dev, substream->stream, config->chan_nr); - else + if (!(dev->use_pio || dev->is_jh7110)) i2s_enable_dma(dev, substream->stream); + i2s_enable_irqs(dev, substream->stream, config->chan_nr); i2s_write_reg(dev->i2s_base, CER, 1); } @@ -218,11 +216,12 @@ static void i2s_stop(struct dw_i2s_dev *dev, else i2s_write_reg(dev->i2s_base, IRER, 0); - if (dev->use_pio || dev->is_jh7110) - i2s_disable_irqs(dev, substream->stream, 8); - else + if (!(dev->use_pio || dev->is_jh7110)) i2s_disable_dma(dev, substream->stream); + i2s_disable_irqs(dev, substream->stream, 8); + + if (!dev->active) { i2s_write_reg(dev->i2s_base, CER, 0); i2s_write_reg(dev->i2s_base, IER, 0); -- 2.49.0

1 0

pcm: hw: do not reset tstamp_type in SND_PCM_APPEND mode
by GitHub pull_request - opened 07 Apr '25

07 Apr '25

alsa-project/alsa-lib pull request #450 was opened from kgroeneveld: When the first client of plugins such as dshare open the hw device they set a default tstamp_type in snd_pcm_direct_initialize_slave based on tstamp_type from the config file. But when subsequent clients open the same plugin the snd_pcm_hw_open_fd function clobbers this default. Request URL : https://github.com/alsa-project/alsa-lib/pull/450 Patch URL : https://github.com/alsa-project/alsa-lib/pull/450.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

alsaseq: Fix type check in set_time()
by GitHub pull_request - opened 06 Apr '25

06 Apr '25

alsa-project/alsa-python pull request #17 was opened from ernestask: SeqEvent_set_time() has fallen victim to the inverted get_long1() return value here, erroring out when called with actual integers. Request URL : https://github.com/alsa-project/alsa-python/pull/17 Patch URL : https://github.com/alsa-project/alsa-python/pull/17.patch Repository URL: https://github.com/alsa-project/alsa-python

1 0

envy24control: port to GTK 3
by GitHub pull_request - opened 05 Apr '25

05 Apr '25

alsa-project/alsa-tools pull request #35 was opened from andreas56: This is a port envy24control from GTK 2 to GTK 3. Note: There is another very similar port in #27, but that one isn't quite finished. I did my port before noticing that there already was one, but I have compared them now to check that I didn't miss anything. My version has more changes, as I wanted to avoid using deprecated GTK functions. It also fixes the rendering of the level meters and optimizes it a bit so the CPU load isn't much higher than it was in GTK 2. Note 2: the fix from #31 is included in this pull request, as it is necessary for the spin buttons to work in GTK 3. Note 3: my other envy24control pull requests are not included here, as they are not related to GTK 3. #29 will probably cause merge conflicts with this one, but I will fix them if you decide to merge any of the pull requests. Request URL : https://github.com/alsa-project/alsa-tools/pull/35 Patch URL : https://github.com/alsa-project/alsa-tools/pull/35.patch Repository URL: https://github.com/alsa-project/alsa-tools

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device are essential. If the functionality cannot be handled with current ALSA audio driver, go to paragraphs bellow. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

ALC4080 - general discussion (driver support)
by GitHub issues - edited 04 Apr '25

04 Apr '25

alsa-project/alsa-ucm-conf issue #541 was edited from perexg: UCM cannot add basic functionalities when the driver does not expose them. I already explained situation in [kernel bugzilla](https://bugzilla.kernel.org/show_bug.cgi?id=218913). **Note** This issue is for the kernel driver related problems. If the driver works and something is missing in UCM configuration, please, create a new issue in this tracker. It may be difficult to distinguish the right place, but if the developers redirected you here, follow the instructions bellow. **For issues like** 1. jack functionality assignment is unstable (jack functionality is not fixed - e.g. changes on warm reboot from windows) 2. low microphone volume (which cannot be controlled using native ALSA mixer controls) 3. sound is activated only after some magic plug/unplug sequence **Further steps** Try to analyze the audio driver using direct ALSA API. See [DEBUG.md](https://github.com/alsa-project/alsa-ucm-conf/blob/master/ucm2/DE…. Very nice report is in #528. Please, use it as a reference what to do. Developers usually do not have exact hardware, so observations describing which ALSA PCM device, which ALSA Mixer control, which ALSA Jack control can be used for given playback/capture device are essential. Reverse engineering of the Windows driver. Capture USB communication and save it to a file which can be replayed by [wireshark](https://www.wireshark.org). Try to write an explanation including timing (what happened in given time slots). Driver reports should go to [kernel bugzilla](https://bugzilla.kernel.org). Add a comment with a link here. You may also push hardware vendors to create USB device which fully follows the USB audio specification, so the ALSA driver will work out-of-box (without "quirks"). **Documentation links** The documentation is not complete. Realtek support is generally very limited to provide full specification to their codecs / audio chips those years. They are providing details only to hardware vendors with a contract. If you know more, please, let us know. - [ALC4080 block scheme](https://bugzilla.kernel.org/attachment.cgi?id=306370) - [ALC4080 datasheet](https://bugzilla.kernel.org/attachment.cgi?id=307224) **Some details** ALC4080 is USB codec, thus it exposes functionality through the USB bus. The block scheme is nice to know internals, but look to the MCU paragraph in the datasheet: ``` 2.1.2. Micro Controller Unit - On-chip high-performance and low-power MCU - Ultra-low power consumption when MCU is at idle state - MCU controls connection to USB bus for re-enumeration without hot-plug - Internal programmable memory support for customized audio function - Watchdog control for MCU reset and interrupt - Configurable VID (Vendor ID), PID (Product ID), and serial number string ``` This means, that the internal firmware for this MCU unit can change the behaviour of audio hardware. Usually, the firmware is vendor specific. The USB audio hardware should comply with the USB Audio specification (refer https://www.usb.org/). The control units parsed by the ALSA driver can be obtained using 'cat /proc/asound/cardX/usbmixer' command (replace X with the correct ALSA card number). Those units are mapped to the standard mixer controls. My guess is that the firmware is not complaint with the USB audio specification and some functionality is controlled using specific USB handshake (data blocks). Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/541 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0