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

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

[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

[PATCH 1/2] ALSA: hda: tas2781: fix tas2563 EFI data endianness
by Gergo Koteles 30 Aug '25

30 Aug '25

Before conversion to unify the calibration data management, the tas2563_apply_calib() function performed the big endian conversion and wrote the calibration data to the device. The writing is now done by the common tasdev_load_calibrated_data() function, but without conversion. Put the values into the calibration data buffer with the expected endianness. Fixes: 4fe238513407 ("ALSA: hda/tas2781: Move and unified the calibrated-data getting function for SPI and I2C into the tas2781_hda lib") Cc: <stable(a)vger.kernel.org> Signed-off-by: Gergo Koteles <soyer(a)irl.hu> --- sound/hda/codecs/side-codecs/tas2781_hda_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c index e34b17f0c9b9..1eac751ab2a6 100644 --- a/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c +++ b/sound/hda/codecs/side-codecs/tas2781_hda_i2c.c @@ -310,6 +310,7 @@ static int tas2563_save_calibration(struct tas2781_hda *h) struct cali_reg *r = &cd->cali_reg_array; unsigned int offset = 0; unsigned char *data; + __be32 bedata; efi_status_t status; unsigned int attr; int ret, i, j, k; @@ -351,6 +352,8 @@ static int tas2563_save_calibration(struct tas2781_hda *h) i, j, status); return -EINVAL; } + bedata = cpu_to_be32(*(uint32_t *)&data[offset]); + memcpy(&data[offset], &bedata, sizeof(bedata)); offset += TAS2563_CAL_DATA_SIZE; } } -- 2.51.0

2 2

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

30 Aug '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 1. Boot kernel 6.10 … 6.17-rc2 with snd-fireface loaded. 2. Start JACK with ALSA backend, for example: jackd -d alsa -d hw:Fireface -p 64 -n 3 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 4. With *FFADO* backend (jackd -d firewire), the same hardware works reliably and does not exhibit this issue. 5. This suggests that the problem lies in the ALSA FireWire streaming engine rather than the hardware itself. 6. 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.

1 0

URGENT: ALSAfirewire Drivers Introduce 90ms delay - Linux is Unusable for Pro Audio
by M. Armsby 29 Aug '25

29 Aug '25

Dear maintainers, Linux is being ridiculed in the professional audio community — not because it can't do low-latency audio, but because the ALSA FireWire stack actively breaks it. Professional gear costing thousands of dollars like Motu RME Focusrite etc. etc. Since kernel 5.16+, FireWire audio devices are correctly detected and functional — but they are burdened with an artificial +90ms latency offset due to missing timing metadata (e.g., cycle-match delay, transmission latency) in the driver's interface to userspace. PipeWire and WirePlumber rely on accurate latency reporting. When it's missing, they fall back to worst-case assumptions — adding ~90ms of delay. This is NOT a PipeWire bug. It is a FAILURE of the ALSA FireWire drivers to expose timing data that the hardware and firmware already provide. This bug: - Renders high-end interfaces (RME, Focusrite, Tascam, Motu, Terratec) unusable for real-time monitoring - Forces users to hack WirePlumber with hardcoded quantum rules - Damages Linux's credibility in music production - Makes Linux a JOKE in studios worldwide There is NO excuse for this in 2025. We have workarounds (see: https://forum.cockos.com/showthread.php?t=274978), but they are fragile, device-specific, and do not scale. We demand: 1. Immediate exposure of accurate device latency via ALSA control or hwdep interface 2. Proper reporting of transmission/cycle delay to userspace 3. A timeline for fixing this in mainline This is not a "nice-to-have". It is a **critical defect** in a core multimedia subsystem now using pipewire as standard. Linux can and must do better. Many are waiting to move to Linux, finally leaving windows. — Martin Armsby (Martin A - maa) Professional Audio Producer / Linux Advocate Please see: Imagine if Linux Audio just worked - Firewire <https://forum.cockos.com/showthread.php?t=302305> and <https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4785> Thank you for reading. -- Martin Armsby -- Martin Armsby

1 1