[PATCH v2 0/4] ALSA: compress_offload: Add 64-bit safe timestamp API

Charles Keepax ckeepax at opensource.cirrus.com
Fri Jul 11 04:56:47 PDT 2025


On Fri, Jul 11, 2025 at 10:36:26AM +0100, 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 introduces a parallel, 64-bit safe API to solve
> this problem while maintaining perfect backward compatibility with the
> existing UAPI. A new pointer64 operation and corresponding ioctls
> are added to allow the kernel to track counters using u64 and expose
> these full-width values to user-space.
> 
> The series is structured as follows:
> 
> Patch 1: Introduces the new internal pointer64 op, refactors the
> core logic 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.
> 
> Patch 4: Implements the new .pointer64 operation in various ASoC
> drivers that support compress offload.
> 
> 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, and no regressions were observed
> when using the legacy API.
> 
> Thanks,
> Joris (George) Verhaegen
> 
> Signed-off-by: Joris Verhaegen <verhaegen at google.com>
> 
> ---

Would it not be slightly simpler to just update all the in kernel
bits to use 64-bit and then only convert to 32-bit for the
existing 32-bit IOCTLs? Why do we need 32-bit callbacks into the
drivers for example?

Thanks,
Charles



More information about the linux-arm-kernel mailing list