[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