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

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

16 Sep '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

5 6

ALSAfirewire broken
by M. Armsby 04 Sep '25

04 Sep '25

Hello everyone. 2 Firewire problems with ALSAfirewire. 1. Firewire Midi was working fine with kernel 5.10 with Reaper. Then obviously a lot changed with the Firewire Stack. The midi output from Reaper has not changed according to it's developer - Justin. The problem is direct ALSA-Midi. We tested the midi app from www.alsa-project.org/alsa-doc/alsa-lib/_2test_2rawmidi_8c-example.html#a0 yesterday and it freezes Debian and just breaks Arch with kernel 6.15 Thread at Reaper Bugs forum: https://forum.cockos.com/showthread.php?t=300278 Has low level ALSA-Midi API changed? 2. If using Pipewire-Jack with ALSAfirewire the Reaper midi output works fine but unfortunately Pipewire adds 90ms delay when playing back through any Firewire interface compared with an onboard soundcard. The pipewire dev Wim Tayman, says it's ALSAfirewire fault but I proved it is not - see thread: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues?show=eyJpaWQiOiI0… The ALSA recording and playback is confirmed by my tests to be working under 10ms RTT with Echo, Motu and Bebop interfaces. Is this problem related to first? Low level communication error? Cheers - and let me know if I can help in any way, although I'm not a programmer. P. S. I hope you can read my post as I loaded up K-9 eMail client so as to deliver text only. -- Martin Armsby

3 11

[PATCH v1] ASoC: tas2781: Normalize the volume kcontrol name
by Baojun Xu 13 Aug '25

13 Aug '25

As more devices become supported, add "tas2781" as a suffix before the TLV name, correct the DVC step, and normalize the volume kcontrol name. Signed-off-by: Baojun Xu <baojun.xu(a)ti.com> --- include/sound/tas2781-tlv.h | 6 ++++-- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 4 ++-- sound/hda/codecs/side-codecs/tas2781_hda_spi.c | 5 +++-- sound/soc/codecs/tas2781-i2c.c | 8 ++++---- 4 files changed, 13 insertions(+), 10 deletions(-) diff --git a/include/sound/tas2781-tlv.h b/include/sound/tas2781-tlv.h index d87263e43fdb..38b8f828a353 100644 --- a/include/sound/tas2781-tlv.h +++ b/include/sound/tas2781-tlv.h @@ -15,7 +15,9 @@ #ifndef __TAS2781_TLV_H__ #define __TAS2781_TLV_H__ -static const __maybe_unused DECLARE_TLV_DB_SCALE(dvc_tlv, -10000, 100, 0); -static const __maybe_unused DECLARE_TLV_DB_SCALE(amp_vol_tlv, 1100, 50, 0); +static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2781_dvc_tlv, + -10000, 50, 0); +static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2781_amp_tlv, + 1100, 50, 0); #endif diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index a0b132681804..6ec93b27aa7f 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -265,9 +265,9 @@ static const struct snd_kcontrol_new tas2770_snd_controls[] = { }; static const struct snd_kcontrol_new tas2781_snd_controls[] = { - ACARD_SINGLE_RANGE_EXT_TLV("Speaker Analog Gain", TAS2781_AMP_LEVEL, + ACARD_SINGLE_RANGE_EXT_TLV("Speaker Analog Volume", TAS2781_AMP_LEVEL, 1, 0, 20, 0, tas2781_amp_getvol, - tas2781_amp_putvol, amp_vol_tlv), + tas2781_amp_putvol, tas2781_amp_tlv), ACARD_SINGLE_BOOL_EXT("Speaker Force Firmware Load", 0, tas2781_force_fwload_get, tas2781_force_fwload_put), }; diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_spi.c b/sound/hda/codecs/side-codecs/tas2781_hda_spi.c index 09a5d0f131b2..b4664a696bad 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_spi.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_spi.c @@ -494,9 +494,10 @@ static int tas2781_force_fwload_put(struct snd_kcontrol *kcontrol, static struct snd_kcontrol_new tas2781_snd_ctls[] = { ACARD_SINGLE_RANGE_EXT_TLV(NULL, TAS2781_AMP_LEVEL, 1, 0, 20, 0, - tas2781_amp_getvol, tas2781_amp_putvol, amp_vol_tlv), + tas2781_amp_getvol, tas2781_amp_putvol, tas2781_amp_tlv), ACARD_SINGLE_RANGE_EXT_TLV(NULL, TAS2781_DVC_LVL, 0, 0, 200, 1, - tas2781_digital_getvol, tas2781_digital_putvol, dvc_tlv), + tas2781_digital_getvol, tas2781_digital_putvol, + tas2781_dvc_tlv), ACARD_SINGLE_BOOL_EXT(NULL, 0, tas2781_force_fwload_get, tas2781_force_fwload_put), }; diff --git a/sound/soc/codecs/tas2781-i2c.c b/sound/soc/codecs/tas2781-i2c.c index 9f4d965a1335..a51f20cd869a 100644 --- a/sound/soc/codecs/tas2781-i2c.c +++ b/sound/soc/codecs/tas2781-i2c.c @@ -908,12 +908,12 @@ static const struct snd_kcontrol_new tasdevice_cali_controls[] = { }; static const struct snd_kcontrol_new tas2781_snd_controls[] = { - SOC_SINGLE_RANGE_EXT_TLV("Speaker Analog Gain", TAS2781_AMP_LEVEL, + SOC_SINGLE_RANGE_EXT_TLV("Speaker Analog Volume", TAS2781_AMP_LEVEL, 1, 0, 20, 0, tas2781_amp_getvol, - tas2781_amp_putvol, amp_vol_tlv), - SOC_SINGLE_RANGE_EXT_TLV("Speaker Digital Gain", TAS2781_DVC_LVL, + tas2781_amp_putvol, tas2781_amp_tlv), + SOC_SINGLE_RANGE_EXT_TLV("Speaker Digital Volume", TAS2781_DVC_LVL, 0, 0, 200, 1, tas2781_digital_getvol, - tas2781_digital_putvol, dvc_tlv), + tas2781_digital_putvol, tas2781_dvc_tlv), }; static const struct snd_kcontrol_new tas2781_cali_controls[] = { -- 2.43.0

2 3

[PATCH v1] ALSA: hda: Fix the wrong register was used for DVC of TAS2770
by Baojun Xu 05 Aug '25

05 Aug '25

The wrong register was used for digital volume control of TAS2770, The definition was changed, and usage was also updated. Fixes: ab29b3460c5c ("ALSA: hda: Add TAS2770 support") Signed-off-by: Baojun Xu <baojun.xu(a)ti.com> --- include/sound/tas2770-tlv.h | 4 ++-- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/tas2770-tlv.h b/include/sound/tas2770-tlv.h index c0bd495b4a07..5518b34abdde 100644 --- a/include/sound/tas2770-tlv.h +++ b/include/sound/tas2770-tlv.h @@ -14,10 +14,10 @@ #ifndef __TAS2770_TLV_H__ #define __TAS2770_TLV_H__ -#define TAS2770_DVC_LEVEL TASDEVICE_REG(0x0, 0x0, 0x17) +#define TAS2770_DVC_LEVEL TASDEVICE_REG(0x0, 0x0, 0x05) #define TAS2770_AMP_LEVEL TASDEVICE_REG(0x0, 0x0, 0x03) -static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_dvc_tlv, 1650, 50, 0); +static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_dvc_tlv, -1000, 50, 0); static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_amp_tlv, 1100, 50, 0); #endif diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index a0b132681804..45ac5e41bd4f 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -260,7 +260,7 @@ static const struct snd_kcontrol_new tas2770_snd_controls[] = { 0, 0, 20, 0, tas2781_amp_getvol, tas2781_amp_putvol, tas2770_amp_tlv), ACARD_SINGLE_RANGE_EXT_TLV("Speaker Digital Volume", TAS2770_DVC_LEVEL, - 0, 0, 31, 0, tas2781_amp_getvol, + 0, 0, 200, 1, tas2781_amp_getvol, tas2781_amp_putvol, tas2770_dvc_tlv), }; -- 2.43.0

2 1

Regression: Microphone broken on Intel Ice Lake with alsa-ucm-conf 1.2.10-150600.3.5.1 (openSUSE Leap 15.6)
by Pablo Scatizza 04 Aug '25

04 Aug '25

Dear ALSA developers, I would like to report a regression affecting the microphone on my laptop using Intel's Ice Lake-LP audio controller with the `sof-hda-dsp` driver. After upgrading `alsa-ucm-conf` to version 1.2.10-150600.3.5.1 (as distributed in openSUSE Leap 15.6), the internal microphone stops working. No capture is possible via `arecord` or any application. The device still shows up in `arecord -l`, but it does not receive audio input. Rolling back to the previous version (1.2.10-150600.1.2) using: sudo zypper install --oldpackage alsa-ucm-conf-1.2.10-150600.1.2.noarch restores full microphone functionality. **System information:** - Distribution: openSUSE Leap 15.6 - Kernel: 6.4.0-150600.23.53-default - Audio device: Intel Corporation Ice Lake-LP Smart Sound Technology Audio Controller (rev 30) - ALSA driver: sof-hda-dsp **Working `arecord -l` output with the old version:** card 0: sofhdadsp [sof-hda-dsp], device 0: HDA Analog ( *) [] card 0: sofhdadsp [sof-hda-dsp], device 6: DMIC (*) [] card 0: sofhdadsp [sof-hda-dsp], device 7: DMIC16kHz (*) [] Let me know if I can provide logs, diffs between UCM files, or further testing. I'd be happy to help. Best regards, Pablo Scatizza Neuquén, Argentina

2 1

retire_capture_urb: Corrected urb data len
by Sean Anderson 01 Aug '25

01 Aug '25

Hi all, I have a "FiiO DigiHug USB Audio" sound card (1852:7022) [3]. I have had no problems with the audio, but I did notice a large number of message like retire_capture_urb: 4992 callbacks suppressed in my dmesg [1]. This is caused by the "Corrected urb data len." warning. The patch adding this warning [2] makes it seem like this warning should be an uncommon occurance. However, based on the number of suppressed callbacks, this seems to be happening at a rate of around 500 Hz. Is this buggy hardware? Or is this a bug in the driver? Does there need to be a quirk? Or perhaps the warning above should be a debug instead? I'm using 5.15.0-46-generic. I know, I know; this is a vendor kernel. However, I went through the commits for sound/usb/pcm.c and didn't see any major differences. I also previously saw this issue on 5.4, so this probably isn't a regression. --Sean [1] I would have liked to post the actual message, but I was unable to figure out how to disable ratelimiting. I tried setting /proc/sys/kernel/printk_ratelimit to 0, /proc/sys/kernel/printk_ratelimit_burst to 5000, and /proc/sys/kernel/printk to 8. However, nothing seemed to have any effect (except that the callbacks suppressed messages were disabled). I find this very strange, given that the callbacks suppressed message uses KERN_WARN, and so does dev_warn_ratelimited. [2] https://lore.kernel.org/all/4B28A659.6070303@ladisch.de/T/ [3] Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x1852 GYROCOM C&C Co., LTD idProduct 0x7022 bcdDevice 0.01 iManufacturer 1 FiiO iProduct 2 DigiHug USB Audio iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0182 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType 33 bcdHID 1.00 bCountryCode 0 Not supported bNumDescriptors 1 bDescriptorType 34 Report wDescriptorLength 58 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0012 1x 18 bytes bInterval 32 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 3 FiiO USB DAC-E10 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x003e bInCollection 2 baInterfaceNr(0) 2 baInterfaceNr(1) 3 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0605 SPDIF interface bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 9 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 3 wTerminalType 0x0605 SPDIF interface bAssocTerminal 0 bSourceID 16 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 5 iTerminal 0 AudioControl Interface Descriptor: bLength 10 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 16 bSourceID 9 bControlSize 1 bmaControls(0) 0x01 Mute Control bmaControls(1) 0x02 Volume Control bmaControls(2) 0x02 Volume Control iFeature 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 7 bDelay 0 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 26 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 6 Discrete tSamFreq[ 0] 8000 tSamFreq[ 1] 16000 tSamFreq[ 2] 32000 tSamFreq[ 3] 44100 tSamFreq[ 4] 48000 tSamFreq[ 5] 96000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0184 1x 388 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 2 Decoded PCM samples wLockDelay 0x0002 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 7 bDelay 0 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 26 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 3 bBitResolution 24 bSamFreqType 6 Discrete tSamFreq[ 0] 8000 tSamFreq[ 1] 16000 tSamFreq[ 2] 32000 tSamFreq[ 3] 44100 tSamFreq[ 4] 48000 tSamFreq[ 5] 96000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0246 1x 582 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 2 Decoded PCM samples wLockDelay 0x0002 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 9 bDelay 0 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 20 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 4 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 tSamFreq[ 3] 96000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0184 1x 388 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 2 Decoded PCM samples wLockDelay 0x0002 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 9 bDelay 0 frames wFormatTag 0x0001 PCM AudioStreaming Interface Descriptor: bLength 20 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 1 (FORMAT_TYPE_I) bNrChannels 2 bSubframeSize 3 bBitResolution 24 bSamFreqType 4 Discrete tSamFreq[ 0] 32000 tSamFreq[ 1] 44100 tSamFreq[ 2] 48000 tSamFreq[ 3] 96000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0246 1x 582 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 2 Decoded PCM samples wLockDelay 0x0002 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 9 bDelay 0 frames wFormatTag 0x2001 IEC1937_AC-3 AudioStreaming Interface Descriptor: bLength 11 bDescriptorType 36 bDescriptorSubtype 2 (FORMAT_TYPE) bFormatType 3 (FORMAT_TYPE_III) bNrChannels 2 bSubframeSize 2 bBitResolution 16 bSamFreqType 1 Discrete tSamFreq[ 0] 48000 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00c0 1x 192 bytes bInterval 1 bRefresh 0 bSynchAddress 0 AudioStreaming Endpoint Descriptor: bLength 7 bDescriptorType 37 bDescriptorSubtype 1 (EP_GENERAL) bmAttributes 0x01 Sampling Frequency bLockDelayUnits 2 Decoded PCM samples wLockDelay 0x0002 can't get debug descriptor: Resource temporarily unavailable Device Status: 0x0000 (Bus Powered)

2 8

pcm: add a loop to snd_pcm_avail_delay() to avoid bogus delay values
by GitHub pull_request - opened 31 Jul '25

31 Jul '25

alsa-project/alsa-lib pull request #469 was opened from kv2019i: snd_pcm_avail_delay() is expected to report avail and delay values in atomic fashion. However the function does two separate syscalls and it cannot guarantee the avail value is the same as was used to calculate the delay. This is a problem as the reported delay is always relative to avail frames value. If application (like e.g. alsa_conformance_test) uses snd_pcm_avail_delay() to estimate the effective play position, it can observe bogus delay values (and effective play position going backwards) if snd_pcm_avail_delay() is called during a DMA burst where hw_ptr moves quickly. This commit adds a loop similar to that used in snd_pcm_hw_htimestamp() to wait until we get a stable avail reading, and only then extract the delay. This will avoid bogus values if function is called during DMA bursts. Closes: https://github.com/alsa-project/alsa-lib/issues/468 Request URL : https://github.com/alsa-project/alsa-lib/pull/469 Patch URL : https://github.com/alsa-project/alsa-lib/pull/469.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0

snd_pcm_avail_delay() reporting inaccurate delay values
by GitHub issues - opened 31 Jul '25

31 Jul '25

alsa-project/alsa-lib issue #468 was opened from kv2019i: The alsa_conformance_test tool (https://chromium.googlesource.com/chromiumos/platform/audiotest/+/HEAD/alsa…) has recently added support to use snd_pcm_avail_delay() to estimate the actual playback position. This has proven a very useful tool to test ALSA drivers on hardware (like that support by https://github.com/thesofproject/ ) where there is significant buffering in hardware (and hw_ptr can move in bursts). When testing with high sampling rates, an issue was found where the estimated playback position seemed to go backwards in time, as observed by alsa_conformance_test. This was observed on multiple Intel platform using SOF firmware for DSP. Debugging the kernel driver delay() implementation showed, that driver never reported incorrect delay values, but somehow alsa_conformance_test still observed these. Example log: ``` alsa_conformance_test -P hw:sofnocodec,2 -d 1 -r 96000 -B 480 -c 2 -f S32_LE -p 480 --avail-delay --debug ... TIME_DIFF(s) HW_LEVEL PLAYED DELAY DIFF RATE [.. snip ] 0.000999950 960 3324 1476 96 96004.800240 0.000995762 864 3420 1380 96 96408.579560 0.001024820 672 3516 1284 96 93674.986827 0.000987638 621 3613 1187 97 98214.122988 [Notice] frame_diff -1 >= 4096. 0.000049322 576 3612 1188 -1 -20274.928024 # KV: the delay value of 1187 is never reported by driver and it causes the playback position to go backwards in time despite driver reporting the accurate delay correctly 0.000992228 480 3708 1092 96 96751.956204 0.000972403 864 3804 1476 96 98724.500027 0.000998287 768 3900 1380 96 96164.730183 0.000979150 768 3996 1284 96 98044.222029 0.000999349 672 4092 1188 96 96062.536711 0.001018172 480 4188 1092 96 94286.623478 0.000977025 960 4284 1476 96 98257.465264 0.001022131 768 4380 1380 96 93921.424945 0.000977795 768 4476 1284 96 98180.088873 0.001019073 601 4573 1187 97 95184.545170 [Notice] frame_diff -1 >= 4096. 0.000049433 576 4572 1188 -1 -20229.401412 0.000953494 480 4668 1092 96 100682.332558 0.000981225 960 4764 1476 96 97836.887564 0.001025294 768 4860 1380 96 93631.680279 ``` When instrumenting alsa-lib snd_pcm_avail_delay() it became apparent the function is calling in middle of a DMA burst (when hw_ptr is moving fast ahead and the "avail" number is changing fast). alsa-lib does two syscalls to read avail and delay, the two values are not in sync and we end up reporting a bogus value. The error is not a big one, but this is enough to fail alsa_conformance_test test plans and push the calculcated standard rate error above acceptance criteria. This could also confuse media players who use this for video lip-sync, although in theory applications should handle this (a 0...3 frame error in delay reporting is not going to make a difference unless negative value breaks the application logic like happens here with alsa_conformance_test). We can observe the error especially with higher rates (96, 176.4 and 192kHz). This is harder to hit with the more typical 48khz use-cases, and thus maybe has not been hit before. Versions tested: 1.12.24, 1.12.11 Issue URL : https://github.com/alsa-project/alsa-lib/issues/468 Repository URL: https://github.com/alsa-project/alsa-lib

1 0

[PATCH] ucm: use close_range on _GNU_SOURCE
by Jochen Sprickerhof 30 Jul '25

30 Jul '25

--- src/ucm/ucm_exec.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/src/ucm/ucm_exec.c b/src/ucm/ucm_exec.c index 276cf592..b79a84ae 100644 --- a/src/ucm/ucm_exec.c +++ b/src/ucm/ucm_exec.c @@ -254,8 +254,12 @@ int uc_mgr_exec(const char *prog) close(f); +#if defined(_GNU_SOURCE) + close_range(3, maxfd, 0); +#else for (f = 3; f < maxfd; f++) close(f); +#endif /* install default handlers for the forked process */ signal(SIGINT, SIG_DFL); -- 2.50.0

1 0

[PATCH v2] ALSA: hda: Fix the wrong register was used for DVC of TAS2770
by Baojun Xu 29 Jul '25

29 Jul '25

The wrong register was used for digital volume control of TAS2770, The definition was changed, and usage was also updated. Fixes: ab29b3460c5c ("ALSA: hda: Add TAS2770 support") Signed-off-by: Baojun Xu <baojun.xu(a)ti.com> --- v2 - Correct number from -1000 to -10000 for DVC. --- include/sound/tas2770-tlv.h | 4 ++-- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/include/sound/tas2770-tlv.h b/include/sound/tas2770-tlv.h index c0bd495b4a07..c7380925417a 100644 --- a/include/sound/tas2770-tlv.h +++ b/include/sound/tas2770-tlv.h @@ -14,10 +14,10 @@ #ifndef __TAS2770_TLV_H__ #define __TAS2770_TLV_H__ -#define TAS2770_DVC_LEVEL TASDEVICE_REG(0x0, 0x0, 0x17) +#define TAS2770_DVC_LEVEL TASDEVICE_REG(0x0, 0x0, 0x05) #define TAS2770_AMP_LEVEL TASDEVICE_REG(0x0, 0x0, 0x03) -static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_dvc_tlv, 1650, 50, 0); +static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_dvc_tlv, -10000, 50, 0); static const __maybe_unused DECLARE_TLV_DB_SCALE(tas2770_amp_tlv, 1100, 50, 0); #endif diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index a0b132681804..45ac5e41bd4f 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -260,7 +260,7 @@ static const struct snd_kcontrol_new tas2770_snd_controls[] = { 0, 0, 20, 0, tas2781_amp_getvol, tas2781_amp_putvol, tas2770_amp_tlv), ACARD_SINGLE_RANGE_EXT_TLV("Speaker Digital Volume", TAS2770_DVC_LEVEL, - 0, 0, 31, 0, tas2781_amp_getvol, + 0, 0, 200, 1, tas2781_amp_getvol, tas2781_amp_putvol, tas2770_dvc_tlv), }; -- 2.43.0

1 0