audio: use size_t for circular-buffer sample counts

[softwarecki]

The typed circular-buffer accessors report sample counts as int, while the rest of the sink/source API expresses sizes as size_t. This series aligns the sample counts with size_t.

The first commit changes cir_buf_samples_without_wrap_s16() and cir_buf_samples_without_wrap_s32() to return size_t.
The second commit changes the buffer_samples out-parameter of source_get_data_s16/s32() and sink_get_buffer_s16/s32() from int pointer to size_t pointer, and updates all callers to declare their sample-count locals as size_t.

[Copilot]

🟡 Changes recommended

Critical API migration gaps and moderate ASRC/mixer type-safety issues remain unresolved.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Aligns audio circular-buffer and source/sink sample counts from int to size_t.

Changes:

• Updates typed buffer helpers and API out-parameters.
• Propagates size_t through audio processing modules.
• Adjusts counters, loops, and buffer-size arithmetic.

File summaries

File	Reviewed changes
src/module/audio/source_api.c	Updates source sample-count outputs.
src/module/audio/sink_api.c	Updates sink sample-count outputs.
src/include/module/audio/source_api.h	Updates source API declarations.
src/include/module/audio/sink_api.h	Updates sink API declarations; existing int * callers remain incompatible.
src/include/module/audio/audio_stream.h	Returns size_t; remaining int consumers leave the migration incomplete.
src/audio/volume/volume_hifi5.c	Migrates HiFi5 processing counts.
src/audio/volume/volume_hifi5_with_peakvol.c	Migrates HiFi5 peak-volume counts.
src/audio/volume/volume_hifi4.c	Migrates HiFi4 processing counts.
src/audio/volume/volume_hifi4_with_peakvol.c	Migrates HiFi4 peak-volume counts.
src/audio/volume/volume_hifi3.c	Migrates HiFi3 processing counts.
src/audio/volume/volume_hifi3_with_peakvol.c	Migrates HiFi3 peak-volume counts.
src/audio/volume/volume_generic.c	Migrates generic volume counters.
src/audio/volume/volume_generic_with_peakvol.c	Migrates generic peak-volume counters.
src/audio/tone/tone.c	Migrates circular-buffer sizes.
src/audio/template/template-generic.c	Updates typed buffer-size locals.
src/audio/stft_process/stft_process_common.c	Updates buffer-size handling; remaining narrowed consumers are unresolved.
src/audio/sound_dose/sound_dose-generic.c	Updates buffer sizes.
src/audio/phase_vocoder/phase_vocoder-generic.c	Updates buffer sizes.
src/audio/phase_vocoder/phase_vocoder_common.c	Updates output sizes.
src/audio/multiband_drc/multiband_drc_generic.c	Updates sample counts.
src/audio/mixer/mixer_hifi3.c	Migrates mixer counts.
src/audio/mixer/mixer_generic.c	Retains unsafe int total counts and const-discarding wrap calls.
src/audio/mfcc/mfcc_common.c	Updates source buffer sizes.
src/audio/level_multiplier/level_multiplier-hifi5.c	Updates buffer-size locals.
src/audio/level_multiplier/level_multiplier-hifi3.c	Updates buffer-size locals.
src/audio/level_multiplier/level_multiplier-generic.c	Updates buffer-size locals.
src/audio/igo_nr/igo_nr.c	Updates buffer-size locals.
src/audio/asrc/asrc.c	Migrates wrap counts, but n_copy remains int in both copy paths.
src/audio/aria/aria_generic.c	Updates processing counters.

Review details

Suppressed comments (5)

src/audio/asrc/asrc.c:50

• These values now have type size_t, but n_copy remains int and receives the conditional result in the copy loop below. A fragment/count above INT_MAX is narrowed; because n is unsigned, n -= n_copy can then underflow and leave the loop making no progress. The count and loop-index locals in both copy functions should use size_t.

	size_t n_wrap_src;
	size_t n_wrap_snk;

src/audio/asrc/asrc.c:122

• The same narrowing remains in the s16 copy function: n_copy is still int while the conditional at line 138 combines it with the new size_t wrap count. Large valid fragments can therefore truncate before memcpy_s, and the unsigned n update can underflow. Keep the sample and byte counts as size_t here as well.

	size_t n_wrap_src;
	size_t n_wrap_snk;

src/audio/mixer/mixer_generic.c:69

• The s24 path has the same signed/unsigned mismatch: processed is size_t but samples remains int. A frame/channel product above INT_MAX can turn the loop bound negative and then huge after promotion, so this path can process beyond the buffers. Store the total in size_t and cast before multiplying, matching the s32 implementation.

	size_t nmax, ns, n, i, processed = 0;
	int32_t *dest;
	uint32_t j;
	int32_t val;
	int32_t x;
	int samples = frames * audio_stream_get_channels(sink);

src/audio/mixer/mixer_generic.c:63

• src is now const, but the wrap call below passes src[j] to audio_stream_wrap(), whose second parameter is void *. That discards the qualifier and is an incompatible pointer-type call under the project’s warning settings. Keep this array as int32_t * (as before), or use a const-preserving wrap helper.

	const int32_t *src[PLATFORM_MAX_CHANNELS];

src/audio/mixer/mixer_generic.c:109

• The same qualifier change breaks the audio_stream_wrap(sources[j], src[j]) call later in this s32 mixer: src[j] is const int32_t *, while the helper requires void *. This produces an incompatible pointer-type/const-discard diagnostic; retain the original mutable pointer type or add a const-compatible wrapper.

	const int32_t *src[PLATFORM_MAX_CHANNELS];

• Files reviewed: 29/29 changed files
• Comments generated: 3
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[intel-sofci]

PR 11193: test results

Run date: 2026-09-15 14:26 UTC

Tested commit: cdb15a1fd397194e0cd770710d6a6d9396e45aa9

[lyakh]

hmm... I've always thought that size_t means "size in bytes." But then I found an explanation somewhere that it's also common to use it for object counts. I've now searched again and again I see "mainly number of bytes." I'm not going to "request changes" here, but personally I don't find this very convincing... Maybe we need a new type for "number of samples." Wondering what OS drivers and libraries use for this?

[kv2019i]

Looks good. The per-module changes are hard to review as so many local variables are changed but looks good. Can you check the copilot comments?

[lgirdwood]

ack -LGTM, pls do resolve the copilot comments