module_adapter: Don't propagate ENOSPC and ENODATA error codes

[softwarecki]

Do not pass non-critical ENOSPC and ENODATA error codes from a module processing function to the pipeline. The pipeline will stop and enter xrun recovery if a module processing function returns a non-zero value.

[Copilot]

Pull Request Overview

This PR updates module processing routines to suppress non-critical ENOSPC and ENODATA errors, preventing them from halting the pipeline while still logging genuine failures.

• Filter out and clear ENOSPC/ENODATA in module_adapter_sink_source_copy
• Mirror the same swallow-and-log behavior in the generic module’s process implementation

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/audio/module_adapter/module_adapter.c	Refactored error check to log only non-ENOSPC/ENODATA errors and reset others to zero
src/audio/module_adapter/module/generic.c	Added identical error filtering in the generic module’s process path

Comments suppressed due to low confidence (2)

src/audio/module_adapter/module_adapter.c:995

• Using %x to format a signed error code can be misleading; consider switching to %d for consistency with other logging calls.

comp_err(dev, "module_adapter_sink_source_copy() process failed with error: %x",

src/audio/module_adapter/module_adapter.c:993

• This new branch swallows ENOSPC and ENODATA—adding unit tests to verify that these codes are ignored but other errors still propagate would help prevent regressions.

if (ret) {

[lyakh]

@softwarecki now I'm confused even more... module_process_sink_src() now cannot return -ENOSPC or -ENODATA, why are we still checking for them? If I'm right - can we improve this in a follow-up?