- Sound-open-firmware - mailman.alsa-project.org

Re: [PATCH v5 0/3] ALSA: compress_offload: Add 64-bit safe timestamp API
by Takashi Iwai 08 Sep '25

08 Sep '25

On Fri, 05 Sep 2025 11:12:53 +0200, Joris Verhaegen wrote: > > The current compress offload timestamping API relies on struct > snd_compr_tstamp, whose cumulative counters like copied_total are > defined as __u32. On long-running high-resolution audio streams, these > 32-bit counters can overflow, causing incorrect availability > calculations. > > This patch series transitions to a 64-bit safe API to solve the problem > while maintaining perfect backward compatibility with the existing UAPI. > The pointer operation is reworked to use a new timestamp struct with > 64-bit fields for the cumulative counters, named snd_compr_tstamp64. > ASoC drivers are updated to use the 64-bit structures. Corresponding > ioctls are added to expose them to user-space. > > The series is structured as follows: > > Patch 1: Updates the pointer op, refactors the core logic and ASoC > drivers to use it, and defines the new UAPI structs. > > Patch 2: Exposes the SNDRV_COMPRESS_TSTAMP64 ioctl. > > Patch 3: Exposes the corresponding SNDRV_COMPRESS_AVAIL64 ioctl. > > This series has been tested on a Pixel 9 device. All compress offload > use cases, including long-running playback, were verified to work > correctly with the new 64-bit API. > > Thanks, > Joris (George) Verhaegen > > Signed-off-by: Joris Verhaegen <verhaegen(a)google.com> > > --- > Changes in v2: > - Corrected author and Signed-off-by to be consistent (Mark Brown). > Changes in v3: > - Rework pointer op to return 64-bit timestamp, rather than adding a > parallel pointer64 op (Charles Keepax, Takashi Iwai, Vinod Koul) > - Bump the protocol version for ABI change (Takashi Iwai) > -Fix linker error on Intel Atom (lkp(a)intel.com) > -Rebase on latest for-next sound tree (Takashi Iwai) > -Avoid changing return error code for ioctl (internal) > -ASoC: Replace u64 % u32 by do_div(u64, u32) (internal) > -ASoC: sprd: change current_data_offset to u64 (internal) > Changes in v4: > -Fix compiler error on Intel AVS (lkp(a)intel.com) > Changes in v5: > -Revert formatting change in compress_offload.c (Vinod Koul) > > Joris Verhaegen (3): > ALSA: compress_offload: Add 64-bit safe timestamp infrastructure > ALSA: compress_offload: Add SNDRV_COMPRESS_TSTAMP64 ioctl > ALSA: compress_offload: Add SNDRV_COMPRESS_AVAIL64 ioctl Applied all patches now to for-next branch for 6.18. thanks, Takashi

1 0

Re: [PATCH v5 0/3] ALSA: compress_offload: Add 64-bit safe timestamp API
by Vinod Koul 08 Sep '25

08 Sep '25

On 05-09-25, 10:12, Joris Verhaegen wrote: > The current compress offload timestamping API relies on struct > snd_compr_tstamp, whose cumulative counters like copied_total are > defined as __u32. On long-running high-resolution audio streams, these > 32-bit counters can overflow, causing incorrect availability > calculations. > > This patch series transitions to a 64-bit safe API to solve the problem > while maintaining perfect backward compatibility with the existing UAPI. > The pointer operation is reworked to use a new timestamp struct with > 64-bit fields for the cumulative counters, named snd_compr_tstamp64. > ASoC drivers are updated to use the 64-bit structures. Corresponding > ioctls are added to expose them to user-space. > > The series is structured as follows: > > Patch 1: Updates the pointer op, refactors the core logic and ASoC > drivers to use it, and defines the new UAPI structs. > > Patch 2: Exposes the SNDRV_COMPRESS_TSTAMP64 ioctl. > > Patch 3: Exposes the corresponding SNDRV_COMPRESS_AVAIL64 ioctl. > > This series has been tested on a Pixel 9 device. All compress offload > use cases, including long-running playback, were verified to work > correctly with the new 64-bit API. Acked-by: Vinod Koul <vkoul(a)kernel.org> Please updated tinycompress changes with this once this is picked up by Takashi-san -- ~Vinod

1 0

Re: [PATCH][next] ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message
by Mark Brown 02 Sep '25

02 Sep '25

On Tue, 02 Sep 2025 13:06:39 +0100, Colin Ian King wrote: > The dev_err message is reporting an error about capture streams however > it is using the incorrect variable num_playback instead of num_capture. > Fix this by using the correct variable num_capture. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message commit: 35fc531a59694f24a2456569cf7d1a9c6436841c 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

1 0

Re: [PATCH][next] ASoC: SOF: ipc4-topology: Fix a less than zero check on a u32
by Mark Brown 02 Sep '25

02 Sep '25

On Tue, 02 Sep 2025 09:32:13 +0100, Colin Ian King wrote: > Currently the error check from the call to sof_ipc4_get_sample_type > is always false because a u32 variable out_ref_type is being used > to perform the less than zero check. Fix this by using the int > variable ret to perform the check. > > Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: ipc4-topology: Fix a less than zero check on a u32 commit: 3279052eab235bfb7130b1fabc74029c2260ed8d 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

1 0

Re: [PATCH][next] ASoC: SOF: Intel: hda-stream: Fix incorrect variable used in error message
by Péter Ujfalusi 02 Sep '25

02 Sep '25

On 02/09/2025 15:06, Colin Ian King wrote: > The dev_err message is reporting an error about capture streams however > it is using the incorrect variable num_playback instead of num_capture. > Fix this by using the correct variable num_capture. > > Fixes: a1d1e266b445 ("ASoC: SOF: Intel: Add Intel specific HDA stream operations") > Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> > --- > sound/soc/sof/intel/hda-stream.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c > index aa6b0247d5c9..a34f472ef175 100644 > --- a/sound/soc/sof/intel/hda-stream.c > +++ b/sound/soc/sof/intel/hda-stream.c > @@ -890,7 +890,7 @@ int hda_dsp_stream_init(struct snd_sof_dev *sdev) > > if (num_capture >= SOF_HDA_CAPTURE_STREAMS) { > dev_err(sdev->dev, "error: too many capture streams %d\n", > - num_playback); > + num_capture); > return -EINVAL; > } > -- Péter

1 0

Re: [PATCH][next] ASoC: SOF: ipc4-topology: Fix a less than zero check on a u32
by Péter Ujfalusi 02 Sep '25

02 Sep '25

On 02/09/2025 11:32, Colin Ian King wrote: > Currently the error check from the call to sof_ipc4_get_sample_type > is always false because a u32 variable out_ref_type is being used > to perform the less than zero check. Fix this by using the int > variable ret to perform the check. > > Fixes: c04c2e829649 ("ASoC: SOF: ipc4-topology: Add support for 8-bit formats") > Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> Acked-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> > --- > sound/soc/sof/ipc4-topology.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/sof/ipc4-topology.c b/sound/soc/sof/ipc4-topology.c > index f5e62cd8fc0c..b6a732d0adb4 100644 > --- a/sound/soc/sof/ipc4-topology.c > +++ b/sound/soc/sof/ipc4-topology.c > @@ -2191,9 +2191,10 @@ sof_ipc4_prepare_copier_module(struct snd_sof_widget *swidget, > case snd_soc_dapm_dai_in: > out_ref_rate = params_rate(fe_params); > out_ref_channels = params_channels(fe_params); > - out_ref_type = sof_ipc4_get_sample_type(sdev, fe_params); > - if (out_ref_type < 0) > - return out_ref_type; > + ret = sof_ipc4_get_sample_type(sdev, fe_params); > + if (ret < 0) > + return ret; > + out_ref_type = (u32)ret; > > if (!single_output_bitdepth) { > out_ref_valid_bits = sof_ipc4_get_valid_bits(sdev, fe_params); -- Péter

1 0

Re: [PATCH v4 2/3] ALSA: compress_offload: Add SNDRV_COMPRESS_TSTAMP64 ioctl
by Vinod Koul 21 Aug '25

21 Aug '25

On 18-08-25, 15:05, Charles Keepax wrote: > On Tue, Aug 05, 2025 at 07:59:42AM +0200, Takashi Iwai wrote: > > On Tue, 05 Aug 2025 06:47:59 +0200, > > Vinod Koul wrote: > > > On 01-08-25, 10:27, Joris Verhaegen wrote: > > > > ret = snd_compr_update_tstamp(stream, &tstamp64); > > > > if (ret == 0) { > > > > - snd_compr_tstamp32_from_64(&tstamp32, &tstamp64); > > > > - ret = copy_to_user((struct snd_compr_tstamp __user *)arg, > > > > - &tstamp32, sizeof(tstamp32)) ? > > > > + if (is_32bit) { > > > > + snd_compr_tstamp32_from_64(&tstamp32, &tstamp64); > > > > + copy_from = &tstamp32; > > > > + copy_size = sizeof(tstamp32); > > > > + } > > > > > > Most of the applications and people would be 32bit right now and we > > > expect this to progressively change, but then this imposes a penalty as > > > default path is 64 bit, since we expect this ioctl to be called very > > > frequently, should we do this optimization for 64bit here? > > > > Through a quick glance over the patch, I don't think you'll hit the > > significant performance loss. It's merely a few bytes of extra copies > > before copy_to_user(), after all. But, of course, it'd be more > > convincing if anyone can test and give the actual numbers. That would be better > I am inclined to agree the impact should be very minimal and the > only alternative is a more complex implementation. I would vote > for leaving this as is. But yes, we can for now, go ahead. It is internal kernel flow can be adapted anytime :-) -- ~Vinod

2 1

[PATCH] ASoC: SOF: ipc4-pcm: Fix incorrect comparison with number of tdm_slots
by Richard Fitzgerald 19 Aug '25

19 Aug '25

In ipc4_ssp_dai_config_pcm_params_match() when comparing params_channels() against hw_config->tdm_slots the comparison should be a <= not a ==. The number of TDM slots must be enough for the number of required channels. But it can be greater. There are various reason why a I2S/TDM link has more TDM slots than a particular audio stream needs. The original comparison would fail on systems that had more TDM slots. Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Fixes: 8a07944a77e9 ("ASoC: SOF: ipc4-pcm: Look for best matching hw_config for SSP") --- sound/soc/sof/ipc4-pcm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sof/ipc4-pcm.c b/sound/soc/sof/ipc4-pcm.c index 374dc10d10fd..86f7377fb92f 100644 --- a/sound/soc/sof/ipc4-pcm.c +++ b/sound/soc/sof/ipc4-pcm.c @@ -639,14 +639,14 @@ static int ipc4_ssp_dai_config_pcm_params_match(struct snd_sof_dev *sdev, if (params_rate(params) == le32_to_cpu(hw_config->fsync_rate) && params_width(params) == le32_to_cpu(hw_config->tdm_slot_width) && - params_channels(params) == le32_to_cpu(hw_config->tdm_slots)) { + params_channels(params) <= le32_to_cpu(hw_config->tdm_slots)) { current_config = le32_to_cpu(hw_config->id); partial_match = false; /* best match found */ break; } else if (current_config < 0 && params_rate(params) == le32_to_cpu(hw_config->fsync_rate) && - params_channels(params) == le32_to_cpu(hw_config->tdm_slots)) { + params_channels(params) <= le32_to_cpu(hw_config->tdm_slots)) { current_config = le32_to_cpu(hw_config->id); partial_match = true; /* keep looking for better match */ -- 2.39.5

1 0

Re: [PATCH v2] ASoC: SOF: imx: Remove error print for devm_add_action_or_reset()
by Mark Brown 12 Aug '25

12 Aug '25

On Tue, 05 Aug 2025 11:33:32 +0200, Waqar Hameed wrote: > When `devm_add_action_or_reset()` fails, it is due to a failed memory > allocation and will thus return `-ENOMEM`. `dev_err_probe()` doesn't do > anything when error is `-ENOMEM`. Therefore, remove the useless call to > `dev_err_probe()` when `devm_add_action_or_reset()` fails, and just > return the value instead. > > > [...] Applied to https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next Thanks! [1/1] ASoC: SOF: imx: Remove error print for devm_add_action_or_reset() commit: 9d6a51651faa577e5d2be9d67915b7621c5c589a 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

1 0

[PATCH] ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies
by Arnd Bergmann 06 Aug '25

06 Aug '25

From: Arnd Bergmann <arnd(a)arndb.de> The hda-sdw-bpt code links against the soundwire driver, but that fails when trying to link from built-in code into loadable module: x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_close_stream.isra.0': intel_ace2x.c:(.text+0x137a531): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_send_async': intel_ace2x.c:(.text+0x137aa45): undefined reference to `hda_sdw_bpt_open' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ab67): undefined reference to `hda_sdw_bpt_close' x86_64-linux-ld: intel_ace2x.c:(.text+0x137ac30): undefined reference to `hda_sdw_bpt_send_async' x86_64-linux-ld: vmlinux.o: in function `intel_ace2x_bpt_wait': intel_ace2x.c:(.text+0x137aced): undefined reference to `hda_sdw_bpt_wait' Ensure that both SOUNDWIRE_INTEL and SND_SOF_SOF_HDA_SDW_BPT are selected at the same time by SND_SOC_SOF_INTEL_LNL, and that this happens even if SND_SOC_SOF_INTEL_SOUNDWIRE is a loadable module but SND_SOC_SOF_INTEL_LNL is built-in. This follows the same logic as commit c5a61db9bf89 ("ASoC: SOF: fix intel-soundwire link failure"). Fixes: 5d5cb86fb46e ("ASoC: SOF: Intel: hda-sdw-bpt: add helpers for SoundWire BPT DMA") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- sound/soc/sof/intel/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/Kconfig b/sound/soc/sof/intel/Kconfig index 7e92aa2f7e39..9722ae43e87c 100644 --- a/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/Kconfig @@ -272,9 +272,10 @@ config SND_SOC_SOF_METEORLAKE config SND_SOC_SOF_INTEL_LNL tristate + select SOUNDWIRE_INTEL if SND_SOC_SOF_INTEL_SOUNDWIRE != n select SND_SOC_SOF_HDA_GENERIC select SND_SOC_SOF_INTEL_SOUNDWIRE_LINK_BASELINE - select SND_SOF_SOF_HDA_SDW_BPT if SND_SOC_SOF_INTEL_SOUNDWIRE + select SND_SOF_SOF_HDA_SDW_BPT if SND_SOC_SOF_INTEL_SOUNDWIRE != n select SND_SOC_SOF_IPC4 select SND_SOC_SOF_INTEL_MTL -- 2.39.5

3 2