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

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 v2] ALSA: hda/tas2781: Fix the order of TAS2781 calibrated-data
by Shenghao Ding 04 Sep '25

04 Sep '25

A bug reported by one of my customers that the order of TAS2781 calibrated-data is incorrect, the correct way is to move R0_Low and insert it between R0 and InvR0. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- v2: - Submit to sound branch maintianed by Tiwai instead of linux-next branch - drop other fix --- sound/hda/codecs/side-codecs/tas2781_hda.c | 38 ++++++++++++++++++---- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda.c b/sound/hda/codecs/side-codecs/tas2781_hda.c index f46d2e06c64f..cd9990869e18 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda.c @@ -33,6 +33,32 @@ const efi_guid_t tasdev_fct_efi_guid[] = { }; EXPORT_SYMBOL_NS_GPL(tasdev_fct_efi_guid, "SND_HDA_SCODEC_TAS2781"); +/* + * The order of calibrated-data writing is a bit different from the order + * in UEFI. Here is the conversion to match the order of calibrated-data + * writing. + */ +static void cali_cnv(unsigned char *data, unsigned int base, int offset) +{ + __be32 bedata[TASDEV_CALIB_N]; + int i; + + /* r0_reg */ + bedata[0] = cpu_to_be32(*(uint32_t *)&data[base]); + /* r0_low_reg */ + bedata[1] = cpu_to_be32(*(uint32_t *)&data[base + 8]); + /* invr0_reg */ + bedata[2] = cpu_to_be32(*(uint32_t *)&data[base + 4]); + /* pow_reg */ + bedata[3] = cpu_to_be32(*(uint32_t *)&data[base + 12]); + /* tlimit_reg */ + bedata[4] = cpu_to_be32(*(uint32_t *)&data[base + 16]); + + for (i = 0; i < TASDEV_CALIB_N; i++) + memcpy(&data[offset + i * 4 + 1], &bedata[i], + sizeof(bedata[i])); +} + static void tas2781_apply_calib(struct tasdevice_priv *p) { struct calidata *cali_data = &p->cali_data; @@ -86,6 +112,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) for (j = 0, k = 0; j < node_num; j++) { oft = j * 6 + 3; + /* Calibration registers address */ if (tmp_val[oft] == TASDEV_UEFI_CALI_REG_ADDR_FLG) { for (i = 0; i < TASDEV_CALIB_N; i++) { buf = &data[(oft + i + 1) * 4]; @@ -93,6 +120,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) buf[2], buf[3]); } } else { + /* Calibrated data */ l = j * (cali_data->cali_dat_sz_per_dev + 1); if (k >= p->ndev || l > oft * 4) { dev_err(p->dev, "%s: dev sum error\n", @@ -103,8 +131,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) data[l] = k; oft++; - for (i = 0; i < TASDEV_CALIB_N * 4; i++) - data[l + i + 1] = data[4 * oft + i]; + cali_cnv(data, 4 * oft, l); k++; } } @@ -127,12 +154,11 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) dev_err(p->dev, "%s: V1 CRC error\n", __func__); return; } - + /* reverse rearrangement in case of overlap */ for (j = p->ndev - 1; j >= 0; j--) { l = j * (cali_data->cali_dat_sz_per_dev + 1); - for (i = TASDEV_CALIB_N * 4; i > 0 ; i--) - data[l + i] = data[p->index * 5 + i]; - data[l+i] = j; + cali_cnv(data, cali_data->cali_dat_sz_per_dev * j, l); + data[l] = j; } } -- 2.43.0

3 4

[PATCH] ASoC: amd: amd_sdw: Add quirks for some new Dell laptops
by Syed Saba Kareem 03 Sep '25

03 Sep '25

Add a quirk to include the codec amplifier function for Dell SKU's listed in quirk table. Note: In these SKU's, the RT722 codec amplifier is excluded, and an external amplifier is used instead. Signed-off-by: Syed Saba Kareem <syed.sabakareem(a)amd.com> --- sound/soc/amd/acp/acp-sdw-legacy-mach.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/acp-sdw-legacy-mach.c index c2197b75a7dd..5a3cfedacbaf 100644 --- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c +++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c @@ -79,6 +79,22 @@ static const struct dmi_system_id soc_sdw_quirk_table[] = { }, .driver_data = (void *)(ASOC_SDW_CODEC_SPKR), }, + { + .callback = soc_sdw_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"), + DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0DD3"), + }, + .driver_data = (void *)(ASOC_SDW_CODEC_SPKR), + }, + { + .callback = soc_sdw_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc"), + DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "0DD4"), + }, + .driver_data = (void *)(ASOC_SDW_CODEC_SPKR), + }, {} }; -- 2.43.0

2 1

ucm2: Qualcomm: x1e80100: Add X1E80100-EVK configuration
by GitHub pull_request - opened 03 Sep '25

03 Sep '25

alsa-project/alsa-ucm-conf pull request #608 was opened from ReaLcdcLeQi: The X1E80100-EVK needs basically the same configuration as the X1E80100-CRD. The dts upstream is already in progress. https://lore.kernel.org/all/20250828-hamoa_initial-v8-3-c9d173072a5c@oss.qu… message id <20250828-hamoa_initial-v8-3-c9d173072a5c(a)oss.qualcomm.com> Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/608 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/608.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

A52 producing static noise
by GitHub issues - edited 03 Sep '25

03 Sep '25

alsa-project/alsa-plugins issue #63 was edited from mingww64: Setup is GPU----(HDMI)----TV----(eARC)----Sonos Arc Playing AC3 audio sample works and can confirm the speakers is receiving in AC3 format (Sonos app displaying Dolby Digital 5.1), however using the a52 plugin with `speaker-test` only static noise was coming out intermittently and Sonos app doesn't show any audio format. The GPU is a rx9070xt , I'm unsure if the problem is on the plugin or on AMD's side. ```log Slave: Hardware PCM card 0 'HDA ATI HDMI' device 9 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 3072 period_size : 768 period_time : 16000 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 768 period_event : 0 start_threshold : 3072 stop_threshold : 3072 silence_threshold: 0 silence_size : 0 boundary : 6917529027641081856 appl_ptr : 0 hw_ptr : 0 0 - Front Left 4 - Front Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 17.888669 0 - Front Left 4 - Front Center 1 - Front Right ^C 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 8.512034 ``` Issue URL : https://github.com/alsa-project/alsa-plugins/issues/63 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

A52 producing static noise
by GitHub issues - opened 03 Sep '25

03 Sep '25

alsa-project/alsa-plugins issue #63 was opened from mingww64: Setup is GPU----(HDMI)----TV----(eARC)----Sonos Arc Playing AC3 audio sample works and can confirm the speakers is receiving in AC3 format (Sonos app displaying Dolby Digital 5.1), however using the a52 plugin with `speaker-test` only static noise was coming out intermittently and Sonos app doesn't show any audio format. ```log Slave: Hardware PCM card 0 'HDA ATI HDMI' device 9 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 3072 period_size : 768 period_time : 16000 tstamp_mode : NONE tstamp_type : MONOTONIC period_step : 1 avail_min : 768 period_event : 0 start_threshold : 3072 stop_threshold : 3072 silence_threshold: 0 silence_size : 0 boundary : 6917529027641081856 appl_ptr : 0 hw_ptr : 0 0 - Front Left 4 - Front Center 1 - Front Right 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 17.888669 0 - Front Left 4 - Front Center 1 - Front Right ^C 3 - Rear Right 2 - Rear Left 5 - LFE Time per period = 8.512034 ``` Issue URL : https://github.com/alsa-project/alsa-plugins/issues/63 Repository URL: https://github.com/alsa-project/alsa-plugins

1 0

[BUG] ALSA FireWire: poll timeout causes JACK to stop (6.10 – 6.17-rc2)
by Илья Кузнецов 03 Sep '25

03 Sep '25

________________________________ Hello ALSA developers, I would like to report a reproducible issue with snd-fireface on Linux kernels 6.10 through 6.17-rc2. ________________________________ System Information Kernel versions tested: 6.10 → 6.17-rc2 Audio interface: RME Fireface 800 Driver in use: snd-fireface Audio server: JACK (tested with jackd and QJackCtl) Distribution: Debian 12 Kernel config: ALSA FireWire drivers enabled, no FFADO in use Chip 1394: Texas Instrumets ________________________________ Steps to Reproduce Boot kernel 6.10 … 6.17-rc2 with snd-fireface loaded. Start JACK with ALSA backend, for example: jackd -d alsa -d hw:Fireface -p 64 -n 3 Use the system normally — during playback, recording, or even when idle. The issue may occur at any time without apparent external cause. Actual Behavior After some idle time, ALSA stops responding and JACK prints: ERROR: ALSA: poll time out, polled for ... usecs ERROR: JackAudioDriver::ProcessAsync: read error, stopping... JACK immediately terminates. The Fireface 800 does not recover until JACK is restarted. ________________________________ Expected Behavior The ALSA FireWire driver should maintain the stream and allow JACK to continue running without manual restart, even when idle. ________________________________ Notes With FFADO backend (jackd -d firewire), the same hardware works reliably and does not exhibit this issue. This suggests that the problem lies in the ALSA FireWire streaming engine rather than the hardware itself. The problem has been reproducible across all tested kernels (vanila, rt, liquorix) from 6.10 through 6.17-rc2. ________________________________ Request Could you please confirm if this issue is known? Is there any ongoing work on the ALSA FireWire streaming engine (snd-fireface) to address these poll timeout conditions? I can provide additional logs (dmesg, journalctl) or test patches if needed. Thank you, Ilya Kuznetsov.

2 2

I2S Stereo ADC Soundcard Hacking
by sylvain.gre＠proton.me 02 Sep '25

02 Sep '25

My idea is to exchange two input signals (CH_L1_IN and CH_L2_IN) at the sampling rate (192kHz) to produce one signal (CH_L_OUT), sampled at 192kHz (small electronic cicuit cf https://electronics.stackexchange.com/questions/754648/i2s-stereo-adc-sound…). In this way, in the digital domain I will receive CH_L1_IN, CH_R1_IN, CH_L2_IN, CH_R2_IN... Of course, the sampling frequency will be decreased by 2 using this method (96kHz instead of 192kHz). But the number of channels is increased by 2 also (4 instead of 2). Where can I begin with alsa to increase the number of channels and adjust the sampling frequency ? Something like a virtual soundcard maybe ? I have skills in dev but don't know where I have to start with alsa fot this hack...

1 0

[PATCH v1] ALSA: hda/tas2781: Fix the order of TAS2781 calibrated-data
by Shenghao Ding 02 Sep '25

02 Sep '25

A bug reported by one of my customers that the order of TAS2781 calibrated-data is incorrect, the correct way is to move R0_Low_%d and insert it between R0_%d and InvR0_%d. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Signed-off-by: Shenghao Ding <shenghao-ding(a)ti.com> --- v1: - Add varialbe csz to store cali_data->cali_dat_sz_per_dev, which is long enough to need two lines. - Add more comments on calibrated-data order --- sound/hda/codecs/side-codecs/tas2781_hda.c | 43 ++++++++++++++++++---- 1 file changed, 35 insertions(+), 8 deletions(-) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda.c b/sound/hda/codecs/side-codecs/tas2781_hda.c index f46d2e06c64f..d5913a727be4 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda.c @@ -33,6 +33,32 @@ const efi_guid_t tasdev_fct_efi_guid[] = { }; EXPORT_SYMBOL_NS_GPL(tasdev_fct_efi_guid, "SND_HDA_SCODEC_TAS2781"); +/* + * The order of calibrated-data writing is a bit different from the order + * in UEFI. Here is the conversion to match the order of calibrated-data + * writing. + */ +static void cali_cnv(unsigned char *data, unsigned int base, int offset) +{ + __be32 bedata[TASDEV_CALIB_N]; + int i; + + /* r0_reg */ + bedata[0] = cpu_to_be32(*(uint32_t *)&data[base]); + /* r0_low_reg */ + bedata[1] = cpu_to_be32(*(uint32_t *)&data[base + 8]); + /* invr0_reg */ + bedata[2] = cpu_to_be32(*(uint32_t *)&data[base + 4]); + /* pow_reg */ + bedata[3] = cpu_to_be32(*(uint32_t *)&data[base + 12]); + /* tlimit_reg */ + bedata[4] = cpu_to_be32(*(uint32_t *)&data[base + 16]); + + for (i = 0; i < TASDEV_CALIB_N; i++) + memcpy(&data[offset + i * 4 + 1], &bedata[i], + sizeof(bedata[i])); +} + static void tas2781_apply_calib(struct tasdevice_priv *p) { struct calidata *cali_data = &p->cali_data; @@ -46,6 +72,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) TASDEVICE_REG(0, 0x13, 0x70), TASDEVICE_REG(0, 0x18, 0x7c), }; + unsigned int csz = cali_data->cali_dat_sz_per_dev; unsigned int crc, oft, node_num; unsigned char *buf; int i, j, k, l; @@ -86,6 +113,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) for (j = 0, k = 0; j < node_num; j++) { oft = j * 6 + 3; + /* Calibration registers address */ if (tmp_val[oft] == TASDEV_UEFI_CALI_REG_ADDR_FLG) { for (i = 0; i < TASDEV_CALIB_N; i++) { buf = &data[(oft + i + 1) * 4]; @@ -93,7 +121,8 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) buf[2], buf[3]); } } else { - l = j * (cali_data->cali_dat_sz_per_dev + 1); + /* Calibrated data */ + l = j * (csz + 1); if (k >= p->ndev || l > oft * 4) { dev_err(p->dev, "%s: dev sum error\n", __func__); @@ -103,8 +132,7 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) data[l] = k; oft++; - for (i = 0; i < TASDEV_CALIB_N * 4; i++) - data[l + i + 1] = data[4 * oft + i]; + cali_cnv(data, 4 * oft, l); k++; } } @@ -127,12 +155,11 @@ static void tas2781_apply_calib(struct tasdevice_priv *p) dev_err(p->dev, "%s: V1 CRC error\n", __func__); return; } - + /* reverse rearrangement in case of overlap */ for (j = p->ndev - 1; j >= 0; j--) { - l = j * (cali_data->cali_dat_sz_per_dev + 1); - for (i = TASDEV_CALIB_N * 4; i > 0 ; i--) - data[l + i] = data[p->index * 5 + i]; - data[l+i] = j; + l = j * (csz + 1); + cali_cnv(data, csz * j, l); + data[l] = j; } } -- 2.43.0

2 1

tlv: ignore xdir when type is DB_MINMAX_MUTE
by GitHub pull_request - opened 02 Sep '25

02 Sep '25

alsa-project/alsa-lib pull request #474 was opened from qaqland: Muting caused by rounding is meaningless, and it is also inconvenient for upper-layer applications to handling muting issues caused by DB_MINMAX_MUTE or xdir. Thus, the restriction on xdir is removed. Request URL : https://github.com/alsa-project/alsa-lib/pull/474 Patch URL : https://github.com/alsa-project/alsa-lib/pull/474.patch Repository URL: https://github.com/alsa-project/alsa-lib

1 0