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

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

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

01 Sep '25

A bug reported by one of my customers that the order of TAS2563 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> --- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index dbd71e173119..853ff5d87966 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -313,7 +313,7 @@ static int tas2563_save_calibration(struct tas2781_hda *h) { efi_guid_t efi_guid = tasdev_fct_efi_guid[LENOVO]; char *vars[TASDEV_CALIB_N] = { - "R0_%d", "InvR0_%d", "R0_Low_%d", "Power_%d", "TLim_%d" + "R0_%d", "R0_Low_%d", "InvR0_%d", "Power_%d", "TLim_%d" }; efi_char16_t efi_name[TAS2563_CAL_VAR_NAME_MAX]; unsigned long max_size = TAS2563_CAL_DATA_SIZE; -- 2.43.0

3 2